This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Re: Guile is becoming as fast as rep
Keisuke Nishida writes:
|> Wow, that's really impressive (especially as the rep vm has been around
|> longer than yours..)
|
|My VM is still under development, though...
yes, that's what I meant, I'm starting to run out of things to optimize
now, but your vm probably still has untapped potentional :-)
|(It lacks module support, exception handling, function inlining, etc.)
I haven't got function inlining to work across module boundaries yet
(for ML paper, see http://citeseer.nj.nec.com/context/297296/0)
|
|> I've not been trying to make interpreted code run fast, so I'm not
|> surprised by this..
|
|Why don't you dynamically compile the user input and run it?
|I mean I think your repl could be written as something like
|
| (define (repl)
| (print (vm-exec (compile (read)))))
|
|Your compiler is too slow? Or your VM does not have debugging
|facilities? Hmm, maybe I should read the source. Probably
|there are something I can steal :)
I've considered doing this, but compiling ahead of time is more
efficient for the things I normally use the system for..
But you're right, the compiler isn't blindingly fast (peephole
optimization of the bytecode takes most of the time), but I've never
considered this a problem (except when bootstrapping from the
interpreter :-)
And yes, there is no support for debugging compiled code, I've never
found this a problem either. Errors can still print backtraces, and
that's usually enough to fix the problem,
John
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user