<div dir="ltr"><br><br><div class="gmail_quote">On Sun, Sep 7, 2008 at 4:56 AM, David Griswold <span dir="ltr"><<a href="mailto:david.griswold.256@gmail.com">david.griswold.256@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div dir="ltr"><div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Sun, Sep 7, 2008 at 4:22 AM, Paolo Bonzini <span dir="ltr"><<a href="mailto:bonzini@gnu.org" target="_blank">bonzini@gnu.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> Also, compiling code that isn't in a hotspot is a waste of time, since<br>
> you spend much longer compiling the code than you would have spent<br>
> interpreting it, and can cause big compile pauses if the compiler does<br>
> much optimization.<br>
<br>
</div>You can use a simple 1-pass compilation (without even register<br>
allocation) that takes just a few ms for any reasonable amount of code.<br>
Don't forget that V8 runs (mainly) in a browser--if the browser is<br>
sufficiently snappy, the user won't notice a compilation pause of a few<br>
milliseconds.<br></blockquote></div><br></div></div><div>Such a compiler is fast, but it produces verbose code. I was talking about a <span style="font-weight:bold">large</span> body of code, the sort that might begin to be used if V8 is used on the desktop for things like running an entire Smalltalk image, for example. In those sorts of cases, there is a difficult trade-off: if you use a fast compiler like the one you are talking about, it produces verbose code that consumes a lot of space, which was the problem for Self. On the other hand if you use a good compiler that produces more compact code, then you get large compilation pauses. </div>
<div><br></div><div>Using a code cache like in Visualworks or mixed-mode hotspot compilation like we did in Strongtalk and the JVM is how to get around that trade-off. The question is, what does V8 do to solve this problem? That is not yet clear. If they don't have some compact way of representing and executing uncommonly-used code, then it will have problems with large bodies of code.</div>
</div></blockquote><div><br></div><div>David is exactly right. I think v8 does not yet have to face this problem because it is compiling javascript programs in web pages where the largest programs are a few hundred k bytes of source (e.g. the lively kernel at around 300k).</div>
<div><br></div><div>That doesn't invalidate v8 for its intended use. As they find it doesn't scale they'll have to evolve the implementation. But right now v8 is the fasted js engine on the planet and it works just fine :)</div>
</div><br></div>