axiom-developer
[Top][All Lists]
Advanced

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

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


From: Gabriel Dos Reis
Subject: Re: [Axiom-commit] [Axiom-developer] Re: SF.net 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 README.build-improvements 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)

Yes.

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