This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Jeff Read <bitwize@geocities.com> writes: > Russ McManus wrote: > > > I would like to know more about what the guile team is planning for > > future releases. So far, I know that the focus for guile-1.4 is up to > > date documentation. > > I think the Guile team should pare it down a little. Make it a bit > smaller and a LOT faster (especially when it comes to startup, and > garbage collection). I was thinking, maybe you guys could borrow a few > ideas from Perl's or Siod's GC. After all that's done, you can then > attack the problems of bignum arithmetic and the numeric tower and that > stuff. I believe that if Guile is going to achieve its intended purpose > of being a ubiquitous, jack-of-all-trades embedded extensibility > language, we have to make it an attractive option for people who're > writing applications that could use such a language. A great way of > doing this is by improving performance in a few areas and keeping the > code size small. The code size of guile is not any bigger than perl, python and friends. If anything, with perl+libs or python+libs (and python especially isn't all that useful without 'em), they're much bigger than guile. A comparison: [greg /usr/local/lib]$ du libguile.so.4.0.0 412 libguile.so.4.0.0 [greg ~]$ du /usr/local/share/guile/ 391 /usr/local/share/guile [greg /usr/lib/perl5/i386-linux/5.00404/CORE]$ du libperl.a 719 libperl.a (I estimate the perl libs at somewhere near the python libs, though that may be very much under the actual size, it's hard to tell with the inline documentation of pods, and I just don't care that much about perl to get an accurate number). [greg /usr/lib/python1.5/config]$ du libpython1.5.a 1606 libpython1.5.a [greg ~]$ du -c /usr/lib/python1.5/*.pyc /usr/lib/python1.5/plat-linux-i386/ /usr/lib/python1.5/lib-dynload/ 2862 total I'm assuming both the perl and python libraries have debugging symbols, so they'd weigh in close to guile. Perl is mostly useful without the spare librarys, so they're about the same; python is pretty useless without the extra libraries, so it is, in fact, much larger than guile, and having to keep track of reference counts in extension c code is a pain in the ass. Even so, python is probably the closest to what guile wants (or should want) to be: it has a lot of available libraries to do damn near anything you want, and python itself is a very managable language, both for quick hacks and larger programs; perl may be fast, but it's not much more than obfuscated c code taylored for string processing, which is great for very small things, but can easily become a maintainance nightmare when it starts getting large. Tcl might be smaller, tcl+tk definately isn't (and how often is tcl used without tk?). So guile really isn't any larger than the other languages that are usually used for extensions. What needs to be improved is the gc (perl & python's gcs are ref-counting, so that's out; siod's gc isn't much different from guile's, and if I seem to recall reading somewhere that guile's gc is mostly based on siod's; the similarities are fairly obvious from looking at the code); the io (outside of gc, this is what's really killing startup); and the module system, which contributes both to the large startup time (there's a lot of module code to read), and somewhat slower evaluation. Of these, the gc and the io are being actively worked on (I think the io is, I know the gc is), and a module system revamp is planned for after 1.4 (documentation is JimB's current focus, and it is the most important element lacking in guile right now). In any case, if you put guile on equal footing with perl and python by compiling the init files, the startup time is very small. It isn't done with the distribution, partly because hobbit doesn't seem to work with 1.3, but mostly because JimB has some objections to it (I would think the objection is to glossing over the problems, rather than fixing them, and I agree (though it wouldn't matter if I didn't ;')), though for end users it's definately something to consider (it does make guile usable on low end hardware). > Note that I really know nothing about hacking together a Scheme > implementation, and many of you guys will probably know a lot better > what to do about the GC problem, ice-9, etc. I'm kind of talking out my > you-know-where here but I really think that being an extensibility > library, addressing these issues is kind of a priority. > > Oh, and why does it give me that IOT Trap error when I do read-line? Is > that a libc or egcs thing? > No idea. A gdb backtrace would probably be helpful for someone to find the bug, though. -- Greg