News for hackers. Stuff that matters.
Re:Make LLVM Fast Again by pfdietz on Monday May 11, 2020 @08:28AM (#23141338)
> Most code is executed a lot more frequently than it is compiled, so if I can get a 1% speed increase with a 100x compile slowdown, I'll take it.

Is that really true? I'd have thought most code outside inner loops benefits almost negligibly from optimization.

Re:Make LLVM Fast Again by jeffbee on Monday May 11, 2020 @11:01AM (#23142873)
That really depends on your program. Many servers have sprawling, flat profiles. Most workloads are not computational fluid dynamics. A perspective on hot/cold code ratio is found in "AsmDB: Understanding and Mitigating Front-End Stalls in Warehouse-Scale Computers" https://storage.googleapis.com/pub-tools-public-publication-...
Re:Make LLVM Fast Again by sesuximo on Tuesday May 12, 2020 @11:51AM (#23155356)
Good question. It's worth asking whether optimizations significantly help "most" code.

There are some optimizations that make a big difference everywhere:

- consolidating pure function calls. This can save arbitrary amounts of time. Classic example is strlen being called many times. I know you're not asking about inner loops, but this can change the complexity of loops which is a big big win.

- mem2reg. Kind of self explanatory. Registers are fast but we write C and C++ using addressable objects. Most compilers make a decent effort here even with optimizations turned off.

- global variable numbering. This allows loads and stores to be removed/moved. Often prevents cache misses or puts them off until the end of a function when it doesn't block execution.

- strength reduction. Turning your divisions into shifts. Turning your && into &. Etc. It is not unusual for these peephole changes to save 10s of cycles per instruction replaced.

These are also really fast optimizations (mem2reg can be extremely slow if "optimal", but the heuristic versions that everyone uses are quick).

If you know you won't care, you can mark the function as cold. That said, the compiler might ignore you and decide you cannot possibly really want to disable something like mem2reg.

Re:Make LLVM Fast Again by bluGill on Monday May 11, 2020 @09:19AM (#23141765)
I don't have time to figure out the correct tradeoff for optimization for each tiny code section of code. Just let the compiler do everything and it might be too much but it won't be too little.

Besides, little things add up even outside of tight loops. Slow code in rarely used areas is still noticeable when that rare thing happens.

Re:Make LLVM Fast Again by pfdietz on Monday May 11, 2020 @05:46PM (#23147477)
So, you don't have time to profile to see where the hotspots are, but you care about how fast your program is? Mkay.
Re:Make LLVM Fast Again by jrochkind1 on Monday May 11, 2020 @08:35AM (#23141394)
It may benefit negligibly from optimization -- or rather, the overall program may benefit negligibly from optimizing that code site -- but it's still gotta be executed a lot more frequently than it is compiled right? Unless it has only one or two users, who both compile it all the time, or something.