gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] Re: [Maxima] Maxima GCL init file update


From: Vadim V. Zhytnikov
Subject: Re: [Gcl-devel] Re: [Maxima] Maxima GCL init file update
Date: Fri, 12 Dec 2003 14:34:42 +0300
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.5) Gecko/20031006

Camm Maguire ?????:
Hi Vadim, and thanks!

1) As you know, we are working on making some of these out-of-the-box
   gcl defaults as well.  This init script will be just fine in any
   case.

Right, maybe we'll be able to incorporate _some_ of these
or similar defaults in gcl 2.6.1 but this init can be used
with older GCL versions as well.  In any case I just want to
have them in forthcoming Maxima 5.9.1 release whatever
situation will be with GCL 2.6.1.

2) If you can be a bit more specific about which tests, and even which
   routines or subsystems, are behind the "1.1-2" times slower figure
   you cite, it would be most helpful.  Even try my latest gprof
   patch, run a test which shows significant slowdown vs. CMUCL, and
profile it. I'd like to get this figure to about "0.8" or so :-).

Mostly tests with large polynomials - ratsimp, expand, factor.
On all these tests GCL is slower due to larger percent of GC
time even with new memory allocation parameters.
And I don't think that further allocation parameters
tweaking could give any serious performance boost
(only at the cost of large memory allocation which
is not the thing we want).
Further enhancement require more intricate
improvements like (1) generate less garbage as you
suggested (2) improve GC timing if there is any
possibility (profiling...).




Take care,

"Vadim V. Zhytnikov" <address@hidden> writes:


Hello!

I'm about to upload into CVS new maxima-init.lisp.
It affects GCL Maxima only and performs some
GCL memory allocation tuning providing significant
performance boot especially on very complicated
problems (up to factor of 10 and more).
According to my tests with such init file
GCL Maxima is just 1.1 - 2 times
slower than CMUCL Maxima.  New init file works
quite well with Maxima 5.9.0 as well.

But there is one issue I want to discuss.
Initial GCL Maxima memory footprint is now
about 11-13 Mb.  Partially due to larger
ANSI GCL image partially due to initial
memory preallocation. Is this is OK?
In principle one can reduce initial memory
footprint to 4-7Mb by removing initial
preallocation altogether but this slows Maxima
down by factor of 2 on small and middle
size problems.  Any ideas are greatly
appreciated.

New maxima-init.lisp:
============================================================
;; Pre-allocating memory and more aggressive allocate growth
;; parameters substantially improves GCL performance
#+gcl
(progn

  #+gmp (si::set-gmp-allocate-relocatable t)

  ;; If you really need smaller initial memory footprint
  ;; comment these pre-allocations out
  (si::allocate-relocatable-pages 400 t)
  (si::allocate 'cons   1000 t)
  (si::allocate 'fixnum 100  t)
  (si::allocate 'symbol 200  t)
  (si::allocate 'array  100  t)
  (si::allocate 'string 200  t)
  (si::allocate 'cfun   400  t)

  ;; It is not recommended to make hole size less than 1000
  (si::set-hole-size 4000)

  (si::allocate-growth 'cons    1 10000 66 33)
  (si::allocate-growth 'fixnum  1 10000 66 33)
  (si::allocate-growth 'symbol  1 10000 66 33)
  (si::allocate-growth 'package 1 10000 66 33)
  (si::allocate-growth 'array   1 10000 66 33)
  (si::allocate-growth 'string  1 10000 66 33)
  (si::allocate-growth 'cfun    1 10000 66 33)
  (si::allocate-growth 'sfun    1 10000 66 33)

  (si::allocate-growth 'relocatable  1 10000 66 33)
  ;(si::allocate-growth 'contiguous   1 10000 66 33)

  )
=====================================================


--
     Vadim V. Zhytnikov

      <address@hidden>
     <address@hidden>

_______________________________________________
Maxima mailing list
address@hidden
http://www.math.utexas.edu/mailman/listinfo/maxima







--
     Vadim V. Zhytnikov

      <address@hidden>
     <address@hidden>





reply via email to

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