[Larceny-users] profiling spirales

[William D Clinger]

Eduardo Cavazos wrote:
> Yes, I was quite surprised to see bignum related procedures in the
> profile reports.

That was probably a performance bug in Larceny.  (See below.)

> Eh... I know that it's good to avoid bignum arithmetic where possible.
> But I didn't know that using exact numbers (i.e. integer literals) will
> throw Larceny into "bignum mode". Isn't there a middle ground for fixnums?

If x is an inexact real (flonum), then (exact x) is an exact
rational whose computation generally involves bignum arithmetic,
because IEEE double precision numbers have a 53-bit significand.

If x is an inexact integer in the fixnum range, however, then
Larceny could recognize that special case and avoid the bignum
arithmetic.  Larceny wasn't recognizing that special case.  As
of changeset:6062, it does.  That special case is now over
twice as fast as the general case.

For your program, you have to convert the inexact results of
a computation into the exact coordinates of a pixel.  If you
round the inexact results before you convert them to exact,
then you are exercising the special case.

> So to be sure, are you saying that if I have a literal '1' in my
> code, I should change it to '0.0'?

More likely to '1.0', but you have to be careful.  If the
constant is an input to a calculation using inexact numbers,
then the constant should be inexact.  If the constant is an
input to a calculation that should use exact numbers, then
the constant should be exact.

You had remarked earlier that "it's no fun to litter the
code with" exact->inexact, but you may need to do some of
that to avoid unnecessary mixed-mode arithmetic, which is
expensive.  On the other hand, it may be that all of the
bignum arithmetic was coming from Larceny's failure to
recognize the special case; if so, then the change I just
made will eliminate the bignum arithmetic.

Will