Closed
Bug 584837
Opened 14 years ago
Closed 6 years ago
Using unsigned compares for uint can be significantly faster
Categories
(Tamarin Graveyard :: Baseline JIT (CodegenLIR), defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
Future
People
(Reporter: wsharp, Unassigned)
Details
(Whiteboard: PACMAN)
asmicro/global_var_write test case was showing some very strange performance gains with my simple function analyzer change...50% faster on my Xeon. Simple test case below shows these results: With method overhead skipped: 230 msecs (INT or UINT) With prologue code and i:int var: 280 msecs With prologue and i:uint var: 430 msecs. Why the big difference? The method overhead skip just shifts the hot loop in memory...some sort of cache alignment? The uint/int change changes one instruction in the loop...a JL vs. a JB. Why a 50% slowdown. var global_var:int = 1; function writeloop():int { var v:int = 2; for ( var i:int=0; i < 100000000 ; i++ ) global_var = v; return i; } function foo() { var d1:Number = new Date().getTime() ; for (var i:int = 1; i < 2; i++) { writeloop(); } var d2:Number = new Date().getTime() ; trace("elapsed time is " + (d2-d1)); } foo();
Reporter | ||
Updated•14 years ago
|
Whiteboard: PACMAN
Reporter | ||
Comment 1•14 years ago
|
||
I answer one question. If I change nativei386.cpp to emit a JL instead of a JB for the unsigned compare, I get the 280 msecs from 430. So that single instruction at the end of the loop is responsible for the time difference. Otherwise the JITed code looks identical.
Comment 2•14 years ago
|
||
FYI, some future mitigate techniques might conflict with this work.
Flags: flashplayer-qrb+
Summary: Investigate code alignment with this simple test case → Using unsigned compares for uint can be significantly faster
Target Milestone: --- → Future
Comment 3•6 years ago
|
||
Tamarin is a dead project now. Mass WONTFIX.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Comment 4•6 years ago
|
||
Tamarin isn't maintained anymore. WONTFIX remaining bugs.
You need to log in
before you can comment on or make changes to this bug.
Description
•