-[ Wed, Oct 12, 2011 at 10:54:11AM -0400, John Lewis ]---- > I don't understand while Guile is so slow. According to these > benchmarks > http://www.cs.utah.edu/~mflatt/benchmarks-20100126/log3/Benchmarks.html > GNU Guile is running about a order of magnitude slower than Bigloo, > Chicken, Gambit, Ikarus, Larceny, MIT, and Racket(PLT) with most task.
Bigloo, Chicken and Gambit compiles to native code (through C). I can't tell for the others. This simple fact certainly accounts for most of the difference. Also, some (Bigloo for sure, maybe others) have type annotations while guile currently have not (although this was discussed recently). Also, as guile now relies on bdwgc for the GC it might suffer from conservative GC (while other scheme might use a dedicated GC, which can additionally perform some life span analysis to reduce useless collection - IIRC Gambit does this... or is it Stalin?). bdwgc is certainly a big win with regard to code complexity, though. > the sluggishness of Guile > is going to make it impossible to use to for application development > no matter how Ubiquitous Guile currently is. If so, then there is no application written in Python, Ruby, Javascript... :-) Joking aside, maybe guile is too slow for writing whole apps in it, but it's primary goal is to be an extension language, a companion for another C/C++ program, or at best an orchestrator of business oriented code. So performance is not the primary objective. For instance, I'm using guile as an extension language for a low-level commercial product for which speed matters, and it's perfect for what it does (configuring the software, mostly). Using another scheme app would have been less convenient since they are less easy to link with C code.
