3 ms·
I realized this myself when I wrote my first JIT compiler. The x86 code generated from bytecode was frightingingly naive. With basic code inlining and redundant
by gizmo 18y ago
I realized this myself when I wrote my first JIT compiler. The x86 code generated from bytecode was frightingingly naive. With basic code inlining and redundant instruction elimination my scripting language ran at 95% the speed of the equivalent c program with -O3 optimizations. And the assembly code generated by gcc was at least 3 times shorter.
Processors do a damn good job at optimizing code, and cache locality is more important than you'd think. The CPU blazes through redundant mov instructions like there's no tomorrow.
The good news is that building a fully functioning native code compiler is doable by a single person.
- palish 18y agoIt is. I happen to be working on a small demonstration of one. I'll post the code for reference when it's done.
- orib 18y agoInteresting. I suppose it depends on what you're doing, but I typically see the speed taken getting cut to half vs -O and -O2 in C/GCC, so things will typically run at 50% the speed. Flipping around between -O, -O2, and -O3 don't make much difference though. The big thing to note is that once you start enabling some major optimizations (doing good register allocation, strength reduction, loop-invariant hoisting, and tail-call elimination) you've already got 95% of the optimization you're going to get. The rest is far less important. This, of course, won't matter if you spend most of your time in I/O or libraries.