3 ms·

I wonder if it's already the time to put to rest the myth that the human-coded assembly for a modern CPU is slower than what a compiler generates? As far as I

I wonder if it's already the time to put to rest the myth that the human-coded assembly for a modern CPU is slower than what a compiler generates? As far as I know it's been semi-true around Pentium time. On that asymetrical dual pipeline architecture with many parring exceptions and some microcoded instructions in the mix the typical hand-optimized code for the previous generation CPUs would likely under-utilize the second pipe and hit some microcode for a good measure. However, even the Pentium Pro already had a very robust front end that did not require non-intuitive op rearrangement to utilize multiple exec units. Saying that you cannot hand code better than the compiler for a non-Pentium CPU nowadays sounds similar to saying that if you use too many set bits in your data then the punch cards will warp and tear apart from too many holes.

yohanatan 12y ago
> Saying that you cannot hand code better than the compiler for a non-Pentium CPU nowadays sounds similar to saying that if you use too many set bits in your data then the punch cards will warp and tear apart from too many holes. If one prefers a style with more set bits than not, looks like there could easily be a physical switch on the machine to inform it to globally flip the bits.
userbinator 12y ago
Speaking from experience, this myth was never true from 8086 up through the 486; the Pentium (P5) might've been slightly harder to optimise for, but a human could still easily beat the compilers of the time. And of course, it is not true today either. Around the time of the P6 (Pentium Pro/II/III) was when I think things really improved - out-of-order execution/speculation/wide decoders meant instruction ordering had little significance, and so getting more performance was more about reducing the number of instructions needed - something compilers tended to not do well at. I believe the myth came from the early days of the RISC fad, where CPUs were designed specifically so that compilers could easily generate code for them and make human-coded Asm "obsolete"; although to me this appears to be more of a "take all the advantage away from humans, making it just as hard for them to optimise the code as the compiler"... I have only a little experience with writing Asm for MIPS and ARM, but even from that I can see they do not have anywhere near the sort of "room for optimisation" that x86 provides. Another myth that probably needs to die now is "microcoded instructions are slow"; in a recent article on HN about using the old BCD instructions which were commonly thought to be much slower than an equivalent sequence of simpler instructions (https://news.ycombinator.com/item?id=8477254 https://news.ycombinator.com/item?id=8477254 ), I did a quick benchmark and found they were basically the same speed, but much shorter. The one caveat is that currently these complex instructions can only be decoded by one of the decoders, so having too many of them close together can slow things down if the other decoders can't find a simpler non-dependent instruction to decode; but using them sparingly could be good for making code smaller (and thus consume less cache) without any speed penalty, or possibly increase speed overall due to reduced cache misses.

yohanatan 12y ago

> Saying that you cannot hand code better than the compiler for a non-Pentium CPU nowadays sounds similar to saying that if you use too many set bits in your data then the punch cards will warp and tear apart from too many holes. If one prefers a style with more set bits than not, looks like there could easily be a physical switch on the machine to inform it to globally flip the bits.

userbinator 12y ago

Speaking from experience, this myth was never true from 8086 up through the 486; the Pentium (P5) might've been slightly harder to optimise for, but a human could still easily beat the compilers of the time. And of course, it is not true today either. Around the time of the P6 (Pentium Pro/II/III) was when I think things really improved - out-of-order execution/speculation/wide decoders meant instruction ordering had little significance, and so getting more performance was more about reducing the number of instructions needed - something compilers tended to not do well at. I believe the myth came from the early days of the RISC fad, where CPUs were designed specifically so that compilers could easily generate code for them and make human-coded Asm "obsolete"; although to me this appears to be more of a "take all the advantage away from humans, making it just as hard for them to optimise the code as the compiler"... I have only a little experience with writing Asm for MIPS and ARM, but even from that I can see they do not have anywhere near the sort of "room for optimisation" that x86 provides. Another myth that probably needs to die now is "microcoded instructions are slow"; in a recent article on HN about using the old BCD instructions which were commonly thought to be much slower than an equivalent sequence of simpler instructions (https://news.ycombinator.com/item?id=8477254 https://news.ycombinator.com/item?id=8477254 ), I did a quick benchmark and found they were basically the same speed, but much shorter. The one caveat is that currently these complex instructions can only be decoded by one of the decoders, so having too many of them close together can slow things down if the other decoders can't find a simpler non-dependent instruction to decode; but using them sparingly could be good for making code smaller (and thus consume less cache) without any speed penalty, or possibly increase speed overall due to reduced cache misses.