[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
|