-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 13-Jun-07, at 9:45 PM, Guillaume Cartier wrote:
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?
Yes... if no declarations are used. If your code uses the declaration (declare (block)) then inter-procedural optimizations are possible (such as inlining) within that file. Of course if you want to be able to redefine functions (as seems to be the case for Jazz) then you cannot use this declaration.
There is a slight advantage with the single executable because the global variables can be statically resolved, but this is a very small factor in my experience.
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).
But what's the difference for the user in having the package in one "library.zip" file or in one *directory* "library" containing a bunch of .o1 files? This reminds me of the Mac OS format for applications. In Mac OS 9 an application is in a single specially formatted file which contains several "resources". In Mac OS X an application is in a hierarchically structured .app directory. So it seems the "trend" is away from specially formatted files!
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.
The problem is that the .o1 files are loaded with "dlopen" (Unix) and "LoadLibrary" (Windows), and these expect the file to be directly accessible on the file system. I am not aware of any workaround.
Marc