[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH][5] numbers integration

From: Mario Domenech Goulart
Subject: Re: [Chicken-hackers] [PATCH][5] numbers integration
Date: Sat, 07 Mar 2015 19:58:01 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)


On Thu, 12 Feb 2015 23:39:14 +0100 Peter Bex <address@hidden> wrote:

> On Wed, Feb 11, 2015 at 02:14:52PM +0100, Peter Bex wrote:
>> [long story about way too complex performance hacks]
>> I'd have to seriously think about this and whether it's feasible at all.
>> It may not be worth it, due to the disadvantages I mentioned.
> Good news, everyone!
> I had another look at the compiled C output for some of the worst
> offenders in the chicken-benchmarks set.  I noticed that the
> scrutinizer misses a few opportunities to rewrite + into ##sys#+-2
> due to fact that the rewrite was  ((number number) (##sys#+-2 #(1) #(2))).
> That meant if the scrutinizer was unable to deduce that the arguments
> were both numbers, it would not rewrite at all, and fall back to the
> vararg version of "+" for which it needs to cons up a rest list and so on.
> But ##sys#+-2 is a generic procedure which needs to analyze its arguments
> anyway, and it signals a condition when it receives non-numeric arguments.
> So the rewrite can be changed to ((* *) (##sys#+-2 #(1) #(2))) without
> this changing anything.
> It turns out that the overhead of the generic vararg numeric operators is
> so much bigger that the total runtime of all the benchmarks with this
> small change in rewrites is only 30% slower than the non-numbers version
> of CHICKEN 5 master, instead of 100% slower!  See the attached performance
> difference between chicken-5 master and the current numbers integration
> version.  In fact, a few benchmarks are even slightly faster with the new
> code (but I can't really explain that)!
> I've pushed the version with the performance improvement to my
> "numbers-integration" branch (and fixed a nasty stupid bug in "eqv?" I
> found while working on this).
> I hope this performance difference is more acceptable.  I don't know if
> any more "low hanging fruit" like this is lurking in the code, but I'd
> like to invite interested parties to take a look and investigate.

I ran chicken-benchmarks and collected some data for variations of
nursery sizes, to see how the stack space influences the timings and

The results are here:

Things I've found interesting:

* The default nursery size on 64bit systems (1024KB) leads to the second
  worst performance of the set of nursery sizes used.

* The chicken-5-numbers performance with a 2MB nursery is about the same
  as chicken-5' with a 1MB nursery.

Best wishes.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]