gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] Re: the speed of load is still terrible


From: Camm Maguire
Subject: [Gcl-devel] Re: the speed of load is still terrible
Date: 21 Nov 2006 11:08:50 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

Robert Boyer <address@hidden> writes:

> >> What you want here (I think) is
> >>
> >>(let ((si::*disable-recompile* t)) (compile-nqthm)(load-nqthm))
> >>(si::do-recompile)
> >>(si::save-system "...")
> 
> Will try.
> 
> By the way, it is my opinion/suspicion that when I try such an approach
> with ACL2, the resulting system runs somewhat slower than if I just let
> the compiler compile everything it wants any time it wants.  This is
> nothing but a suspicion so far.
> 

OK, interested as always should this become evident.

> > mostly due to signature conflicts *between* files.
> 
> I agree.  But so what?  I think (dreaming again that I have the
> resources of DARPA) that the compilation process should get its thing
> done well once and for all, so that the load process is lightening fast.
> 

I agree this is a good goal.  And there may be something we can do
with with-compilation-unit as you describe below.  Effectively, this
would be by expanding 'compile-file into a 'compile-file of several
files, or the concatenation of same, enabling one to do all the pass1
and pass2 before ever hitting gcc.  This is a good idea, but the
question still arises on how to handle the load of different 'units'
into the same image, understanding all the while that the bigger the
units the better.

If in unit one one has

(defun foo (x) (bar x))

and in unit two

(defun bar (x) (declare (fixnum x)) (1+ x))

(each of which could be compiled in separate sessions), loading these
compiled into the same image will break foo, without an automatic
recompile at load time.  So while we can and should mitigate the
problem with bigger units, and better handling of the units
themselves, is it not true that there will always be some basic issue
like the above which needs to be handled at load time?

> > we thought this was a good idea
> 
> It is certainly a winning idea to have a smarter compiler even if it is
> slower.  But I don't think load should be any slower at all.  Perhaps I
> am engaged in a phoney, old-fashioned separation of things that should
> not be separated.
> 
> Perhaps what I ought to do is
> 
>   (with-compilation-unit (compile-nqthm) (si::save-system ...))
> 
> Perhaps GCL should define with-compilation-unit to invoke
> (si::do-recompile) before and after each of the arguments to
> with-compilation-unit.
> 

I like this.   Here is what with-compilation-unit should do AFAICT:

1) on each called compile file, do pass 1 only watching for new
   caller/callee signature conflicts within the set
2) at the end, if the above are found, do a repass1
3) loop over the processed forms, do pass2 and gcc.

The problem is that pass1 sets many special variables which are used
in pass2 and which are not so easily separable.  This should be
doable, but is not quite trivial.

Have you seen the repass1 warnings in the new gcl?  Basically, they
are triggered if a caller appears before a callee whose signature has
changed.  With this repass1, the single output of compile-file should
be loadable without recompile.  Did you get a chance to check this
with the original example file you sent me?

> > We should probably discuss this again to make sure this extra logic in
> > the compiler is actually useful on real code.
> 
> There is no doubt about this in my mind.  Your great work on the
> compiler in discovering proclaims is *very* much for the best.  But
> looking at Nqthm and ACL2 (and probably Macsyma) for supporting evidence
> here is probably not such a winning idea because those systems have
> benefitted from years of manual proclamation support from Schelter,
> Boyer, Moore, and Kaufmann.  What is unclear to me is whether the
> current interaction between the inference of proclamations and the
> invocation of recompilation is properly organized yet.  If the GCC phase
> of GCL compilation were as fast as the wind, this might be less of an
> issue, but it takes real time to get in and out of GCC at the moment.
> 

Agreed!

> Modifying my above proposal:
> 
> Perhaps GCL should define with-compilation-unit to invoke full
> proclamation discovery as would be done by do-recompile before and after
> each of the arguments to with-compilation-unit, but without actual calls
> to GCC, and then a full call of (do-recompile) before and after the last
> argument to with-compilation-unit.
> 

OK, I'll be looking into something like this, assuming that you agree
that this will mitigate, but not entirely remove the recompile on load
issue as described above.  If I am overlooking something here, as is
entirely likely, please let me know, as I'd love to be able to
dispense with all recompiles at load time -- I just don't see how to
do it while protecting the soundness of the result.

Take care,

> 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]