Tuukka Toivonen wrote:
> On Sun, 14 Oct 2001, Vadim V. Zhytnikov wrote:
>
> >Maxima 5.6 last CVS version + GCL 2.3.8beta3 (mp):
> >
> >expand((x+y+z)^300)$ 99.8 sec
> >ratsimp((x+y+z)^300)$ 11.8 sec
> >
> >Maxima 5.6 last CVS version + GCL 2.4.0 (gmp):
> >
> >expand((x+y+z)^300)$ 239.2 sec
> >ratsimp((x+y+z)^300)$ 18.7 sec
>
> Well, I'm quite puzzled by this. In the first place,
> I can't understand how these can be different at all?
> I can't see anywhere big integer arithmetic used in these
> examples.
>
> Could you show results from some benchmark that handles
> more big integers, such as 10000!
>
> --
> | Tuukka Toivonen <tuukkat@ee.oulu.fi> [PGP public key
> | Homepage: http://www.ee.oulu.fi/~tuukkat/ available]
> | Try also finger -l tuukkat@ee.oulu.fi
> | Studying information engineering at the University of Oulu
> +-----------------------------------------------------------
Finally mystery is resolved. The point is that GCL by default
allocates very little free space and it is very "lazy" in
allocating extra free space. It makes hundreds of garbage
collection before requesting some more memory.
Pre allocating memory on startup improves situation dramatically.
It is turned out that GCL 2.4.0 compiled with gmp support is
especially susceptible to the problem since it actively uses
cfun space for computation (as far as I understand without mp
this space isn't needed for usual computation but for
storing compiled functions code only).
So, to make GCL 2.4.0 with gmp run really fast one need
to make init.lsp which looks something like this
(progn
(si::allocate 'cons 20000 t)
(si::allocate 'fixnum 4000 t)
(si::allocate-relocatable-pages 10000 t)
(si::allocate 'cfun 5000 t)
(si::set-gmp-allocate-relocatable t)
)
The last two lines are essential for GCL compiled with gmp.
With pre allocated memory new results are as follows.
Maxima 5.6 + GCL 2.3.8beta3 (no gmp)
expand((x+y+z)^300)$ 44 sec
ratsimp((x+y+z)^300)$ 2.8 sec
Maxima 5.6 + GCL 2.4.0 (gmp)
expand((x+y+z)^300)$ 33 sec
ratsimp((x+y+z)^300)$ 1.6 sec
Thus gmp is really faster.
Vadim
--
[ Vadim V. Zhytnikov <vvzhy@mail.ru> <vvzhy@td.lpi.ac.ru> ]