[Top][All Lists]

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

Re: [Axiom-commit] [Axiom-developer] Re: SVN: axiom: [266]branche

From: root
Subject: Re: [Axiom-commit] [Axiom-developer] Re: SVN: axiom: [266]branches/build-improvements/src
Date: Sat, 18 Nov 2006 03:14:20 -0500


> yes, it deletes the existing NRLIBs.  
> However, I'm not sure where whole SPAD needs to be recompiled, or only
> AXIOMSsys.   I believe it is AXIOMsys only.  In that case, we need to 
> keep the previous .fn and .data files for latter use.  And it should
> be planned ahead.

The function optimization stuff that Schelter and I worked on
requires two compiles. If the optimizing code is loaded and enabled
the first lisp compile has a side-effect output of .fn files. These
.fn files contain static type information that describes the types
of the lisp function call and arguments.

In order to optimize lisp code you:

 1) load the optimizer program (gcl_collectfn)
 2) enable the optimizer
 3) 1st compile the lisp function or file
 4) (lisp generates a .fn file)
 5) load the .fn file
 6) 2nd compile the lisp function or file

If the .fn files are loaded and a second compile is done then there is
a significant speedup of the generated code because the lisp compiler
can almost completely eliminate the function calling overhead.

In axiom this process is planned to be automated during the build 
process (see src/interp/Makefile.pamphlet around line 368). 

The idea is that during an axiom build you generate the .fn files
At the end of each subdirectory such as boot, interp, and algebra
you gather up the .fn files into a proclaims file. Thus the first
time you compile boot you gather up the .fn files into 
src/boot/boot-proclaims.lisp. The first time you compile interp
you gather the .fn files into src/interp/interp-proclaims.lisp.
The first time you compile the algebra you gather the .fn files
into src/interp/algebra-proclaims.lisp

The second time you build the system you can increase the speed
of the build and the speed of the compiled code because you have
cached the correct type information into these proclaim files.

This machinery is only partially built but you can see that it
is partially documented in the Makefile and the partial proclaim
files exist. (src/boot/boot-proclaims, src/interp/interp-proclaims)
These need to be automatically built, cached in the source tree,
 and pre-loaded in the bootsys, interpsys, and axiomsys images.
Someone could create a branch to explore this machinery.

Notice the implications of this for the whole build mechanism.
Past builds create information used by future builds. This
already exists with the databases although there are still
bugs in that process. The end result is that builds are much
faster because two-pass processing can be eliminated and the
generated code is faster even though the build is shorter.

As you guys dive into the code you're beginning to overrun
areas where I've been working.


reply via email to

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