Re: [Chicken-hackers] [PATCH] More efficient numbers integration through "scratchspace"

[Peter Bex]

On Mon, Apr 20, 2015 at 07:59:56AM -0400, John Cowan wrote:
> Peter Bex scripsit:
> 
> > Except for the fact that this causes the needed stack space is bigger,
> > resulting in more minor GCs even for code that doesn't need these numeric
> > types.
> 
> How can that be?  If the code doesn't use them, they aren't on the stack,
> so they can't cause more minor GCs.

The generated C simply sets aside a fixed amount of memory in a buffer
local to the function.  For each "inline_allocate" function we declare
a fixed amount of memory that it uses.  When the C function gets
generated, we simply sum all those memory amounts together and that's
set aside in the buffer, regardless of whether it's used.  We can't
allocate exactly what we need, because it's stack-allocated in the
caller, and if you return from the called inline function, its own
stack space gets destroyed.

You should really study how the compiler operates before asking such
basic questions, because this is pretty fundamental to CHICKEN's
operation, but I'm having a hard time explaining it right now.

> > I don't understand how this would work and why it will be needed.  If you
> > need flonum behaviour, you can simply convert to inexact before making
> > your calculations.
> 
> Yes, indeed.  But if your existing code expects (/ 884279719003555
> 281474976710656) to return 3.141592653589793 and then to continue to
> do flonum arithmetic after that, it will not be happy allocating two
> bignums and a ratnum instead.  (Silly example, but there are non-silly
> ones out there.)  Existing Chicken code has been able to count on this.

That's not a problem, as we've already decided that CHICKEN 5 is an
incompatible breaking change.  Also, this code wouldn't be portable to
other Schemes either, so it will be so CHICKEN 4-specific it will have
to be ported anyway.  In the process, it will become more portable to
other implementations, so that's an added bonus.

> > The compiler cannot make the decision to use inexact numbers for you:
> > that depends on the application and the domain-specific nature of the
> > calculations you're performing, I would say.
> 
> Which is exactly why a switch is needed to restore the old behavior
> for backward compatibility.  This does not mean shutting off bignums
> and ratnums, just not creating them as a result of fixnum operations.
> Arguably the most important of the two is not creating ratnums
> unexpectedly.

I disagree.  Attempting to bend over backwards to support old code
doesn't sound very productive to me.  Users will have to make quite
some changes to port CHICKEN 4 code to CHICKEN 5 anyhow.  This is a
relatively small thing to change, even if it can be very subtle in
some cases.

Cheers,
Peter

signature.asc
Description: Digital signature