Summary: | Speed up JSImmediate::getTruncated* by using custom float -> int code | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> | ||||||||
Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> | ||||||||
Status: | RESOLVED INVALID | ||||||||||
Severity: | Normal | CC: | darin, mjs | ||||||||
Priority: | P2 | ||||||||||
Version: | 523.x (Safari 3) | ||||||||||
Hardware: | Mac | ||||||||||
OS: | OS X 10.4 | ||||||||||
Attachments: |
|
Description
Eric Seidel (no email)
2007-10-30 03:17:42 PDT
Created attachment 16944 [details]
broken fix
Created attachment 16956 [details]
nearly correct functions (fail two tests) inside test harness
The test output: Running JSImmediate::getTruncated* tests, this will take a while. testing : -2147483648 : 1000 0000 0000 0000 0000 0000 0000 0000 getTruncatedUInt32 -0.000000 expected: 0 (1) got: 0 (0) testing : -822083584 : 1100 1111 0000 0000 0000 0000 0000 0000 getTruncatedInt32 -2147483648.000000 expected: -2147483648 (1) got: -2147483648 (0) The first failure is obvious. Not sure if we need to support it (depending on how 0 is stored in JSImmediate floats), probably though. The second failure seems to be related to exponent size. FYI, in addition to being slightly wrong... this code is also slightly (but only slightly!) slower than the current float -> int code. I'm confident that both correctness and speed can be fixed, but I'm a bit tired to do so myself. Perhaps someone will do so while I'm in Mexico. Created attachment 16957 [details]
an actual patch for JSC (same code as in test above)
Oliver got good results by switching our immediate optimization from floating point to int instead. |