gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] Re: load


From: Camm Maguire
Subject: [Gcl-devel] Re: load
Date: 21 Nov 2006 11:22:15 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

Robert Boyer <address@hidden> writes:

> Below is what I get following your advice.  Here, the old
> self-proclaiming by Nqthm has been entirely turned off, I believe, by
> the hack of changing #+AKCL to #+AKCLL in the function
> PROCLAIM-NQTHM-FILE in nqthm.lisp.
> 
>    % 4
>    GCL (GNU Common Lisp)  2.7.0 ANSI    Nov 20 2006 17:20:56
>    ...
>    >(load "nqthm.lisp")
>    ...
>    >(time (let ((si::*disable-recompile* t)) (compile-nqthm)))
>    ...
>    ;; Finished compiling ppr.o.
>    real time       :     82.580 secs
>    run-gbc time    :     43.880 secs

My informal yardstick is that I'd like to keep run-gbc <= child run
time.  Of course this varies a lot with the source, but here we still
have a bit of work to do.  General question -- if gcl becomes as
capable someday as gcc in the quality of its output, but has the
additional burden of type inferencing which is absent in C, is it
reasonable to expect it to take as much time as gcc does?

>    child run time  :     34.260 secs
>    gbc time        :      1.950 secs
>    #P"/v/filer2/boyer/nqthm-2nd/nqthm-1992/ppr.o"
>    ...
>    >(time (let ((si::*disable-recompile* t)) (load-nqthm)))
>    ...
>    real time       :      4.290 secs
>    run-gbc time    :      4.190 secs

Note this is still larger than the 2.6.7 loads.  Why? -- the source of
each function is installed, and the signature of each function and its
callees is checked against a global hash table to detect conflicts.
Would be nice to make this faster too, but it appears as a 10%
effect.  The major improvement would be to use hash-tables instead of
lists for the callees and callers.

>    child run time  :      0.000 secs
>    gbc time        :      0.000 secs
>    ...
>    >(time (si::do-recompile))
>    ...
>    real time       :     88.340 secs
>    run-gbc time    :     38.850 secs
>    child run time  :     44.760 secs
>    gbc time        :      1.030 secs
>    NIL
>    >
> 
> That is a lot better than 10 minutes.  However, load by itself is still
> incredibly slow.  For example:
> 
>    % 4
>    GCL (GNU Common Lisp)  2.7.0 ANSI    Nov 20 2006 17:20:56
>    ...
>    >(load "nqthm.lisp")
>    ...
>    >(time (load-nqthm))
>    ...
>    real time       :    119.550 secs
>    run-gbc time    :     37.000 secs
>    child run time  :     73.880 secs
>    gbc time        :      1.310 secs
> 
> I want to know how to get the compiler to do its job once and forall.
> What we see here is that load has essentially become the compiler.
> 

There is yet another trick available akin to the older Schelter
mechanism, but it requires static sources.  Once the above is done
once, output the proclaims into a sys-proclaims file and load that
before compiling.  There should be no recompilation necessary, but
there may be, which would indicate a weakness.  Right now the compiler
simply overrides any user proclaims -- it should type-and then into
its own result with a warning.  I'll look into getting this in too. 

I'm not sure if falling back to a two stage compile process with a
generated proclaims in between is a good idea or not.  Most comments
I've heard indicate that it is too fragile, at least at present, as
one always has to remember to update the proclaims when the sources
change. 

Effectively, this is what a with-compilation-unit would do
automatically, and faster too as it would do the gcc part only once
(but may do pass1 several times).  I wonder how many people would know
to use it, though.  Still this appears the way foward at the moment.

Take care,


> Thank you.
> 
> Bob
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

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