[gambit-list] Gambit's Linking Model

Guillaume Cartier gcartier at jazzscheme.org
Wed Jun 13 21:45:07 EDT 2007

Thanks Marc. These results are *very* interesting!

2 questions:

1- Will Gambit do as good a job in optimizing the code if I package my 
application as a bunch of .o1 files than if I had compiled them together 
in one executable?
2- If the answer to 1- is yes, then the only remaining thorn is to have 
to actually untar the .o1 files. Almost all modern languages like Python 
(.pyc), Java (.class), ... enable code distribution inside compressed 
archives which is really nice and easy for the developer and for the end 
user (it would annoy me if Mercurial upon install extracted it's 300+ 
.pyc files to my hard disk instead of keeping them in a neat library.zip 
file). Do you think something could be done to load the .o1 files 
directly from an archive? This could be a wonderful code distribution 
mechanism for Gambit too.


Marc Feeley wrote:
> Hash: SHA1
> On 13-Jun-07, at 5:36 PM, Guillaume Cartier wrote:
>> Hi everyone,
>> Unfortunately, I think I have stumbled upon a major problem for my
>> project with the linking model of Gambit / Scheme's lack of
>> specification for linking code.
>> For my applications I absolutly need the ability to be able to load code
>> selectively. If I understand correctly, the Gambit linking model is that
>> all classes compiled into a .exe are loaded upon launching the .exe so
>> that cannot do for me.
>> The only alternative I see is the use of .o1 loadable code but is it
>> reasonable to dynamically load like 1000+ .o1 files?
> To evaluate how "reasonable" this is I wrote a script to generate 1000 
> .scm files.  Each contains a dozen Scheme functions which compile down 
> to a 54 KB dynamic library (.o1 file).  According to "nm" each file 
> contains about 36 KB of executable code, so that's a total of 36 MB of 
> code (which is probably an order of magnitude larger than a big 
> application).
> I then wrote the following file (go.scm):
> (load "mod-000000.o1")
> (load "mod-000001.o1")
> ...
> (load "mod-0000999.o1")
> (pp (fn-000047 0))
> And loaded it into the Gambit interpreter running on a MacBook Pro.  
> Here's the timing of a few runs:
> % time gsi go.scm
> 10865
> real    0m1.868s
> user    0m0.353s
> sys    0m0.450s
> % time gsi go.scm
> 10865
> real    0m0.895s
> user    0m0.328s
> sys    0m0.394s
> % time gsi go.scm
> 10865
> real    0m0.899s
> user    0m0.326s
> sys    0m0.387s
> You can see that the second and third runs are faster than the first 
> one, because the files have been loaded into the disk cache.  When the 
> number of .o1 files is lowered to 100 files the timing is:
> % time gsi go.scm
> 10865
> real    0m0.229s
> user    0m0.192s
> sys    0m0.034s
> So it takes about one second of real time to load 36 MB of executable 
> code distributed in 1000 .o1 files and about a quarter of a second of 
> real time to load 3.6 MB of executable code distributed in 100 .o1 files.
> I think that is reasonable.
>> Wouldn't launching
>> incur a huge penalty in speed / space vs a selfcontained .exe as every
>> .o1 is a full fleged dynamic library? Also, with this approach,
>> distributing to my clients a folder containing 1000 .o1 files is
>> everything but nice.
> Why is that a problem?  You just need to package your .o1 files in a 
> .tar.gz and have a package installer that unpacks the archive at the 
> appropriate place.  In fact that's essentially how the Snow framework 
> operates.
>> I could zip them together a bit like interpreted
>> languages like Python do but then I don't think Windows or Gambit or ...
>> can load .o1 files from a zip directly so I'd have to unzip them to a
>> temp folder which is again not very tempting.
>> Any help / thoughts really appreciated. This is criticaly for my using
>> Gambit for my project.
> I don't really see a problem with this (either performance or 
> convenience).
> Marc
> Version: GnuPG v1.4.3 (Darwin)
> iD8DBQFGcJY7//V9Zc2T/v4RAiL0AJ9QLgjly9E4r/W+NFctwnwQ4KfTQwCeM3DE
> bfN1+nv/IokEmLOBzGzmlh4=
> =lOk5

More information about the Gambit-list mailing list