On Fri, May 14, 2010 at 4:43 PM, Igor Stasenko <siguctua at gmail.com> wrote:

> On 15 May 2010 02:35, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> > The cardinal rule of running benchmarks is to compare apples to apples.
> >  You've compared apples to oranges, i.e. an optimized reimplementation of
> > WideString>>hash that eliminates the mapping of codes to characters,
> against
> > the vanilla Squeak implementation.  You need to at least compare the NB
> > implementation against
> > WideString methods for comparison
> > fastHash
> > | stringSize hash low |
> > stringSize := self size.
> > hash := ByteString identityHash bitAnd: 16rFFFFFFF.
> > 1 to: stringSize do: [:pos |
> > hash := hash + (self wordAt: pos).
> > "Begin hashMultiply"
> > low := hash bitAnd: 16383.
> > hash := (16r260D * low + ((16r260D * (hash bitShift: -14) + (16r0065 *
> low)
> > bitAnd: 16383) * 16384)) bitAnd: 16r0FFFFFFF.
> > ].
> > ^ hash
> > | s n |
> > s := (WideString with: (Character value: 16r55E4)) , 'abcdefghijklmno'.
> > n := 100000.
> > { [1 to: n do: [:i| s fastHash. s fastHash. s fastHash. s fastHash. s
> > fastHash. s fastHash. s fastHash. s fastHash. s fastHash. s fastHash]]
> > timeToRun.
> >  [1 to: n do: [:i| s hash. s hash. s hash. s hash. s hash. s hash. s
> hash. s
> > hash. s hash. s hash]] timeToRun. }
> >      #(829 1254)
> > ASo your measurements tell us nothing about a general comparison of NB
> > against the Squeak VM or Cog.  They only demonstrate (unsurprisingly)
> that a
> > loop summing integers in an array goes PDQ.  On the other hand my numbers
> > showed Cog 10x faster than the Squeak interpreter when executing exactly
> the
> > same bytecode.
>
> Yes, of course you're right.
> But i didn't compared it with Cog, because i can't.
> And NB is not for translating bytecodes into native code,
> it is for authoring a primitives using native code.
> So, my comparison is how faster it could be , if implemented primitively.
>
> I can only imagine, how faster the whole thing would be if we
> cross-hatch NB and Cog,
> where Cog will serve as a smalltalk optimizer , and NB will serve for
> manual optimizations
> for heavy numerical crunching :)
>

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.

best,
Eliot


> > best
> > Eliot
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100515/6bea4308/attachment.htm