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 _______________________________________________ Larceny-users mailing list Larceny-users@lists.ccs.neu.edu https://lists.ccs.neu.edu/bin/listinfo/larceny-users
