Re: [gambit-list] loc count
On 17-Feb-09, at 1:47 PM, lowly coder wrote:
Not impressed at all. In fact, why is Gambit so big? Why is there 100K LOC for the *.scm s? There doesn't seem to be many built in libraries. All for optimizing?
Don't ask why but why not! ;-) There are on the order of 200 procedures and special forms defined by R5RS. Gambit adds another 800. So there are lots of builtin features. About 50 KLOC are in the runtime system and 50 KLOC in the compiler. I've written a few small Scheme's in my career... for example picobit is really small (it can fit in less than 10K on an embedded system) and BIT is just slightly bigger but it implements almost all of R4RS. So my question to you... why are you not using BIT? That would be the best choice if you are worried about size and R4RS conformance. I suspect there are features of Gambit that you like and that make your life as a programmer simpler so you prefer using it to other Scheme systems. Perhaps one of - feature-full debugger (single-stepping, backtrace, descriptive error messages, error pinpointing, live repair, etc) - space and time efficient scalable thread system (how many languages do you know can manage millions of threads?) - full-featured I/O system integrated into the thread system - ability to mix compiled and interpreted code seamlessly and to load compiled code dynamically - ability to interface easily with C code - one of the many extensions (homogeneous vectors, networking, subprocesses, hash tables, pretty printing, readtables, serialization, etc) - complete numerical library with fast bignum operations - etc (check the README file) All of these things contribute to the "user experience" that people appreciate when using Gambit. You aren't confronted with these things when you first start using Gambit (and that's the way it should be)... you only see the simple > prompt. But these features are ready to be used when you are ready to use them. It is true that these things take code space, so that the gsi executable (essentially the Gambit runtime system) takes about 3 MB, but that compares favourably to many other language implementations (on desktops) and it takes only 15 milliseconds (real time) to start and exit, so it is lightweight enough to use for everyday scripting (on my computer that's about 3 times slower than /bin/sh, but still twice as fast as Scheme48 (which also has a 3 MB footprint) and about 30 times faster than mzscheme). So Gambit is not as "bloated" as you might think! Marc
Afficher les réponses par date
Do not feed the trolls! ;) On Tue, Feb 17, 2009 at 4:35 PM, Marc Feeley <feeley@iro.umontreal.ca> wrote:
On 17-Feb-09, at 1:47 PM, lowly coder wrote:
Not impressed at all. In fact, why is Gambit so big? Why is there 100K LOC for the *.scm s? There doesn't seem to be many built in libraries. All for optimizing?
Don't ask why but why not! ;-)
There are on the order of 200 procedures and special forms defined by R5RS. Gambit adds another 800. So there are lots of builtin features. About 50 KLOC are in the runtime system and 50 KLOC in the compiler.
I've written a few small Scheme's in my career... for example picobit is really small (it can fit in less than 10K on an embedded system) and BIT is just slightly bigger but it implements almost all of R4RS.
So my question to you... why are you not using BIT? That would be the best choice if you are worried about size and R4RS conformance.
I suspect there are features of Gambit that you like and that make your life as a programmer simpler so you prefer using it to other Scheme systems. Perhaps one of
- feature-full debugger (single-stepping, backtrace, descriptive error messages, error pinpointing, live repair, etc) - space and time efficient scalable thread system (how many languages do you know can manage millions of threads?) - full-featured I/O system integrated into the thread system - ability to mix compiled and interpreted code seamlessly and to load compiled code dynamically - ability to interface easily with C code - one of the many extensions (homogeneous vectors, networking, subprocesses, hash tables, pretty printing, readtables, serialization, etc) - complete numerical library with fast bignum operations - etc (check the README file)
All of these things contribute to the "user experience" that people appreciate when using Gambit. You aren't confronted with these things when you first start using Gambit (and that's the way it should be)... you only see the simple > prompt. But these features are ready to be used when you are ready to use them. It is true that these things take code space, so that the gsi executable (essentially the Gambit runtime system) takes about 3 MB, but that compares favourably to many other language implementations (on desktops) and it takes only 15 milliseconds (real time) to start and exit, so it is lightweight enough to use for everyday scripting (on my computer that's about 3 times slower than /bin/sh, but still twice as fast as Scheme48 (which also has a 3 MB footprint) and about 30 times faster than mzscheme). So Gambit is not as "bloated" as you might think!
Marc
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Jazz Scheme" group. To post to this group, send email to jazzscheme@googlegroups.com To unsubscribe from this group, send email to jazzscheme+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/jazzscheme?hl=en -~----------~----~----~----~------~----~------~--~---
Marc Feeley <feeley@iro.umontreal.ca> writes:
[...] (on my computer that's about 3 times slower than /bin/sh, but still twice as fast as Scheme48 (which also has a 3 MB footprint) and about 30 times faster than mzscheme). [...]
If you run mzscheme just like that (eg, mzscheme -e "(exit)") then you're loading stuff that is useful only for an interactive REPL. On my machine, this takes 169ms. But if you run it with mzscheme -I scheme/base -e '(exit)' then it goes down by a factor of 10 to 17ms. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life!
On 17-Feb-09, at 5:34 PM, Eli Barzilay wrote:
Marc Feeley <feeley@iro.umontreal.ca> writes:
[...] (on my computer that's about 3 times slower than /bin/sh, but still twice as fast as Scheme48 (which also has a 3 MB footprint) and about 30 times faster than mzscheme). [...]
If you run mzscheme just like that (eg, mzscheme -e "(exit)") then you're loading stuff that is useful only for an interactive REPL. On my machine, this takes 169ms. But if you run it with
mzscheme -I scheme/base -e '(exit)'
then it goes down by a factor of 10 to 17ms.
On my MacBook Pro, after a few iterations (to get the executables into the disk cache), I get: % time gsi -f -e '(exit)' < /dev/null real 0m0.012s user 0m0.005s sys 0m0.006s % time mzscheme -I scheme/base -e '(exit)' < /dev/null real 0m0.057s user 0m0.037s sys 0m0.014s So mzscheme is still a factor of 5 slower to startup and exit, and with Gambit you get all the REPL stuff included, which is really important if you want to be able to debug your code comfortably if something goes wrong (I would expect this to be an important point for most users given that this is an advantage of using Scheme... indeed the default in mzscheme is to include the REPL support). Anyway my point is simply that even though the Gambit runtime may seem big, it still is lightweight to use. Marc
participants (4)
-
Ali -
Eli Barzilay -
Jeremie Lasalle Ratelle -
Marc Feeley