[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) |
Hi,
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
GCs.
The results are here: http://parenteses.org/mario/misc/numbers-benchmark/
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.
Mario
--
http://parenteses.org/mario
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Chicken-hackers] [PATCH][5] numbers integration,
Mario Domenech Goulart <=