[gambit-list] problem with load.

Marc Feeley feeley at iro.umontreal.ca
Wed Jun 20 08:01:55 EDT 2007


On 20-Jun-07, at 12:49 AM, naruto canada wrote:

> On 6/19/07, Marc Feeley <feeley at 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.scm

To get the heap usage (live data, etc), do:

    gsi -:h700000 -e '(gc-report-set! #t)' test.scm

> I 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




More information about the Gambit-list mailing list