5 ms·
A good optimizing compiler almost always beats hand coded assembly language. It is difficult for a programmer to keep track of what is going on in his code: in
by russell 16y ago
A good optimizing compiler almost always beats hand coded assembly language. It is difficult for a programmer to keep track of what is going on in his code: instruction timing, register allocation and locking, pipelined multiple instruction execution, instruction optimization, global optimization, on and on. JIT can do even better.
I've done hand optimization of RISC assembly. It's fun, but nowhere near as productive as productive as coding in Python, or C for that matter.
- rbanffy 16y agoModern processors may be to blame for that. Out of order execution, register renaming and speculative execution are very hard to wrap your head around. That's what I liked about the 6502 - very simple, very direct and somewhat RISC-ish. Not many ways to do something. It is said the ARM was very 6502 influenced, but I never worked with it on a low level. The other thing I liked about the 6502 was that I was flying under the OS all the time on those machines. Dealing with the OS at the machine-language-level is usually painful.
- pdany 16y agoI think you are overestimating the current capabilities of JIT's. Also, unfortunately, current compilers are notoriously bad at generating code with special instructions (vectorized code). So in the end applications that need to be really fast end up being written in assembly, or carefully written fortran and C code to generate a particular assembly.
- koenigdavidmj 16y ago>Also, unfortunately, current compilers are notoriously bad at generating code with special instructions (vectorized code). Sounds like the downfall of the Itanium. They promised that the compilers would make it all usable, but the compilers never showed up.