Re: [Axiom-developer] RE: [Gcl-devel] compiler speed

[Camm Maguire]

Greetings!

"Page, Bill" <address@hidden> writes:

> Camm,
> 
> On Tuesday, March 16, 2004 11:28 AM you wrote:
> > 
> > Greetings!  I've been working on this a bit, and have not been able to
> > find any more errors, which is good!  I'd like to get the 10,000/8
> > case up to the 50k runs or so you did with clisp, but have discovered
> > that we have a performance issue in the compiler which scales
> > quadratically with the number of variables.  I've come up with a fix,
> > which reduces the GCL portion of the compile time for your forms of
> > size 10000 to a small fraction of its earlier value.
> > 
> > I'm debating with myself whether its good to commit into the stable
> > branch before release.  Compile speed is not a major issue in most
> > cases -- nevertheless I think it useful to be able to report some good
> > statistics on your random tester which apply to the stable branch.
> > ...
> 
> If your change would affect compile times for Axiom (for example),
> then I (personally) would place a high value in it.
> 

While I haven't finished my tests, the changes are bound to help, at
least somewhat.  They are most prominent when the number of variables
is large.  This having been said, I have confirmed that this issue is
not responsible for the single longest step of the axiom compile, that
of EXPEXPAN.spad.

The slowness of the compilation of this file is almost entirely due to
to the repeated calls to 'lengthenvec' in category.spad.pamphlet.  If
any recall, this was involved in the hasCategory bug of last year.
The function has two basic methods for achieving the lengthening -- if
the array is adjustable, try to adjust it, otherwise replace with a
newly allocated one.  The former call to adjust array will in turn
simply allocate a new array unless the array passed to it is
'displaced' to another one (i.e. shares the same storage) large enough
to accommodate the lengthening, in which case there is no copying.  

I cannot discern when lengthenvec is passed a 'displaced' array and
when not.  I know this is done at least sometimes, as this was the
cause of the hasCategory bug.  The slowdown of EXPEXPAN.spad, however,
is because the passed arrays are *not* displaced, and are
length-incremented by one each call, basically doing a tight loop
allocating and copying a 1k array, then copying again into a 1025
length array, and so on up to very large numbers.  this churns the
garbage collector for relocatable blocks, a sign which I earlier
mistook for bignum integer generation.

One can usually implement an effective caching by doing something like
the following:

(defun lengthenvec (v n)
  (if (adjustable-array-p v) 
        (let ((disp (or (array-displacement v) (make-array (+ 1024 n)))))
                (when (> n (length disp))
                        (setq disp (adjust-array disp (+ 1024 n))))
                (adjust-array v n :displaced-to disp))
    (replace (make-array n) v)))
;(defun lengthenvec (v n)
;  (if (adjustable-array-p v) (adjust-array v n)
;    (replace (make-array n) v)))

This does not work, as apparently there is already some displacement
in certain calls to this routine, with which this interferes.

Speaking of which, I cannot compile debugsys, at least as of my
20040128 tree.  Has there been recent work in this area?  

Anyway, suggestions appreciated.

Take care,

> The recent improvements to GCL on Windows are making me anxious
> to get back to looking at Axion for Windows.
> 
> You and the rest of the GCL team are doing great work!
> 
> Thank you.
> 
> Cheers,
> Bill Page.
> 
> 
> _______________________________________________
> Axiom-developer mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/axiom-developer
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah