On Fri, Nov 27, 2009 at 1:49 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2009/11/27 Eliot Miranda <eliot.miranda@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@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
>>
>>
>>
>
>
>
>
>