7 ms·
Surprisingly, compilers already do much of these optimization, particularly profile directed feedback (basically a static JIT), and the mixing of high-level and
by CountHackulus 16y ago
Surprisingly, compilers already do much of these optimization, particularly profile directed feedback (basically a static JIT), and the mixing of high-level and low-level optimizations.
Now while, LLVM may not do this, it's far from the only compiler on the block; especially in the non-open-source world.
The IR argument is a non-argument. Certain optimizations work better with certain IRs than others, that's just the way it is. It's unlikely that there will be one to rule them all. More likely, we'll convert between them to use the optimal one.
Superoptimizers are an interesting case, it's kind of like having a database of optimality. While it may not give much speedup compared to time invested, if you're desperate for that last little bit of performance, it's a great tool. Plus it should make itself faster over time. Could even locate it in the cloud, such that a compiler send its hottest methods over to a remote machine, and it'll use its massive database of optimality to optimize it as best as possible.
Verifiable transformations are great in theory, but it's true, it's extremely hard to implement currently.
The author definitely has a point about AOT/JIT compilers being the future of optimization. Static compilers have been done to death, while dynamic compilers are still (comparatively) new and fresh.
- ced 16y agoNow while, LLVM may not do this, it's far from the only compiler on the block; especially in the non-open-source world. Non-open-source compilers don't get much press around here. Could you point out the most interesting ones?
- larsberg 16y agoVisual C++ has had things like profile-guided optimization for over a decade internally to MSFT and nearly that long shipping externally (http://blogs.msdn.com/b/vcblog/archive/2008/11/12/pogo.aspx http://blogs.msdn.com/b/vcblog/archive/2008/11/12/pogo.aspx). In general, the Microsoft and Intel C++ compilers have pretty incredible performance on the x86 platform. The last time I talked to the Intel folks, they didn't really consider GCC to be competitive. It's possible things have changed in the last five years on that front; apologies if I'm misrepresenting the state of GCC optimization quality. The PGI Fortran folks are pretty incredible in the parallel space. On embedded platforms, most serious companies seem to buy the Green Hills C++ compiler. One of the program-management types from the Visual C++ team could probably do this much better justice than my quickly-fading memories. But, I think the HN crowd would be quite shocked by the market share that commercial compilers have, even on *NIX platforms.
- gaius 16y agoIt is not unusual to get 2x performance with icc vs gcc. But of course, their priorities are different. Sun's SPARC compilers are (were?) also excellent. The benefits of targetting only one architecture and developing the compiler in close collaboration with the hardware designers. gcc is "free" but is it free enough to double the bill for hardware? Benchmark and find out...
- beza1e1 16y agoI have never seen such a speed difference. Can you reference anything?
- gaius 16y agoBenchmarks we did at my last company (trading app in C++). But like I say, try it for yourself. There's a reason people still pay $$$ for compilers when GCC is free!
- beza1e1 16y agoWell, i am doing compiler research, which means testing is mostly SPEC CPU. Sometimes i wonder if those measurements show reality, because every serious compiler is heavily optimized for these special cases. There is no 2x difference there.
- gaius 16y agoCalculating yield curves is pretty "real world", as is transactions/sec. If the benchmark is representative, then it is a good benchmark, and if the compiler is optimized for it, then it is optimzed for real world use cases too.
- acqq 16y agoYou should definitely measure something from the real life. I measure something as simple as a loop in which some short floating point calculations is made (actually only two additions per loop and one FP comparison) and my measurements on the latest Intel i5 give (in seconds): 0.31 VS2010 -O2 SSE2 0.35 VC 6 -O2 0.44 cygwin gcc-4.3.2 -O2 0.95 cygwin gcc-3.4.4 -O2 I haven't tested the later 4.x gcc but the results are clear -- even VC 6, 12 years old, is better than a quite recent gcc, at least for FPU calculations.
- ohyes 16y agoThe interesting thing about the peephole superoptimizer paper that he linked is that the actual peephole optimization process is not necessarily slower than a regular peephole optimizer, as all it is doing is looking up faster equivalent instructions in a database. The difficult (compute intensive) part is training the database, and you only have to do that once for each optimization... I am a little confused by why he stated that the results of the super optimizer were not very impressive. Presumably, man-years have been invested in defining optimizations for compilers like GCC and the intel C compiler, by human experts... To have a machine that even gets close to those results is impressive to me. If the technique were used for an actual compiler, it would mean that no one would have to write peephole optimizations, instead, the compiler would just get better and better as it ages. Combined with aggressive in-lining (or maybe dynamic recompilation? e.x. lisp style function compilation rather than C), it seems to me that this sort of technology could be incredibly powerful. Am I wrong?
- beza1e1 16y agoSuperoptimizers are good at finding complex combinations of mini optimizations, but often optimization is finding creative solutions to lots of special cases. Machine learning does not help you with creating more mini optimizations.