[ANN] Nile 0.9.0

Andreas Raab andreas.raab at gmx.de
Sun Jun 10 20:18:53 UTC 2007


Hi -

Damien Cassou wrote:
>> meaning there is a 20% difference within five runs which seems extremely
>> high for a microbenchmark that's just a primitive call. I think you'll
>> have to fix the benchmarks to give more consistent results if you want
>> to make any claims about relative speed improvements.
> 
> I noticed these changes too but I didn't understand why they happened.
> Can you help me investigate please?

I'm not entirely sure what's causing this but a couple of things to try 
are: Make it run for a longer period of time. Just runinng for ten 
seconds instead of one should reduce the variation quite a bit. Another 
thing to try is increase the priority of the benchmark process to run at 
"Processor timingPriority - 1". If neither of those help have a look at 
the GC statistics (do Utilities vmStatisticsReportString before and 
after and look at the delta); if they are wildly different it's a sign 
that something is wrong.

>> The lesson here is (at least for me) that after trying to wrap my brain
>> around the code in NSStringReader>>next: I'm willing to give up the
>> speed. A nice example for what can be done if you understand byte code
>> execution but by no means production code (pity the bugger who at some
>> point will need to understand that the "0-position" is required since
>> position cannot occur on the right-hand side of that expression ;-)
> 
> I do not understand this paragraph.

I just mean that I prefer code like this:

   prior := position.
   position := capacity min: position + amount.
   size := position - prior.

over code like this:

   size := 0 - position + (position := capacity min: position + amount)

(and yes, it's equivalent ;-) The latter is a real brain-teaser if you 
don't have the former to compare it to, in particular that "0 - position 
+ X" is equivalent to "X - position(before X executed)".

And although the latter will be faster, I strongly prefer the former.

>> > nextPut:
> So, the primitive is always failing?  Why?  String new:100 now
> creates a byteString.  Is it the case that the primitive is still
> checking for an instance of * String * in the Stream's collection?

I don't know (but it's a great little exercise for someone who wants to 
learn about the Squeak VM and a bit about optimization).

> In fact, these benchmarks were done to verify that Nile was at least
> as fast as Squeak. I didn't want people to complain because Nile was
> slower and this was due to traits... Now, I can say that Nile is as
> fast as Squeak even with the better design.

Yes, I think given the benchmarks it's completely fair to say that Nile 
is definitely on par with what we currently have. To be honest, 
everything else would have come as a big surprise to me which is why I 
looked at these benchmarks more carefully - the numbers you posted 
seemed to indicate that there is a *major* speed advantage in the 
microbenchmarks (>40%) and I was simply surprised to see such large numbers.

> I would really appreciate help to improve Nile. Don't forget you can
> always commit directly if you want to;
> http://www.squeaksource.com/Nile/ is writeable by anybody.

Thanks, but I was really only interested in the benchmarks. I suspected 
that there is something to learn with these numbers and indeed there is 
(like primNextPut: failing).

Cheers,
   - Andreas




More information about the Squeak-dev mailing list