llvm dev - Apr 2020 - Why we don't have eternal optimizers?

Hi everyone,

Lately I've been thinking of the optimization model of almost any optimizer
ever.
The optimizer should finish "at a reasonable time". For example,
for a 20k lines program, the optimizer should finish in a couple of minutes
and not
e.g. a couple of days.

And my question is, why? For almost all programs, the period that starts
when the program
starts being developed to the day it is released is way bigger than a
couple of minutes.
In the meantime, a couple of modules might not have been touched for months.
And an unconstrained optimizer could do its best in all this time.

Given that this eternal optimizer will respect the initial semantics, one
can compile
a module, test it, and then let the optimizer do its best. The behavior of
a module should
only be faster, no need to re-test.

In the meantime of course, we need to test the program as a whole and other
modules
might actually change. For that we can already what happens today which is
run
"reasonably optimized" builds.

This is a humble opinion and I'm looking forward to hear the opinion of the
LLVM community.

Best,
Stefanos
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200413/a6ff1eb4/attachment.html>

Hi,

   Seems like something that could be useful, but…
> Given that this eternal optimizer will respect the initial semantics, one
can compile
> a module, test it, and then let the optimizer do its best. The behavior of
a module should
> only be faster, no need to re-test.
   This seems extremely dangerous. In theory it shouldn’t change the behavior,
but all software has bugs…

Thanks,
   Christopher Tetreault

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Stefanos
Baziotis via llvm-dev
Sent: Monday, April 13, 2020 9:13 AM
To: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [EXT] [llvm-dev] Why we don't have eternal optimizers?

Hi everyone,

Lately I've been thinking of the optimization model of almost any optimizer
ever.
The optimizer should finish "at a reasonable time". For example,
for a 20k lines program, the optimizer should finish in a couple of minutes and
not
e.g. a couple of days.

And my question is, why? For almost all programs, the period that starts when
the program
starts being developed to the day it is released is way bigger than a couple of
minutes.
In the meantime, a couple of modules might not have been touched for months.
And an unconstrained optimizer could do its best in all this time.

Given that this eternal optimizer will respect the initial semantics, one can
compile
a module, test it, and then let the optimizer do its best. The behavior of a
module should
only be faster, no need to re-test.

In the meantime of course, we need to test the program as a whole and other
modules
might actually change. For that we can already what happens today which is run
"reasonably optimized" builds.

This is a humble opinion and I'm looking forward to hear the opinion of the
LLVM community.

Best,
Stefanos
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200413/4c382db0/attachment.html>

Hi,

Thanks for your feedback!

Yes, I agree. What I described is the "extreme". In a real-world
scenario,
that may be modified to X amount of time (e.g. days or hours or
whatever the programmer believes is important). Automatic tests can be run
every X amount of time. You pretty much
only have wins, as the module would stay as still otherwise. And if the
eternal optimizer breaks something, you can
always go back to a previous version.

My main point is that right now, optimizers are constrained heavily for
reasons that might not be pragmatic. Even if the available
time becomes an hour vs a minute, imagine how different and more
powerful an optimizer could be.

Best,
Stefanos

Στις Δευ, 13 Απρ 2020 στις 8:33 μ.μ., ο/η Chris Tetreault <
ctetreau at quicinc.com> έγραψε:
> Hi,
>
>
>
>    Seems like something that could be useful, but…
>
>
>
> > Given that this eternal optimizer will respect the initial semantics,
> one can compile
> > a module, test it, and then let the optimizer do its best. The
behavior
> of a module should
> > only be faster, no need to re-test.
>
>
>
>    This seems extremely dangerous. In theory it shouldn’t change the
> behavior, but all software has bugs…
>
>
>
> Thanks,
>
>    Christopher Tetreault
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of
*Stefanos
> Baziotis via llvm-dev
> *Sent:* Monday, April 13, 2020 9:13 AM
> *To:* llvm-dev <llvm-dev at lists.llvm.org>
> *Subject:* [EXT] [llvm-dev] Why we don't have eternal optimizers?
>
>
>
> Hi everyone,
>
> Lately I've been thinking of the optimization model of almost any
> optimizer ever.
> The optimizer should finish "at a reasonable time". For example,
> for a 20k lines program, the optimizer should finish in a couple of
> minutes and not
> e.g. a couple of days.
>
> And my question is, why? For almost all programs, the period that starts
> when the program
> starts being developed to the day it is released is way bigger than a
> couple of minutes.
> In the meantime, a couple of modules might not have been touched for
> months.
> And an unconstrained optimizer could do its best in all this time.
>
> Given that this eternal optimizer will respect the initial semantics, one
> can compile
> a module, test it, and then let the optimizer do its best. The behavior of
> a module should
> only be faster, no need to re-test.
>
>
>
> In the meantime of course, we need to test the program as a whole and
> other modules
> might actually change. For that we can already what happens today which is
> run
> "reasonably optimized" builds.
>
> This is a humble opinion and I'm looking forward to hear the opinion of
> the LLVM community.
>
> Best,
> Stefanos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200413/522b08c5/attachment.html>