[squeak-dev] Faster FileStream experiments

Eliot Miranda eliot.miranda at gmail.com
Fri Nov 27 22:04:09 UTC 2009


On Fri, Nov 27, 2009 at 1:49 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

> 2009/11/27 Eliot Miranda <eliot.miranda at gmail.com>:
> > Hi Nicholas,
> >     here are my timings from Cog.  Only the ratios correspond since the
> > source file is of a different size, my machine is different, and Cog runs
> at
> > very different speeds to the interpreter.  With that in mind...
> > t1 is nextLine over the sources file via StandardFileStream
> > t2 is nextLine over the sources file via BufferedFileStream
> > t3 is next over the sources file via StandardFileStream
> > t4 is next over the sources file via BufferedFileStream
> > Cog: an OrderedCollection(11101 836 9626 2306)
> > Normalizing to the first measurement: 1.0 0.075 0.867 0.208
> > Your ratios are 1.0 0.206 4.827 0.678
> >
> > I'd say BufferedFileStream is waaaaay faster :)
> >
>
> Impressive.
> I presume every Smalltalk message is accelerated while primitive call
> remain expensive...
>

Exactly.  Or rather, the primitives which aren't implemented in machine code
are even slower to invoke from machine code than in the interpreter.
 Machine code primitives exist for SmallInteger + - / * // \\ % > >= < <= =
~=, for Float + - * / > >= < <= = ~=, for Object == at: ByteString at: and
for BlockClosure value[:value:value:value:].  Once I reimplement the object
representation I'll be happy to implement Object>>at:put:
ByteString>>at:put: Behavior>>basicNew & Behavior>>basicNew: which should
result in another significant step in performance.


> >
> > P.S. your timing doit revealed a bug in Cog which is why it has taken a
> > while to respond with the results :)  The doit's temp names are encoded
> and
> > appended to the method as extra bytes.  The JIT wasn't ignoring these
> extra
> > bytes, and your doit just happened to cause the JIT to follow a null
> pointer
> > mistakenly scanning these extra bytes.  So thank you :)
> >
>
> Oh, you discovered my secret for finding bugs: (bad) luck
>

:) :)


>
> Nicolas
>
> > On Wed, Nov 18, 2009 at 3:10 AM, Nicolas Cellier
> > <nicolas.cellier.aka.nice at gmail.com> wrote:
> >>
> >> I just gave a try to the BufferedFileStream.
> >> As usual, code is MIT.
> >> Implementation is rough, readOnly, partial (no support for basicNext
> >> crap & al), untested (certainly has bugs).
> >> Early timing experiments have shown a 5x to 7x speed up on [stream
> >> nextLine] and [stream next] micro benchmarks
> >> See class comment of attachment
> >>
> >> Reminder: This bench is versus StandardFileStream.
> >> StandardFileStream is the "fast" version, CrLf anf MultiByte are far
> >> worse!
> >> This still let some more room...
> >>
> >> Integrating and testing a read/write version is a lot harder than this
> >> experiment, but we should really do it.
> >>
> >> Nicolas
> >>
> >>
> >>
> >
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091127/9a1341c8/attachment.htm


More information about the Squeak-dev mailing list