2010/1/11 Gianrico Fini <gianrico.f...@gmail.com>: > On 11 Gen, 03:14, Bill Hart <goodwillh...@googlemail.com> wrote: >> Ha ha, very funny cheater. Your function is only faster for full limbs!! > > Well, Fermat numbers with k>=5 use full limbs!
Yes, true. But that just illustrates that this particular test is not a good one for showing off our function, which does not just work with full limbs. > >> What do you think the other hundred or so lines of mpn/generic/mulmod_2expp1 >> do? > > I do not know, I did not read the function, nor I know what it is > supposed to do: it is not documented. > > The benchmark should shows how a library is with an application, I > optimised the application. > >> Everyone notice what a silly cheater gian is. Ha ha ha ha!!! > > Why? Is there something undocumented or unfair? Please explain. I > explained. > > If I wanted to cheat I would have used some internal functions; e.g. > mpn_fft_mul. I didn't. > >> More seriously, what do you think you have just proved? > > That the right 10 lines could do a fair application, instead of an > application written with an as slow as possible substitute for an > internal function. It is not a substitute for our internal function, as far as I know. It only works for full limbs. > > fermat_prime_p.c is not a possible application using the library, it's > an application written in such a way that it is fast only with a > specified version of the library. > > Tell someone to write a simple function performing Peppin's test, > using mpn_mulmod_2expp1 only if available. Will he write something > like my patch or something like the mess using mpz? No, I agree with that. For Peppin's test our function is not needed. > >> The powm idea was ok. But this is rubbish. > > Why? Please explain. > >> Why don't you put your creative energy to good use and write some >> decent code. The actual mpn_mulmod_2expp1 function in MPIR is a sad >> joke. > > We finally agree! That function is a joke! I'm talking about the real mpn_mulmod_2expp1 function in mpn/generic, not the stupid alternative in the benchmark. > But your cheating_benchmark > still use it as a club on other libraries! :D > >> Someone like you could probably do a good job of speeding it up >> for real. The same for the mpn_mulmod_2expm1 function. Or are you just >> all mouth? > > I'll follow your suggestion, but... forgive me, I'll not do it for > your project. Guess why? > > Gian. > > -- > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To post to this group, send email to mpir-de...@googlegroups.com. > To unsubscribe from this group, send email to > mpir-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mpir-devel?hl=en. > > > >
-- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
