Re: v8 first impressions
"David Griswold" <[email protected]> Fri, 5 Sep 2008 12:09:41 -0700
| Newsgroups | gmane.comp.lang.smalltalk.strongtalk |
|---|---|
| Message-ID | <[email protected]> |
------=_Part_51919_25462557.1220641781144 Content-Type: text/plain; charset=ISO-8859-1 Hi Eliot, sorry for the delay in answering, I am traveling overseas. On Wed, Sep 3, 2008 at 9:57 AM, Eliot Miranda <[email protected]>wrote: > Hi David, > > I spent some time reading the code yesterday. Here's what I could > glean > > > Thread model: the standard, multi-threaded with only one active thread at a > time, i.e. the standard combination of a green thread VM architecture with > native threads, as seen in Strongtalk. Different threads must use a lock on > the entire VM to use it. There is a preemptive scheduler to share the VM > between threads waiting on the lock. > > That's interesting; green threads I expected but the preemptive scheduler for sharing the VM sounds cool. But I hope that doesn't mean they can't actually schedule different VM instances concurrently. > > Parses direct to an AST. > > > Generates native code directly from AST. > > > No bytecode intermediate form. > > > In-lines simple arithmetic ops (see codegen-ia32.cc/codegen-arm.cc) when > one side or the other is literal. > > > Has monomorphic & megamorphic inline caches, but no polymorphic inline > caches (see e.g. MONOMORPHIC in globals.h). > > I'm not that bothered by the lack of PICs; for inlining most of the benefit comes from just detecting the monomorphic case, but it sounds like they aren't doing that anyway, at least yet. Having just monomorphic and megamorphic is interesting, perhaps they don't have inline caches at all (other than the degenerate monomorphic case). The monomorphic form would still give the speed advantages of inline-caching for the common case, and if it ever changes they could lock and update to the megamorphic form, which would be reasonable because it only ever happens once per send site and would avoid the need to do any locking for the small polymorphic case if the VM is shared. PICs don't buy much performance anyway; I've always thought they were a bit overrated. In fact I have often thought that Strongtalk might be improved by eliminating PICs and doing basically what they doing. It would be slightly slower, but would eliminate a lot of complexity. > I see no evidence of adaptive optimization/speculative inlining, > performance counters et al. Seems to generate stubs to defer code > generation. So perhaps some deferred optimization is done at send/link > time, but its not obvious to me. > > > There are counters, but I think this is for understanding the dynamic > behaviour, not yet for optimization. > > Lack of a bytecode intermediate form is disappointing. The big question is whether they can still do any kind of mixed-mode execution without it. Perhaps they interpret the AST directly and use the counters you saw to do 'hotspot' compilation. If not, that sounds like it would be a problem for big code bodies, since if they have to compile any code that is executed, they would have the same kind of code blowup that was a big problem in Self, although that was exacerbated by the verbose code generated by the non-optimizing compiler. Even if space isn't a problem, compiling everything that runs would take time, although perhaps they think that is hidden by the page load pause. Well, it sounds like they aren't doing anything radically advanced or magical. Kind of mind-boggling that Strongtalk is more advanced than anything else after nearly 15 years. I keep expecting people to catch up, but I guess the complexity is the obstacle. -Dave --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~--- ------=_Part_51919_25462557.1220641781144 Content-Type: text/html; charset=ISO-8859-1 <div dir="ltr">Hi Eliot, sorry for the delay in answering, I am traveling overseas.<br><br><div class="gmail_quote">On Wed, Sep 3, 2008 at 9:57 AM, Eliot Miranda <span dir="ltr"><<a href="mailto:[email protected]">[email protected]</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr"><div class="gmail_quote"><div>Hi David,</div><div><br></div><div> I spent some time reading the code yesterday. Here's what I could glean</div> <div><br></div><div><br></div><div><p style="margin: 0px; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; font-size: 14px; line-height: normal; font-size-adjust: none; font-stretch: normal;"> Thread model: the standard, multi-threaded with only one active thread at a time, i.e. the standard combination of a green thread VM architecture with native threads, as seen in Strongtalk. Different threads must use a lock on the entire VM to use it. There is a preemptive scheduler to share the VM between threads waiting on the lock.</p> <p style="margin: 0px; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; font-size: 14px; line-height: normal; font-size-adjust: none; font-stretch: normal; min-height: 17px;"></p></div> </div></div></blockquote><div>That's interesting; green threads I expected but the preemptive scheduler for sharing the VM sounds cool. But I hope that doesn't mean they can't actually schedule different VM instances concurrently.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr"><div class="gmail_quote"><div><p style="margin: 0px; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; font-size: 14px; line-height: normal; font-size-adjust: none; font-stretch: normal; min-height: 17px;"> <br></p> <p style="margin: 0px; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; font-size: 14px; line-height: normal; font-size-adjust: none; font-stretch: normal;">Parses direct to an AST.</p> <p style="margin: 0px; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; font-size: 14px; line-height: normal; font-size-adjust: none; font-stretch: normal; min-height: 17px;"><br></p> <p style="margin: 0px; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; font-size: 14px; line-height: normal; font-size-adjust: none; font-stretch: normal;">Generates native code directly from AST.</p> <p style="margin: 0px; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; font-size: 14px; line-height: normal; font-size-adjust: none; font-stretch: normal; min-height: 17px;"><br></p> <p style="margin: 0px; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; font-size: 14px; line-height: normal; font-size-adjust: none; font-stretch: normal;">No bytecode intermediate form.</p> <p style="margin: 0px; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; font-size: 14px; line-height: normal; font-size-adjust: none; font-stretch: normal; min-height: 17px;"><br></p> <p style="margin: 0px; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; font-size: 14px; line-height: normal; font-size-adjust: none; font-stretch: normal;">In-lines simple arithmetic ops (see codegen-ia32.cc/codegen-arm.cc) when one side or the other is literal.</p> <p style="margin: 0px; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; font-size: 14px; line-height: normal; font-size-adjust: none; font-stretch: normal; min-height: 17px;"><br></p> <p style="margin: 0px; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; font-size: 14px; line-height: normal; font-size-adjust: none; font-stretch: normal;">Has monomorphic & megamorphic inline caches, but no polymorphic inline caches (see e.g. MONOMORPHIC in globals.h).<br> </p> <p style="margin: 0px; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; font-size: 14px; line-height: normal; font-size-adjust: none; font-stretch: normal; min-height: 17px;"></p></div> </div></div></blockquote><div><br>I'm not that bothered by the lack of PICs; for inlining most of the benefit comes from just detecting the monomorphic case, but it sounds like they aren't doing that anyway, at least yet. Having just monomorphic and megamorphic is interesting, perhaps they don't have inline caches at all (other than the degenerate monomorphic case). The monomorphic form would still give the speed advantages of inline-caching for the common case, and if it ever changes they could lock and update to the megamorphic form, which would be reasonable because it only ever happens once per send site and would avoid the need to do any locking for the small polymorphic case if the VM is shared. PICs don't buy much performance anyway; I've always thought they were a bit overrated. In fact I have often thought that Strongtalk might be improved by eliminating PICs and doing basically what they doing. It would be slightly slower, but would eliminate a lot of complexity.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr"><div class="gmail_quote"><div><p style="margin: 0px; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; font-size: 14px; line-height: normal; font-size-adjust: none; font-stretch: normal; min-height: 17px;"> <br></p> <p style="margin: 0px; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; font-size: 14px; line-height: normal; font-size-adjust: none; font-stretch: normal;">I see no evidence of adaptive optimization/speculative inlining, performance counters et al. Seems to generate stubs to defer code generation. So perhaps some deferred optimization is done at send/link time, but its not obvious to me.</p> <p style="margin: 0px; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; font-size: 14px; line-height: normal; font-size-adjust: none; font-stretch: normal;"><br></p><p style="margin: 0px; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; font-size: 14px; line-height: normal; font-size-adjust: none; font-stretch: normal;"> There are counters, but I think this is for understanding the dynamic behaviour, not yet for optimization. </p> <p style="margin: 0px; min-height: 17px;"></p></div></div></div></blockquote><div><br>Lack of a bytecode intermediate form is disappointing. The big question is whether they can still do any kind of mixed-mode execution without it. Perhaps they interpret the AST directly and use the counters you saw to do 'hotspot' compilation. If not, that sounds like it would be a problem for big code bodies, since if they have to compile any code that is executed, they would have the same kind of code blowup that was a big problem in Self, although that was exacerbated by the verbose code generated by the non-optimizing compiler. Even if space isn't a problem, compiling everything that runs would take time, although perhaps they think that is hidden by the page load pause.<br> </div></div>Well, it sounds like they aren't doing anything radically advanced or magical. Kind of mind-boggling that Strongtalk is more advanced than anything else after nearly 15 years. I keep expecting people to catch up, but I guess the complexity is the obstacle.<br> <br>-Dave<br></div><br> --~--~---------~--~----~------------~-------~--~----~<br> You received this message because you are subscribed to the Google Groups "Strongtalk-general" group. <br> To post to this group, send email to [email protected] <br> To unsubscribe from this group, send email to [email protected] <br> For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en <br> -~----------~----~----~----~------~----~------~--~---<br> <br> ------=_Part_51919_25462557.1220641781144--