[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