It's like compilers. There is optimization by recognizing cases that might occur in programs. And then there is optimization by recognizing ... entire functions featured in specific benchmark programs, or those entire programs themselves.

Imagine a compiler that recognizes when you're attempting to compile Firefox from source. It checks your internet connection speed and hashes all the source files. If your Internet connection is sufficient, and the hashes match, this nifty compiler would "optimize" the compilation by downloading the matching binary from mozilla.org.

ccache hashes the preprocessed input to gcc, hashes it, and pulls out a previously compiled object file if possible. You can use it together with distcc to farm out jobs to other machines; whether you pick their caches or yours depends on the order of ccache and distcc on the command line.

So basically any caching strategy?

Compiler optimisation isnt about compiling faster, though :-)

Of course it is, at least if the optimized compiler is compiled with an optimized compiler, but also generally fast compilation is optimal.

Fast compilation is a worth goal, but it's not fundamentally different from optimizing other kinds of programs: it involves good selection of data structures and algorithms, smart caching, that sort of stuff.

Compiler optimization (in the sense of optimizing the emitted code) is a research area of its own with millions of man hours invested.

Oh my. I've worked in those car test and simulation SW environments (and a cross compiler for a weird engine), and now I'm working on compilers and compiler optimizations in a different industry.

You cannot compare that at all.

With engine simulation and control you have real-time loops, with the biggest problem being the latency. You reduce latency by getting better HW, better sensors, shorter distances, a better SW driver architecture. You don't optimize by finding patterns or counting occurrences at all, esp. not at run-time. You always have to be prepared for the worst case. Plus you always have HW + SW combined. Any major important SW feature is always doubled in HW for security. It's a different world.

With compilers there's no real-time trouble (GC's, ha!), mostly no loops, no worry about HW, cables, sensors or drivers. It's pure abstraction. With JIT compilers it's a bit different, mostly a tradeoff memory + optimization overhead vs speed. More measurements and dynamic decisions. But jit optimization in engine control? Nah. And there's never a HW cross check. Signals, interrupts may arrive or get lost. The machine will not hard reset and reboot if a signal gets lost. It does so in a car or in space or other industrial control environments.

The similarity is that optimization is taking place, and cheating is possible by recognizing a test situation, in order to "game" the test. Compilers can "game" benchmarks by recognizing them specifically and supplying hand-crafted code. The cases which do this have no applicability to non-benchmark code. Just like recognizing that an emissions test is taking place and behaving optimally for that test has no applicability to real driving.