Re: v8 first impressions
"David Griswold" <[email protected]> Thu, 11 Sep 2008 09:48:08 -0700
| Newsgroups | gmane.comp.lang.smalltalk.strongtalk |
|---|---|
| Message-ID | <[email protected]> |
------=_Part_115897_5493522.1221151688462 Content-Type: text/plain; charset=ISO-8859-1 Hi Marc, On Tue, Sep 9, 2008 at 1:12 AM, prunedtree <[email protected]> wrote: > > [...] > 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. I'm not sure how that would work. What you suggest sounds pretty much like a standard inline-cache. With type-feedback the form of the send needs to record the encountered polymorphism of the send; the kind of send you suggest can't be distinguished from a truly megamorphic send. Such a send would be slower for megamorphic sends, since the cache will usually miss, so it is wasted time that is eliminated in Strongtalk, as well as eliminating the updating of the cache. The question is, when the cache misses, what do you do? If you don't convert such sends into the megamorphic form (with no inline-cache), how do you detect megamorphic sends? I am sure you are right that slightly polymorphic sends would be slower without PICs or an inline cache, however I have my doubts how important they are statistically. As you pointed out, many of them become monomorphic after inlining and/or customization; my intuition is that the resulting distribution is highly bi-modal and dominated by monomorphic and megamorphic, with not much in-between. As you also pointed out, since boolean control structures are hardcoded, that eliminates the biggest source of slightly polymorphic sends. In essence, this is a > degenerate PIC of length 1, and I guess it seems natural to allow > bigger PICs. As I said above, I don't think it really is like a PIC, since a PIC upgrades itself to the next higher arity send when a cache miss occurs, and doesn't just do a megamorphic send and update the cache. Allowing bigger PICs of variable size I think is a big mistake we made in Strongtalk, since suddenly you get a lot of extra complexity for very little payoff. Variable size PICs cause fragmentation in the PIC area, requiring compaction (which isn't done in the current system but would eventually be necessary). I think eliminating variable size PICs would be a great improvement. But there are two different ways that could be done, depending on how important sends of arity 2 are, which as I said is not clear. If they are not that important, which I suspect is true, then separately allocated PICs could be eliminated entirely, and we could use a degenerate inline 1 element PIC for the monomorphic case, which patches to a cache-less megamorphic send on cache miss. Nothing else would be needed. If it turns out that sends of arity 2 are too important not to optimize, then 2 element allocated PICs could be retained. That is still much simpler than now, since all PICs would have the same size, and no fragmentation would occur, and thus no compaction would be needed. > [...] 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. In fact, that is the first experiment I tried when Strongtalk went open source, but it didn't appear to work the easy way, and I didn't follow up on it. I tried just lowering the constant that determines the max PIC size to 1 and 2, but I got no change at all in the benchmarks I tried, and the inlined code structure didn't appear to change. I suspect that the constant is probably also hardcoded somewhere, perhaps in the assembly code, so just changing the constant wasn't enough :-(. But I agree that actually getting the experiment to work shouldn't be very hard and would be very, very interesting. -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_115897_5493522.1221151688462 Content-Type: text/html; charset=ISO-8859-1 <div dir="ltr"><div class="gmail_quote">Hi Marc,</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Tue, Sep 9, 2008 at 1:12 AM, prunedtree <span dir="ltr"><<a href="mailto:[email protected]" target="_blank">[email protected]</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>[...]<br> Dave: regarding PICs, I'm pretty sure it's critical that you have a<br> monomorphic send attempt followed by a megamorphic send for the case<br> where a call site is nearly-monomorphic. </blockquote><div><br></div><div><div>I'm not sure how that would work. What you suggest sounds pretty much like a standard inline-cache. With type-feedback the form of the send needs to record the encountered polymorphism of the send; the kind of send you suggest can't be distinguished from a truly megamorphic send. Such a send would be slower for megamorphic sends, since the cache will usually miss, so it is wasted time that is eliminated in Strongtalk, as well as eliminating the updating of the cache. The question is, when the cache misses, what do you do? If you don't convert such sends into the megamorphic form (with no inline-cache), how do you detect megamorphic sends?</div> <div><br></div><div>I am sure you are right that slightly polymorphic sends would be slower without PICs or an inline cache, however I have my doubts how important they are statistically. As you pointed out, many of them become monomorphic after inlining and/or customization; my intuition is that the resulting distribution is highly bi-modal and dominated by monomorphic and megamorphic, with not much in-between. As you also pointed out, since boolean control structures are hardcoded, that eliminates the biggest source of slightly polymorphic sends.</div> </div> <div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In essence, this is a<br> degenerate PIC of length 1, and I guess it seems natural to allow<br> bigger PICs. </blockquote><div><br></div><div><div>As I said above, I don't think it really is like a PIC, since a PIC upgrades itself to the next higher arity send when a cache miss occurs, and doesn't just do a megamorphic send and update the cache. Allowing bigger PICs of variable size I think is a big mistake we made in Strongtalk, since suddenly you get a lot of extra complexity for very little payoff. Variable size PICs cause fragmentation in the PIC area, requiring compaction (which isn't done in the current system but would eventually be necessary).</div> <div><br></div><div>I think eliminating variable size PICs would be a great improvement. But there are two different ways that could be done, depending on how important sends of arity 2 are, which as I said is not clear. </div> <div><br></div><div>If they are not that important, which I suspect is true, then separately allocated PICs could be eliminated entirely, and we could use a degenerate inline 1 element PIC for the monomorphic case, which patches to a cache-less megamorphic send on cache miss. Nothing else would be needed.</div> <div><br></div><div>If it turns out that sends of arity 2 are too important not to optimize, then 2 element allocated PICs could be retained. That is still much simpler than now, since all PICs would have the same size, and no fragmentation would occur, and thus no compaction would be needed.</div> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[...] It would actually be<br> interressing to benchmark strongtalk with various settings (no PICs,<br> PICs limited to various sizes). If PICs of length 1 are found to be<br> enough, then the PICs code could indeed be much more simple.</blockquote><div><br></div><div><div>In fact, that is the first experiment I tried when Strongtalk went open source, but it didn't appear to work the easy way, and I didn't follow up on it. I tried just lowering the constant that determines the max PIC size to 1 and 2, but I got no change at all in the benchmarks I tried, and the inlined code structure didn't appear to change. I suspect that the constant is probably also hardcoded somewhere, perhaps in the assembly code, so just changing the constant wasn't enough :-(. But I agree that actually getting the experiment to work shouldn't be very hard and would be very, very interesting.</div> <div><br></div><div>-Dave</div></div></div></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_115897_5493522.1221151688462--