|
|
|
|
|
|
by dietr1ch
522 days ago
|
|
|
> I've never, ever, heard the idea that compilers are burdened by the workload of maintaining thousands of type-specific optimizations for hilariously bad code, until today. I've heard tons of people complain about slow compilers, so even if compiler devs find it easy architect their compilers to do multiple kinds of optimisations there's a cost to it that devs running the compilers pay. Also, if you think about it, optimising code has to follow diminishing returns, so at some point we are putting too much CPU time into little to no gains, and it's also possible to get slower code with more optimisations if they interact poorly, or at least not better code even if spending more CPU time. This is why there's -O3 in gcc and it's not the default, there's a cost to it that's likely not worth paying. |
|
|
A slow compiler does not imply the compiler is slow because there's thousands of bespoke optimizations for nonsense code being ran
> Also, if you think about it, optimising code has to follow diminishing returns,
Nope, trivially. Though, I'm always eager for a Fermat-style marvelous proof that may have been too big for the initial margin you had. :)
Take a classic case of a buggy compiler generating O(n²) temporary copies due to missed alias analysis. One optimization pass to fix that analysis transforms it to O(n).
> at some point we are putting too much CPU time into little to no gains
It is theoretically possible to design a compiler such that it spends much more time looking for optimizations that the total sum of looking is greater than the program it is optimizing's runtime.
For example, an optimizer that is a while loop that checks if the function returns 42, but the function returns 43.
I'm not sure what light that sheds.
I'm not sure that implies that compilers have tons of bespoke optimizations for hand-transforming specific instances of absurd string code.
If they do, I would be additionally surprised because I have never observed that. What I have observed is compilers, universally, optimize code structures of a certain general form
> This is why there's -O3 in gcc and it's not the default, there's a cost to it that's likely not worth paying.
The existence of an argument with a higher processing level than default does not imply the compiler is slow because there's thousands of bespoke optimizations for nonsense code being ran. (n.b. -O3 is understood, in practice, to be risky because it might be too aggressive, not that it might not be worth it)