[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: Gabriel Dos Reis
Subject: Re: [Axiom-commit] [Axiom-developer] Re: SVN: axiom: [266]branches/build-improvements/src
Date: 18 Nov 2006 10:14:55 +0100

root <address@hidden> writes:

| Gaby,
| > 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.

Yes, I understood that part.

My question is whether the optimization we're talking about
is about just AXIOMsys, or about whole AXIOMsys+algebras.

I don't believe Waldek's original patch planned any of those
optimizations.  And if it did, then it is not right.

I'll update to have this item as goal.

I've spent the last couple of days on the "new boot" translator.  I
uncovered a "package hell" bug that I'll fix in a moment.

Then, I'll move on making sure Humberto can build Axiom on MAC, then
support Axiom build without X, then work on the optimization stuff.
I'll be working on/off on documenting "new boot".


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

I'm not sure they should be cached in the source tree, as opposed to
being generated during the build.

| Notice the implications of this for the whole build mechanism.

Yes.  That is why I came to believe that the change in the behaviour
is accidental, as opposed to being intended.

| Past builds create information used by future builds. This
| already exists with the databases although there are still
| bugs in that process. 

I think the database part is what Waldek originally wanted to fix.

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

Hey, that is why it is opens source, right? ;-)

-- Gaby

reply via email to

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