texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Texmacs-dev] Performance of Guile Scheme vs librep Lisp


From: Karl Hegbloom
Subject: [Texmacs-dev] Performance of Guile Scheme vs librep Lisp
Date: Sat, 12 Nov 2005 03:43:42 -0800

A long time ago, I tried out the SCWM (scheme controlled window
manager), which had Guile Scheme as it's extension language.  It was
really slow, and difficult to use because of that.  Not long after that,
Sawfish, then called Sawmill, was released.  It is much faster than
SCWM, and very useable.  Soon after I mentioned this fact on the Guile
mailing lists, someone began work on a byte code virtual machine and
compiler for Guile.  For some reason, it is not part of the Guile
release right now.

It turns out that the reason for its performance superiority over Guile
is that rep has a byte compiler and virtual machine.  The VM is based on
a technique known as "indirect threading" that was developed for engines
driving portable Forth language implementations.

Guile does not have a byte code virtual machine.  Instead, it is a
tree-code evaluator.  This means slower execution and probably (I'm
guessing) greater memory consumption.

Like Guile, rep was designed to be an embedded extension language.  John
Harper, its author, started writing it to create his version of an
Emacs.  Later, he used it to implement the Sawmill window manager, now
known as Sawfish.  Rep has a fairly decent module system, is easy to
link to C programs, and has both a Lisp and Scheme personality.  There
is an evaluator for R4RS scheme as well as one for a lexically scoped
Lisp.  The main thing about it is that it's quick.  A lot faster than
Guile.

If TeXmacs is spending much time executing Scheme code, perhaps Rep
would be a better choice?  There may be other reasons for choosing it
that I am not completely aware of.  One may be the Gnome2 bindings for
it.

OTOH, if anyone ever finishes up the byte code engine for Guile, and
perhaps the GNU Lightning based JIT...  It will be fastest then.

-- 
Karl Hegbloom <address@hidden>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]