Eduardo Cavazos wrote: > So what do the numbers mean? There are two tables > which are output each time.
Roughly speaking, the first table shows the percentage of time each procedure is executing its own code. The second table shows the percentage of time each procedure is executing its own code or is suspended while waiting for the result of some procedure it calls. Hence the percentages for the second table will always be at least as high as for the first table. Your profiles show that about 20% of the time is being spent in %flonum->bignum. I doubt whether your problem really needs any bignum arithmetic at all, so I suspect that you are using exact numbers for calculations that were intended to use inexact numbers. That, I think, is the most likely reason Larceny is running slower than Ypsilon. Interpreted systems often perform well on benchmarks that do a lot of bignum arithmetic, because there is no interpretation involved during the bignum calculations themselves. Furthermore Larceny's bignum arithmetic is known to be especially slow, so an interpreter can easily be faster than Larceny on a bignum-intensive benchmark. I'd suggest you go through your code and convert every arithmetic operation that should be taking inexact arguments into the corresponding flonum-specific operation. For example, change + to fl+. Then you'll get an exception every time an exact argument is passed to one of the flonum-specific operations, and that will make it easier for you to track down the exact numbers that (in all likelihood) are making the program run so slowly. The flonum-specific operations should be significantly faster than the generic operations, so the transformed program (after you have debugged it) should run faster in both Larceny and in Ypsilon. Will _______________________________________________ Larceny-users mailing list Larceny-users@lists.ccs.neu.edu https://lists.ccs.neu.edu/bin/listinfo/larceny-users
