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

[Felix Winkelmann]

>>> Personally I'd be more than happy to take the performance
>>> hit on this so long as I can rely on fx operations and/or
>>> (declare fixnum-arithmetic) to recover the original performance.
>>
>> You can; I didn't change any of those.  The "fixnum mode" probably
>> still works, too (as in "(declare fixnum)"), but I didn't test it.
> 

I recommend to get rid of "fixnum-mode" - this brings up serious
problems in code that uses external libraries, similar to the case
when non-numbers code uses libraries that use numbers (and vice
versa).  Fixnum-mode will assume that all numbers are fixnums (without
checking for this). It is seldom used and only viable for small bodies
of code with carefully integrated libraries/eggs.

> 
> Also, with it all integrated and bugs kicked out, we will be free to
> look at micro-optimisations of the code in future; I'm assuming we may
> be able to do something with range analysis to prove the fixnuminess of
> some numbers, and specialisation on fixnums in future.

Micro-optimizations won't give much, as Peter said: the CPS calls are
what's expensive and there is no fast path that one could take. If, for
example one would implement "optimistic inlining" (as in the Feeley paper),
where one would rewrite 

  (+ x y)

into

  (let* ((tmp1 x)
         (tmp2 y)
         (tmp3 (##sys#fast-fixnum-+-that-checks-for-overflow x y)))
    (or tmp3 (##sys#slow-generic-+ x y)))

then the slow-call will be a CPS call, and the code transformed
accordingly, so nothing is won, because the speed advantage of fixnum
math is that we can avoid the CPS calls and cram more numerical
operations into a single CPS-converted function.

But - range-analysis is indeed a good idea. We could perhaps extend
the scrutinizer to track number-ranges for values and specialize
numerical operations using this information. So instead of just
tracking the type, one could track the minimum and maximum of a value
that is known to be a number and use fixnum-operations if the range is
known to be in that range. There is a paper[1] about doing static
analysis of numeric overflow which indicates that this is quite a
performance win. On the other hand, there is much less type
information in Scheme available, and it's not particularly fun to
extend the already rather complex scrutinizer...

Personally, I find the performance impact Peter reported unacceptable,
and something has to be done about it before we commit on
numbers-integration. But that's just _my_ opinion.


felix


[1] http://www.lexifi.com/ml2012/slides8.pdf