Investigate the performance impact of recompiling code non-float code to the latest swf version that will enable float checks in the VM. Compile performance media with the latest float enable asc.jar and take a performance measurement with a float enable shell. Then recompile the abc files with the "-abcfuture" switch and take another measurement. The difference in results is the added overhead of having float/float4 checks in the runtime code path. Note: None of the measure media will actually be using any of the float opcodes.
Created attachment 570754 [details] OS X 64bit performance/v8.5 Highlevel results: raytrace and crypto in the untyped code suffer a large performance hit when the float code is active at runtime. Dir: v8.5/js/ Normal -abcfuture ratio crypto 843.0 609.0 0.722 ** raytrace 846.0 789.0 0.933 ** Dir: v8.5/untyped/ crypto 960.0 671.0 0.699 ** raytrace 4055.0 3200.0 0.789 ** Full results in attachment. Revisions: patch-queue: 321:2056bcae3a1b tamarin: 6684:9e6897c7b7f6 Machine: MacPro 2x2.66 GHz 6-Core Intel Xeon, 6GB RAM
An interesting benchmark to run here eventually is to compare the performance of the old VM with the new VM as you do above, once the array optimizations land. It might not matter too much for the two benchmarks above but the point I'm making is that we may be able to make up some of the lost ground by optimizations that come in elsewhere, ergo it's not an overall regression. Which is not to say that there are not programs that will not regress. Hard to say how much effort we should expend on making untyped code run fast. Would be interesting to know how much of the problem above is boxing costs - I assume a lot (gcsummary data would be useful). Would be interesting to investigate a code generation strategy that avoids heap boxing for intermediate numerics by using 16-byte boxes in code that is predominantly untyped. Ditto NaN boxing of course.
You need to log in before you can comment on or make changes to this bug.