<br><br><div class="gmail_quote">On Fri, Nov 27, 2009 at 1:49 PM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2009/11/27 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br>
<div class="im">> Hi Nicholas,<br>
> here are my timings from Cog. Only the ratios correspond since the<br>
> source file is of a different size, my machine is different, and Cog runs at<br>
> very different speeds to the interpreter. With that in mind...<br>
> t1 is nextLine over the sources file via StandardFileStream<br>
> t2 is nextLine over the sources file via BufferedFileStream<br>
> t3 is next over the sources file via StandardFileStream<br>
> t4 is next over the sources file via BufferedFileStream<br>
> Cog: an OrderedCollection(11101 836 9626 2306)<br>
> Normalizing to the first measurement: 1.0 0.075 0.867 0.208<br>
> Your ratios are 1.0 0.206 4.827 0.678<br>
><br>
> I'd say BufferedFileStream is waaaaay faster :)<br>
><br>
<br>
</div>Impressive.<br>
I presume every Smalltalk message is accelerated while primitive call<br>
remain expensive...<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
><br>
> P.S. your timing doit revealed a bug in Cog which is why it has taken a<br>
> while to respond with the results :) The doit's temp names are encoded and<br>
> appended to the method as extra bytes. The JIT wasn't ignoring these extra<br>
> bytes, and your doit just happened to cause the JIT to follow a null pointer<br>
> mistakenly scanning these extra bytes. So thank you :)<br>
><br>
<br>
</div>Oh, you discovered my secret for finding bugs: (bad) luck<br></blockquote><div><br></div><div>:) :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
Nicolas<br>
</font><div><div></div><div class="h5"><br>
> On Wed, Nov 18, 2009 at 3:10 AM, Nicolas Cellier<br>
> <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>
>><br>
>> I just gave a try to the BufferedFileStream.<br>
>> As usual, code is MIT.<br>
>> Implementation is rough, readOnly, partial (no support for basicNext<br>
>> crap & al), untested (certainly has bugs).<br>
>> Early timing experiments have shown a 5x to 7x speed up on [stream<br>
>> nextLine] and [stream next] micro benchmarks<br>
>> See class comment of attachment<br>
>><br>
>> Reminder: This bench is versus StandardFileStream.<br>
>> StandardFileStream is the "fast" version, CrLf anf MultiByte are far<br>
>> worse!<br>
>> This still let some more room...<br>
>><br>
>> Integrating and testing a read/write version is a lot harder than this<br>
>> experiment, but we should really do it.<br>
>><br>
>> Nicolas<br>
>><br>
>><br>
>><br>
><br>
><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br>