Speaking of heaps I can't get gambit to let me (make-vector 10000000) with any heap size...
% unlimit % gsi -:h4000000 Gambit Version 4.0 beta 22
(make-vector 10000000)
*** ERROR IN ##make-vector -- Heap overflow 1>
Any ideas?
On 6/20/07, Marc Feeley feeley@iro.umontreal.ca wrote:
On 20-Jun-07, at 12:49 AM, naruto canada wrote:
On 6/19/07, Marc Feeley feeley@iro.umontreal.ca wrote:
On 19-Jun-07, at 9:59 AM, naruto canada wrote:
gambit-c seems to have problem with "load". I was able to load a test file 26meg with petite and mzscheme, but crashes gambit-c. (gsi)
By "crash" do you mean a segment violation or a "heap overflow" message?
I think it's just out of memory, "top" showing fast increasing memory usage.
If it didn't output a "heap overflow" message, my guess is that Gambit is still computing but with such a large heap that it is very slow due to thrashing.
By my calculations it will require roughly 500 MB of RAM to load a 26
I think it takes more than 500M, I have 1G of memory, and the program crashes before loading.
You might be able to avoid thrashing on your machine by specifying a maximum heap size with the -:hXXX option. My test on a 1GB RAM machine seems to indicate that loading the 26MB file of integer sequences generates a peak of about 630MB of live data. So this should work:
gsi -:h700000 test.scmTo get the heap usage (live data, etc), do:
gsi -:h700000 -e '(gc-report-set! #t)' test.scmI know the problem can be got around by simply doing "cat code.sc| gsi". I don't know if it's possible to treat "load" simply as another input stream like petite or mzscheme.
No. Gambit's model is that files loaded by "load" are complete "modules". The module has to be parsed (to check for lexical and syntax errors) and macro-expanded before it can execute. This is so loading an interpreted file has (roughly) the same semantics as loading a compiled file.
What if someone needs to write to test cases, based on the execution of a large file then gambit-c won't be able handle it "in-code" sorta speak, it has to "cat" the test case after "code.sc", just not pretty but workable. anyway, it's not a serious problem.
I think a better approach is to treat the sequences as "data". Then you just need a small driver program that does:
(define (go) (with-input-from-file "sequences.dat" (lambda () (let loop () (let ((s (read))) (if (not (eof-object? s)) (begin (solve-seq s) (loop))))))))
(go)
Marc
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list