[Top][All Lists]

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

Re: Serious performance issues with 1.9.0

From: Martin Ward
Subject: Re: Serious performance issues with 1.9.0
Date: Mon, 20 Jul 2009 13:48:22 +0100
User-agent: KMail/1.8.2

On Sunday 19 Jul 2009 23:03, Andy Wingo wrote:
> Discussed here:
>   http://article.gmane.org/gmane.lisp.guile.devel/8882
> I'm working on a fix, hopefully within a couple of days.

Great! Let me know when it is ready, and I'll put it through
its paces for you.

> > Its a pity that you decided to write your own compiler instead
> > of continuing development with Hobbit :-(
> Hobbit is a whole-program compiler. Guile needs an incremental,
> embeddable compiler, with source information, and a repl, etc etc.
> Apples and oranges, to a rough approximation.

I needed to persuade Hobbit to compile files separately,
and found a couple of ways to do it:

Slow Solution: Ensure everything is defined as an OBJT by adding the line:
(define compile-new-proc-redefined #t) to one of the files in each Hobbit
compiler call. This ensures all new procs are typed as OBJT, which causes
some loss of efficiency.

Fast Solution: Add the names of all the procs defined in compiled files
to the list *special-scm->c-functions* after loading hobbit.scm but before
calling hobbit. These will then be treated as simple functions, even when they
are defined externally.

Compiling the whole of FermaT in a single file still gives a performance
boost of about 18%, but compilation takes a long time!

> Guile will be fast, but it will take a couple more years. In the
> meantime, it is getting better, but if you are in a hurry for some
> reason, perhaps some other scheme would suit your needs better.

For performance runs, speed is top priority. But if there is a bug
somewhere then the Hobbit compiled code just crashes with a segfault.
In this case, I re-run the failed process with FermaT debugging turned on:
this creates lots of checkpoints. I can then run the program from 
the last checkpoint under a Scheme interpreter with good debugging facilities.
This is where implementations such as Guile are useful.

But I don't see why the latest version of Guile has to be half as fast
as the previous version!


address@hidden http://www.cse.dmu.ac.uk/~mward/ Erdos number: 4
G.K.Chesterton web site: http://www.cse.dmu.ac.uk/~mward/gkc/

reply via email to

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