Mail Archives: djgpp/2000/06/21/10:57:18
I know that the operator loading of =,+,-,*, and / slows genprec
down by a factor 1.3. Previous versions of genprec looked a lot more
like gmp than the present version. In the present version
a=b+c;
was, in previous versions,
zadd(b,c);
zstore(a);
or, in gmp
mpf_add (a,b,c);
The previous version of genprec is about 1.5 times slower than gmp,
and 1.5 x 1.3 = 1.95 (i.e. 2). I thought perhaps that gmp has a
better algorithm for / and that would account for the 1.5 (since in
calculations to 512 significant figures +,- don't matter and * is
much more efficient than /) but tests show that is not the case.
That leaves only your explanation that C++ codes are inherently
slower than C codes.
I am pleased to hear that gmp is coming out with the elementary
transcendental functions soon. However, for me, complex numbers must
be covered because of the importance of complex variable theory in
two dimensional hydrodynamics. I must be able to write
a=exp(iz);
where a and z are multiple precision complex variables. Otherwise,
the codes becomes too long and tedious and too unreadable. I must
be able to manipulate power series with complex coefficients in
one line of code, as in genprec. Perhaps it is correct for gmp to
leave tasks that like to the user. Genprec is sort of my vision of
what a language ought to be able to do, but other users would no
doubt have a much different vision. Some things, like linear system
solving and polynomial solving are pretty general. No matter how
clumsy, they are in genprec.
Forgive this rambling.
- Raw text -