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

[Peter Bex]

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.

Cheers,
Peter

perf-diff
Description: Text document

signature.asc
Description: Digital signature