So what we're seeing is that a specialized handcoded assembler version is 10x faster than a generic C version?
If so that makes me a bit sad, because in the modern day we'd want to assume that compilers have gotten a little better at optimization.
If so that makes me a bit sad, because in the modern day we'd want to assume that compilers have gotten a little better at optimization.
Seriously. It's eye-popping. It's eldritch madness. It's black wizardry. The blackest of the black arts.
The "fastest FizzBuzz" implementation isn't merely "fast". It's faster than memcpy()!!!
Expecting compilers to outperform this tour-de-force is asking a tad too much from compiler writers...
All I mean is that I appreciate the author making their thought process accessible. It certainly looks like virtuosity, but I'm not competent enough to judge.
For comparison, that time is on par with integer multiplication.
// The bytecode generation loop is unrolled to depth 30, allowing the
// units digits to be hardcoded. The tens digit is stored in %al, and
// incremented every ten lines of output. The parity of the hundreds
// digit is stored in %ymm2: one half predicts the hundreds digit to
// be even, the other to be odd, and the halves are swapped every time
// the tens digit carries (ensuring the predictions are correct).Again: you're comparing the performance of different algorithms. A compiler won't turn bubblesort into quicksort.
If you show a modern compiler the typical idiomatic blob of code for counting the set bits in a word in a language like C, the compiler goes "Oh, popcount I know this" and when targeting modern CPUs it emits a single instruction, the popcount instruction for that CPU.
In APL idiom recognition was essential to making even a halfway decent compiler. It's easy, and idiomatic, to write APL which would be tremendously wasteful if implemented naively, while recognising common idioms could remove lots of that waste without needing the level of sophistication modern compilers have during optimisation.
Because the compiler knows about idioms you should not try to optimise your programs by writing non-idiomatic code until you've determined you have a performance problem and the non-idiomatic code is identified as a way to fix it. Otherwise it may be that the compiler improves and now your code is not only harder to maintain it also has worse performance than the idiomatic solution.
The programmer can understand these domain characteristics but the compiler certainly can't. If code isn't running qsort(), this could be a mistake, but may also be an optimization.
(But no, I'm not expecting AI driven compilers anytime soon)