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