Closed Bug 698492 Opened 13 years ago Closed 6 years ago

Investigate performance impact of introduction of float/float4

Categories

(Tamarin Graveyard :: Virtual Machine, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX
Q2 12 - Cyril

People

(Reporter: brbaker, Unassigned)

References

Details

Attachments

(1 file)

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.
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.
Priority: -- → P3
Target Milestone: --- → Q2 12 - Cyril
Tamarin is a dead project now. Mass WONTFIX.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Tamarin isn't maintained anymore. WONTFIX remaining bugs.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: