This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Jim Blandy <jimb@red-bean.com> writes: > I can't run Stalin on my UltraSPARC (64Mb) or my Linux box (32Mb), > because it runs out of memory compiling this program: > > (define (fact n) > (if (<= n 1) 1 > (* n (fact (- n 1))))) > > (write (fact (read))) > (newline) > > ... so I can't actually say what code it generates, but I'll bet it > doesn't do anything particularly spectacular with this code. I'll bet > it does exactly what every other Scheme compiler with a type > inferencer does. I've had problems running the latest stock binary for Linux too. But I've built it & tested it in the past. > Don't get me wrong --- it sounds really cool, as if someone had > finally put together all the right optimizations in one package. My > point is that there's no magic going on here, and that the real > problem --- efficient compilation to a run-time that uses the full > numeric tower --- is still an unsolved problem, and for good reason. Yes and no. I have advocated correct bignum support, and I do like having the full numeric tower. On the other hand, for numerical work I certainly am satisfied with inexacts. If, for numerical work I have to restrict myself to inexacts to get blistering speed, I can certainly live with that. Remember also that in scheme inexacts are allowed to be contagous. If one starts by assuring that all the numbers used in the computations are inexact, then the compiler can treat everything as inexact, and use unboxed native representations for numbers & arrays of numbers. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il