Re: v8 first impressions

Hello

I gave a quick look at the V8 source code (I was curious about some
architectural choices) and it is a lot less interesting than what I've
read on the web made me expect.

V8 is clearly a VM made to be embedded and run short Javascript code
that interacts with a large amount of built-in objects and functions
(like DOM). Compilation straight to native code does make perfect
sense for this specific use, as well as many other implementation
choices in V8 (I suppose the complexity of the write barrier also
comes from the desire to simplify embedding, compared to simpler
cardmarking). It's fine software and deserves credit for it's
performance as a JS engine for web browsers.

However, if your goal is to run a complete application/system on a VM
(not embedding) or if your language is not based on Javascript, then
I'm afraid using this VM doesn't make much sense. V8 and Strongtalk
(among others) have been made with totally different goals in mind,
and it's hard for me to see a meaningful way to compare them in
practice.

So it doesn't really surprise me to see Strongtalk crush V8 when it
does what it has been made for. In fact, there's probably more room
for Strongtalk to improve than for V8 here: Strongtalk has a cheaper
write barrier, less indirection, and more potential for optimisation
due to type-feedback (escape analysis...).

Btw, a simple optimisation to Strongtalk's GC (using a sparse and
precise representation for the remembered set during scavenges) would
remove any advantage that V8's more expensive write barrier might give
to it's scavenging speed.

Dave: regarding PICs, I'm pretty sure it's critical that you have a
monomorphic send attempt followed by a megamorphic send for the case
where a call site is nearly-monomorphic. In essence, this is a
degenerate PIC of length 1, and I guess it seems natural to allow
bigger PICs. I think this mainly made sense in the Self system where
the effiency of ifTrue:/ifFalse:/etc depended highly on PICs of arity
2. This is irrevelant in Strongtalk (or in any system that implements
booleans without polymorphism). I suspect larger PICs are useless
because of recompilation (it makes code more monomorphic - PICs for
non-inlining JITs (VW or V8) are another story). It would actually be
interressing to benchmark strongtalk with various settings (no PICs,
PICs limited to various sizes). If PICs of length 1 are found to be
enough, then the PICs code could indeed be much more simple.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en
-~----------~----~----~----~------~----~------~--~---