Bill Allombert on Tue, 13 Jan 2004 16:56:50 +0100


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

Re: some PARI kernel oddities/remarks


On Mon, Jan 12, 2004 at 11:37:41PM +0100, Bill Allombert wrote:
> Hello PARI-dev,
> 
> While trying to understand why Flx_sqr was so slow,
> I found some oddities in the kernel:
> 
> I suppose I will test NTL with my benchmark to start with.

Well here are the results:
[The host is much faster/reliable than  the previous one used]
NTL was compiled with GMP as multiprecision package.
NTL version 5.3.1
GMP version 4.1.2
PARI version 2.1.8 CVS
GCC 2.95.4 Debian
(I use pari-ntl interface to use NTL under GP)

i       : NTL  |Flx_sqr|  sqri |  GMP sqri
1       : 300  | 40    |  30   |  30
2       : 170  | 20    |  10   |  10
3       : 90   | 20    |  10   |  10
4       : 60   | 30    |  10   |  0
5       : 50   | 40    |  10   |  10
6       : 40   | 50    |  20   |  20
7       : 50   | 80    |  30   |  20
8       : 80   | 130   |  40   |  30
9       : 110  | 210   |  60   |  40
10      : 160  | 310   |  90   |  60
11      : 170  | 470   |  130  |  90
12      : 190  | 700   |  210  |  110
13      : 210  | 1080  |  310  |  120
14      : 310  | 1630  |  480  |  160
15      : 360  | 2440  |  750  |  170
16      : 1000 | 3720  |  1140 |  210

The NTL result  for i=1...3 are probably due to the overhead to convert
PARI vecsmall to NTL lzz_pX objects, hence are not significants.

NTL is much slower than GMP sqri here. It is much faster than PARI Flx_sqr
and became faster than PARI sqri for large degree, but it use asymptotically 
faster algorithms than Karatsuba.

In fact, even using evaluation in 2^64 instead of 2^32, GMP should be
twice faster than NTL.

Bill.