[gambit-list] Help With Memory

Joel J. Adamson <adamsonj@email.unc.edu> adamsonj at email.unc.edu
Wed Sep 24 10:44:54 EDT 2008


>>>>> "DR" == David Rush <kumoyuki at gmail.com> writes:

    DR>  And if you capture a continuation via call/cc and then recurse
    DR> you start getting into the allocation issues.

I've removed all instances of call/cc from the application code ---
there may be some lingering in my genetics library that I'll check for.

I still get the memory killing behavior at large population sizes, even
though I've reduced another parameter to 1 (thus reducing the number of
iterations by 50 times).  It worked at 1000, but when I increased "N" to
2000, my workstation entirely locked up after about half an hour.  There
must be something totally different going on, or like I said it would
just take longer.

    DR> 1) they help ensure the typological correctness of your
    DR> program. Yes this is Lisp and all, but it does mean that really
    DR> smart compilers (e.g. Stalin) can better optimize your code

On the issue of using different compilers: outside of using the Gambit-C
FFI, how locked in to Gambit-C am I?  How many of Gambit's non-standard
features are implemented in other compilers (e.g., Bigloo, Stalin,
Larceny)?  Does anybody use a different compiler and if so, what's your
porting strategy?

    DR> Have you traced this program to see where it's allocating
    DR> heavily?
    >> 
    >> What's the best way to do that?

    DR> Errr...print out data structures at key points of the program
    DR> and see if they're bigger than you expect?

Okay: I thought you were talking about a specific debugging procedure (duh).

    >> Thanks a heap ;)

    DR> Don't make me Pun-ish you.

Thanks a stack,
Joel
-- 
Joel J. Adamson
University of North Carolina at Chapel Hill
CB #3280, Coker Hall
Chapel Hill, NC 27599-3280

Before you reply to this email, please read
http://www.unc.edu/~adamsonj/email-howto.html



More information about the Gambit-list mailing list