|Bill Allombert on Wed, 6 Nov 2002 21:08:11 +0100|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: CVS branch gmp-kernel-2-2-5|
On Wed, Nov 06, 2002 at 02:06:40PM -0500, Igor Schein wrote: > On Wed, Nov 06, 2002 at 05:32:12PM +0100, Bill Allombert wrote: > > On Wed, Nov 06, 2002 at 04:50:52PM +0100, Karim BELABAS wrote: > > > On Wed, 6 Nov 2002, Bill Allombert wrote: > [snip] > > > > --- Lots of things need tuning/testing. > > > > > > Any comparison data so far ? > > > > The PARI benchmark is 50% worse with the GMP kernel :-( Once we have changed the makefiles so that you can use the asm level0 file with gmp, the GMP kernel is only 5% behind on the PARI benchmark, see previous mail. > Before I jump into testing, I'd like to know the long term outlook. > > Will GMP kernel *eventually* > a) replace PARI kernel In a sense, yes. We have an optimised asm kernel for few architectures and general inlining for fewer. On the other hand, gmp have asm support for an incredible number of CPU, and have loop written in asm. Unless someone volunteer to write a inlined asm PARI kernel for new cpus like ppc and ia64, the gmp will be a better long term solution. I do not thing we will remove the pari kernel, but it will become as deprecated as is now the m68K kernel. An alternative is to implement level0.h with longlong.h from GMP. It may allow us to have an asm level0 kernel for all arch supported by gmp. > b) be used in conjunction with PARI kernel to utilize strengths of > both kernels? Very difficult to implement, for various reasons, including kernel inlining. > c) be ( like now ) a separate entity and a user will have choice of > going with either kernel? I believe so. > Is GMP kernel expected to overall be faster than PARI kernel *after* > it's been *fully* implemented, crash-tested and polished? Currently it appears that PARI kernel is faster than GMP kernel for small input size. I have been told that one goal of current GMP was to try to reduce the overhead for small input. Cheers, Bill.