[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!
--
Martin
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/
- Serious performance issues with 1.9.0, Martin Ward, 2009/07/16
- Re: Serious performance issues with 1.9.0, Neil Jerram, 2009/07/16
- Re: Serious performance issues with 1.9.0, Neil Jerram, 2009/07/16
- Re: Serious performance issues with 1.9.0, Martin Ward, 2009/07/16
- Re: Serious performance issues with 1.9.0, Ludovic Courtès, 2009/07/17
- Re: Serious performance issues with 1.9.0, Martin Ward, 2009/07/17
- Re: Serious performance issues with 1.9.0, Ludovic Courtès, 2009/07/17
- Re: Serious performance issues with 1.9.0, Martin Ward, 2009/07/19
- Re: Serious performance issues with 1.9.0, Andy Wingo, 2009/07/19
- Re: Serious performance issues with 1.9.0,
Martin Ward <=
- Re: Serious performance issues with 1.9.0, Andy Wingo, 2009/07/24
- Re: Serious performance issues with 1.9.0, Ludovic Courtès, 2009/07/20
- Re: Serious performance issues with 1.9.0, Andy Wingo, 2009/07/26