Re: CLN, GMP inputs

[Kevin Ryde]

Hans Aberg <address@hidden> writes:
> 
> GHC heavily abuses the GMP interface, to the point that even if GMP changes
> some functions to macros, GHC must be rewritten.

Anything documented as a function will remain a function, at least in
as much as taking a pointer to it will still work.  "extern inline"
code might be added to get plain calls to small functions inlined.

> Marcin Kowalczyk said that the use of small number representations were
> said to speed GHC up a lot. But he cold not tell if it was due to merely
> the accessing of GMP or due to the dynamic memory allocations. (My own
> guess is that if GHC is using say a two-space copying conservative GC
> (garbage collector), then memory allocations will be fast as long as they
> do not hit GC time; but when GC time is included, the average memory
> allocation time will not so short anymore.)

I might have guessed the opposite, that function call overheads and
memory allocations (if they occur repeatedly) would be the worst
slowdowns.  But no doubt it's best to fire up the profiler or do some
sample measurements and find out for sure.

> If GMP would add small number representations, that might even be a
> complication, because GHC might still need to convert to its internal
> format.

You know a possibility would be to reserve one bit of a 32-bit int as
a flag indicating it's not a number but a pointer to a bignum.  Then
maybe all arithmetic could be inlined and just have traps to special
code if a bignum is encountered.  But no doubt others smarter than me
have thought more about such things.