[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] EXPEXPAN problem
Re: [Axiom-developer] EXPEXPAN problem
19 Mar 2004 07:33:41 -0500
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Greetings! The following versions of lengthenvec and make-init-vector
(defun lengthenvec (v n)
(if (and (array-has-fill-pointer-p v) (adjustable-array-p v)) (if (>= n
(array-total-size v)) (adjust-array v (* n 2) :fill-pointer n) (progn (setf
(fill-pointer v) n) v))
(replace (make-array n :fill-pointer t) v)))
(defun make-init-vector (n val) (make-array n :initial-element val
(in macros.lisp.pamphlet) cut out the lion's share of the gc problem
on this compile. 30min -> 7 min on my box. There is still some gc
churning in cons pages due to many calls to 'list' with small n. One
can likely improve things further with an appropriate (declare
(:dynamic-extent ...)) in the right place -- gcl will allocate such
lists on the C stack (very fast).
The above timings also incorporated another modification/performance
improvement to gcl, so the actual improvement over the present
situation is likely greater. This is a replacement of the single
(declare (integer count)) in gcl_seqlib.lsp with (declare (fixnum
count)). After a bit more testing I intend to commit this. I first
want to figure out why it got there in the first place.
root <address@hidden> writes:
> Excellent work. I think we can instrument the axiom calls to print
> out which array type we are using during the compile. Since the behavior
> happens every time and we now have a clue it shouldn't be too hard
> to fix (of course, there is no such thing as a simple job).
> re: debugsys. That image is only used to run interpreted versions of
> axiom for deep debugging. This might be a case where it is needed. I
> haven't been maintaining debugsys because I haven't needed it so it
> doesn't surprise me that it fails to build. The problem can't be deep
> though as the debugsys build is just a copy of the standard build but
> loads the .lisp rather than the .o files. The src/interp/Makefile
> makes a file called "makeint.lisp" in the obj/linux/interp directory
> which is the final script to build interpsys. I just hack that to
> load the .lisp files and call it debugsys.
> re: work. 100% of my time has been spent on documentation. I have an
> axiom--book--1 branch on tenkan where I'm making progress. I have
> requests out to several authors for copies of their research papers
> related to Axiom algebra and Nic has agreed to let me use his thesis
> work. I'll be creating the axiom--coerce--1 branch once that arrives.
> Fabrizio just sent me new algebra and I have to work it into the
> system. I'll put the code into the axiom--algebra--1 branch as soon
> as I doc it. I've also written up, for my own understanding, the
> axiom--crystal--1 design docs (I just got biffed about a conference on
> Mathematical Knowledge Management which is a dead-center target for
> Crystal but they need the paper by April and that can't happen).
> Stacked behind that are a bunch of changes to Axiom's latex output
> which needs work. I've been sending myself "fix-this" messages that
> are queueing up for work.
> Also on the queue is building a live-CD version of Axiom. Dirk has a
> Quantian CD (which contains quantitative software) based on Debian. I
> think it should be relatively easy (did I mention that there is no
> such thing as a simple job?) to add Axiom (and, by side-effect GCL) to
> the CD. This will give us a plug-and-play platform. I'd like to get a
> lot of the CA systems on one CD so we can use the CD as a basis for
> developing algorithms (literate ones :-)).
> I'm happy to see that you're making performance changes to lisp.
> Everything helps.
> I'll look at the array issue at the next logical break in the
> documentation work (probably the next chapter boundary).
> Axiom-developer mailing list
Camm Maguire address@hidden
"The earth is but one country, and mankind its citizens." -- Baha'u'llah