<br><br><div class="gmail_quote">On Tue, Jul 1, 2008 at 1:47 PM, <<a href="mailto:bryce@kampjes.demon.co.uk">bryce@kampjes.demon.co.uk</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Igor Stasenko writes:<br>
> 2008/6/30 Peter William Lount <<a href="mailto:peter@smalltalk.org">peter@smalltalk.org</a>>:<br>
> > Hi,<br>
> > Speed is always fun - fast programs and fast cars that is.<br>
> ><br>
><br>
> Moreover, if you looking for speed, just take a look at Huemul Smalltalk :)<br>
<br>
You could also look at Exupery itself, I think Exupery is about as<br>
fast as Huemul. Huemul was much faster until it got a few extra<br>
language features that cost performance. Exupery's been through the<br>
same loop, fast, add features, then add more optimisations to regain<br>
the speed.<br>
<br>
Bryce<br>
<br>
P.S. That's one reason I don't like the idea of a write protect bit in<br>
the object header. It adds yet another thing to check for every single<br>
write into an object. Small costs add up on common basic operations.</blockquote><div><br>Actually one can be clever about this. yes one has to check for inst var assignment. But for at:put: one can fold the check into other activities. For example, in my VisualWorks implementation the write-protect bit was put very close to and more significant than the size field in the object header.<br>
<br>An at:put: has to extract the size of the array for the bounds check. The size field might indicate an overflow size (for large arrays their size doesn't fit in the header size field and requires an additional word in front of the header to store the actual size. The overflow is indicated by the size field being at its maximum value or somethign similar).<br>
<br>So in at:put: code masks off the size field and the write-protect bit so that when the check is made for an overflow size a write-protected object appears to have an overflow size. So the check for write-protect is done only in the arm that fetches the overflow size. This makes the test free for most array accesses since most arrays are small enough to not need an overflow size (at least in VW).<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Write protection could be implemented using similar tricks to the<br>
write barrier. Then send optimisation will help reduce the costs when<br>
it's used. When it's not used, there's no cost.</blockquote><div><br>I don't understand this. Can you explain the write-barrier tricks and the send optimization that eliminates them?<br><br>I think per-object write-protection is very useful. Its very useful for read-only literals, OODBs, proxies (distributed objects), debugging, etc. Amongst Smalltalks I think VisualAge had it first and I did it for VW round about 2002. I did it again for Squeak at Cadence. In both the VW and Squeak cases the performance degradation was less than 5% for standard benchmarks. Its cheap enough not to be noticed and there's lots more fat in the Squeak VM one can cut to more than regain performance.<br>
<br>So unlike, say, named primitives for the core primitives, this is something I am in favour of. It is a cost well worth paying for the added functionality.</div></div>