On 2010/07/26 20:51:59, zarko wrote:
I'm looking for some initial comments on this one and expect that it will go
through some revision.

And I think this is the right day, so: welcome back from vacation, Vitaly!

Thanks
   Luke

The delta in performance on this is a mixed bag-- and it's definitely not as
significant as the difference I observed before applying the TLS merge patch. The WindScorpion IEEE754 benchmark goes from a speedup of 63.925 (/100) down to 59.875 on ia32, but from 64.975 to 68 on x64. (Overall on ia32 this goes from 503.75 to 510.5 on the v8 subset score and on x64 it goes from 492.75 to 497.5.
The benchmarks in the subset I'm using are Richards, DeltaBlue, Crypto,
RayTrace, EarleyBoyer, RegExp, Splay, ws-IEEE754Conv, ws-genetic, ws-solve,
ws-longfact and ws-huffman).

On x64, (out of all calls) calls to pthread_getspecific go from 2.3% to 1.9%;
calls to dyld_stub_pthread_getspecific go from 1.7% to 1.5%. Some runtime
routines are still hitting TLS transitively-- eg, LoadContextSlotHelper calls IsContext(), which grabs at the heap through Isolate::Current->heap(). I think
that we ought to push the isolate/heap pointers out along the call graph a
little more. (This would work in concert with the oddball-bits CL; I'd expect it's faster to use the heap when you have a pointer to it at the ready, but if
you have no such thing the extra indirections of the oddball bit test are
probably cheaper than the control effects of Isolate::Current().)



http://codereview.chromium.org/2884039/show

--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev

Reply via email to