There are actually VERY few compilers that will generate standard C++ into the fastest possible code in the case of several specific algorithm types.
The most common example is when coding SIMD instructions with an assembler. Any JPEG or MPEG codec that is halfway decent these days MUST use hand-coded assembly to get decent speed.. I'm not saying that the hand-coded assembly routines wouldbe the fastest possible.. I'm just saying there are any readily available C++ compilers that will come close.
It seems I didn't make my meaning clear enough, but I was trying to make the point that for AN ENTIRE PROGRAM for the vast majority of cases it's not just really hard, but it can take more time and skill than any team of humans realistically has available, just to get results as good as a good compiler. I was replying to:
they could also make games nowadays that run twice as fast or are twice as smart, or pretty, etc. all they would have to do is write it all in assembly which would be too much effort
...I would like to see, for example, someone writing entire non-trivial OO programs in fully optimized assembler, by hand.
Or see someone doing optimal register assignment for a whole PROGRAM, bearing in mind they have to write the entire program several times, trying different tradeoffs between e.g. reducing memory accesses vs making use of the cache.
If you read my post carefully, I'm basically objecting to the claims that you can write whole programs (and we're talking computer games here, not simple stuff) in optimized assembler by hand - and that they'll be "twice as fast" as the compiled C++ version. That's just complete rubbish! In reality, a complete program is typically going to be very close in execution speed. TYPICALLY - i.e. I'm sure we could come up with another dozen particular programs, like your examples of (de)compressors, where the difference can be much greater - but these are special cases, and as you point out generally occur when the program is dominated by a particular kind of algorithm.
I wasn't trying to say "no compiled code can ever be sped up". I did say "Assembler programs are NOT faster than compiled programs". You seem to have read that as "bits of code written in Assembler are NOT faster than the same bits of code output from a compiler" - the distinction (which obviously I didn't make clear enough, sorry) is critical.
PS: there are also some crap compilers in common use, like the GNU ones last time I checked in detail, about 4 years ago (ducks and runs for cover!). Seeing GNU C++ compilers get thrashed on various benchmarks by Java 2 compilers is pretty unimpressive. Back then, the MS C++ compiler seemed about as good as I expected from a good compiler.
(at this point I'm so far off-topic, I'm actually back on topic again).
