<br><br><div class="gmail_quote">On Fri, May 14, 2010 at 4:43 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@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><div></div><div class="h5">On 15 May 2010 02:35, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
> The cardinal rule of running benchmarks is to compare apples to apples.<br>
> You've compared apples to oranges, i.e. an optimized reimplementation of<br>
> WideString>>hash that eliminates the mapping of codes to characters, against<br>
> the vanilla Squeak implementation. You need to at least compare the NB<br>
> implementation against<br>
> WideString methods for comparison<br>
> fastHash<br>
> | stringSize hash low |<br>
> stringSize := self size.<br>
> hash := ByteString identityHash bitAnd: 16rFFFFFFF.<br>
> 1 to: stringSize do: [:pos |<br>
> hash := hash + (self wordAt: pos).<br>
> "Begin hashMultiply"<br>
> low := hash bitAnd: 16383.<br>
> hash := (16r260D * low + ((16r260D * (hash bitShift: -14) + (16r0065 * low)<br>
> bitAnd: 16383) * 16384)) bitAnd: 16r0FFFFFFF.<br>
> ].<br>
> ^ hash<br>
> | s n |<br>
> s := (WideString with: (Character value: 16r55E4)) , 'abcdefghijklmno'.<br>
> n := 100000.<br>
> { [1 to: n do: [:i| s fastHash. s fastHash. s fastHash. s fastHash. s<br>
> fastHash. s fastHash. s fastHash. s fastHash. s fastHash. s fastHash]]<br>
> timeToRun.<br>
> [1 to: n do: [:i| s hash. s hash. s hash. s hash. s hash. s hash. s hash. s<br>
> hash. s hash. s hash]] timeToRun. }<br>
> #(829 1254)<br>
> ASo your measurements tell us nothing about a general comparison of NB<br>
> against the Squeak VM or Cog. They only demonstrate (unsurprisingly) that a<br>
> loop summing integers in an array goes PDQ. On the other hand my numbers<br>
> showed Cog 10x faster than the Squeak interpreter when executing exactly the<br>
> same bytecode.<br>
<br>
</div></div>Yes, of course you're right.<br>
But i didn't compared it with Cog, because i can't.<br>
And NB is not for translating bytecodes into native code,<br>
it is for authoring a primitives using native code.<br>
So, my comparison is how faster it could be , if implemented primitively.<br>
<br>
I can only imagine, how faster the whole thing would be if we<br>
cross-hatch NB and Cog,<br>
where Cog will serve as a smalltalk optimizer , and NB will serve for<br>
manual optimizations<br>
for heavy numerical crunching :)<br></blockquote><div><br></div><div>Yes, this is a very cool direction. One effort should be AOStA/SIStA with Marcus, which will do adaptive optimization/speculative inlining a la Self & Hotspot. Being able to directly generate machine code with NB and not have to rely on the VM's naive code generator would allow machine-specific optimization ad excellent register usage. This could beat C. The difficulty here is in portability. Another more researchy direction would be a Klein approach where the Cog code generator is eliminated and replaced by NB, perfectly possible since Cog retains the interpreter which can be fallen back upon at any time. Again portability is an issue.</div>
<div><br></div><div>best,</div><div>Eliot</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
> best<br>
> Eliot<br>
><br>
<font color="#888888"><br>
<br>
<br>
--<br>
</font><div><div></div><div class="h5">Best regards,<br>
Igor Stasenko AKA sig.<br>
<br>
</div></div></blockquote></div><br>