If you've ever looked at the VAX instruction set, you'll possibly be surprised to see an essentially-Greenspun microcoded CPU (there's definitely list-walking instructions in there and all sorts of BIZARRE things).
One of the few CPUs I know of where "optimize for lowest instruction count" tends towards generating slower and larger code than either "optimize for smallest code size" or "optimize for fastest execution" (also the inly CPU I know of to have had a "optimize for instruction count" compiler, but taht may be by-the-by).
If you've ever looked at the VAX instruction set,...
...and lived to tell the tale....
Yeah. The polynomial evaluation instruction on early Vaxen was slower and larger than DIY evaluation, as I recall. (This may have been microcode version and/or VAX model dependent). It made me laugh many a time.
( But then, I actually liked the nasty complexity of early DCL quoting, so,... )
For a long time I thought the early RISC proponents just had a sour grapes attitude because they weren't smart enough to write a compiler that could make use of the VAX instruction set. :)
"optimize for instruction count" makes sense in a universe where a megabyte is a huge (and hugely expensive) amount of RAM. Especially on a machine with virtual memory* and poor page swapping algorithms. A program that exceeded it's available RAM by even a few bytes could take a horrible hit in performance due to disk swapping. A less than speed optimal program may well outperform a speed optimized program if stays resident in RAM.
*) Virtual memory in it's original sense, not today's definition which is mostly just memory management.
"optimize for smallest code size" makes more sense in that context, and the comment you're replying to asserts that "optimize for instruction count" tended to produce bigger code than "optimize for smallest code size", which is unsurprising. (The surprising part is that "optimize for smallest code size" existed.)
It would've made sense, if it wasn't for the fact that the really powerful instructions (as in "did lots of stuff") usually ended up being MASSIVELY huge, memory-wise. We're talking machine instructions in the multiple tens of bytes, here.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Date: 2009-12-20 04:49 pm (UTC)(no subject)
Date: 2009-12-20 05:13 pm (UTC)(no subject)
Date: 2009-12-20 05:38 pm (UTC)One of the few CPUs I know of where "optimize for lowest instruction count" tends towards generating slower and larger code than either "optimize for smallest code size" or "optimize for fastest execution" (also the inly CPU I know of to have had a "optimize for instruction count" compiler, but taht may be by-the-by).
(no subject)
Date: 2009-12-20 09:02 pm (UTC)...and lived to tell the tale....
Yeah. The polynomial evaluation instruction on early Vaxen was slower and larger than DIY evaluation, as I recall. (This may have been microcode version and/or VAX model dependent). It made me laugh many a time.
( But then, I actually liked the nasty complexity of early DCL quoting, so,... )
(no subject)
Date: 2009-12-20 09:46 pm (UTC)For a long time I thought the early RISC proponents just had a sour grapes attitude because they weren't smart enough to write a compiler that could make use of the VAX instruction set. :)
(no subject)
Date: 2009-12-20 09:59 pm (UTC)"optimize for instruction count" makes sense in a universe where a megabyte is a huge (and hugely expensive) amount of RAM. Especially on a machine with virtual memory* and poor page swapping algorithms. A program that exceeded it's available RAM by even a few bytes could take a horrible hit in performance due to disk swapping. A less than speed optimal program may well outperform a speed optimized program if stays resident in RAM.
*) Virtual memory in it's original sense, not today's definition which is mostly just memory management.
(no subject)
Date: 2009-12-22 01:08 am (UTC)(no subject)
Date: 2009-12-27 05:30 pm (UTC)Indeed. I have disabled cache on pc's just to see how much the performance drops. Tip: don't do this with an o/s that boots into a gui.
I've also done a fair amount of embedded kernel development so I've benchmarked the differences between cache on and cache off at boot time.
(no subject)
Date: 2009-12-22 07:54 pm (UTC)(no subject)
Date: 2009-12-27 05:39 pm (UTC)You're right, I mis-read the comment. my above comment should have been in regards to "optimize for smallest code size".
(no subject)
Date: 2009-12-29 11:30 am (UTC)