Revisit "narrowing" optimization rationale about raptorjit

[lukego]

... actually it looks like my use of unifdef in #5 was not extensive enough to remove the single-vs-dual number modes from RaptorJIT. This is lucky because now we can see which one makes the right performance/simplicity trade-off and remove the other!

[lukego]

I am slightly fascinated with the narrow optimization at the moment. I will do some tests to check how important it is in practice.

I suspect that it will prove to be beneficial: eliminating guard and conversion instructions, utilizing the integer-only ALUs (ports 5,6), and making other optimizations like fold more effective by letting them operate on integers instead of floats.

However, if it did prove to be unbeneficial then that would be a bit thrilling. The narrow optimization is a lot of tricky code that would be lovely to eliminate, and that may have the knock-on effect of being able to remove a bunch of integer-oriented optimizations from fold. I doubt it will pan out that way but feel obliged to check.

[lukego]

I tested -O-narrow on the Snabb CI. The report takes some practice to interpret but it shows a definite degradation of the lukego-optimize benchmark result probability distribution compared with the master reference one. Ballpark 5% slowdown on the l2fwd benchmarks (and no apparent impact on the iperf benchmark.) These benchmarks both do a lot of integer operations including with 16/32/64 bit FFI values.

So the good news is that narrow is beneficial in practice on Intel CPUs. The bad news is that the benefit may be fairly modest even though the code is quite complex.

I will look at some more optimizations and benchmarks.

[lukego]

Closing because the narrow optimization seems to be valuable in practice and not a candidate for removal.