Ha ha, very funny cheater. Your function is only faster for full limbs!!
What do you think the other hundred or so lines of mpn/generic/mulmod_2expp1 do?
Everyone notice what a silly cheater gian is. Ha ha ha ha!!!
More seriously, what do you think you have just proved?
The powm idea was ok. But this is rubbish.
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. 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?
Bill.
2010/1/11 Gianrico Fini <gianrico.f...@gmail.com>:
> When it will be stable and documented, it will make sense using it...
> But now I'm playing with the stable version. Try this ten-lines patch:
>
> --- mpir_bench_two/fermat_prime_p.c 2010-01-11 02:12:21.000000000
> +0100
> +++ mpir_bench_two/fermat_prime_p.c.orig 2010-01-11 01:47:44.000000000
> +0100
> @@ -109,16 +109,6 @@ fermat_prime_p (unsigned long k)
> xp[0] = 3;
> c = 0;
> for (i = 1; i < k2; i++)
> -#ifdef NEED_MULMOD
> - if (c != 0) { /* -1^2 = 1 */
> - MPN_ZERO (xp, n); xp[0] = 1; break;
> - } else if(n+1==BITS_TO_LIMBS(k2+1)){/*Full limbs? Silly if in
> loop,but I want short patch.*/
> - mpn_mul_n(yp, xp, xp, n); /* Or better a mpn_sqr_n :-P */
> - c = mpn_sub_n(xp, yp, yp+n, n);
> - c = mpn_sub_1(xp, xp, n, c);
> - /* Avoid to be slowed down by the cheaters!!! */
> - } else
> -#endif
> {
> if (c != 0)
> c = 3; // as we are squaring , dont need to do this ,
> as for Pepin
> test it doesn't matter
>
> ....the old score for GMP4 on my laptop with your
> cheating_fake_benchmarks was:
> Program fermat (weight 1.00)
> 8 => 1657
> 10 => 83.6
> 12 => 2.52 => 70.4, 50.3
> After this (simple, isn't it?) patch they are:
> Program fermat (weight 1.00)
> 8 => 12414
> 10 => 280
> 12 => 7.60 => 298, 213
> And... surprise, MPIR is SLOWER!
> Program fermat (weight 1.00)
> 8 => 9241
> 10 => 230
> 12 => 6.03 => 234, 167
>
> Am I using any undocumented function in the 10 lines above? Or doing
> something very complicated? No, I'm simply avoiding the fake mpz
> implementation of your CHEATING fake_benchmark!
>
> Gian.
>
> On 11 Gen, 01:18, Bill Hart <goodwillh...@googlemail.com> wrote:
>> Hey, the GMP 5 library now has a version of our mpn_mulmod_2expp1.
>> It's also undocumented I believe, but we can now use it in our timing.
>> That should give GMP a good speedup for this.
>>
>> When this test was written, such a function did not exist in GMP.
>>
>> The GMP 5 library is just a few days old. Give us a chance to catch up!
>>
>> Bill.
>>
>> 2010/1/10 Gianrico Fini <gianrico.f...@gmail.com>:
>>
>> > It didn't took me so much time as I feared to understand why the use
>> > of bench_two on GMP4.3 and MPIR1.3 (on my 32-bit CPU) gave so strange
>> > results...
>> > GMP4.3 was (slightly) faster than MPIR1.3 for all tests, expect two
>> > where it was terribly slower: fermat and mersenne. The overall score
>> > says:
>>
>> > GMP4.3 => 136, 97.2
>> > MPIR1.3 => 145, 104
>>
>> > I.e. the bench_two test I downloaded from mpir.org says that yes, for
>> > many application GMP is faster, but there are some (two) where it is
>> > by far slower... so, globally, MPIR is 6% better than GMP.
>>
>> > It sounds strange, doesn't it?
>>
>> > Well, go and look into the code, the tarball is available from the
>> > main page of MPIR, you can download it, unpack it and... before you
>> > use it, please READ THE CODE!
>>
>> > The two very interesting test files are: fermat_prime_p.c,
>> > mersenne_prime_p.c .
>>
>> > Let's start from the first one: fermat_prime_p.c
>>
>> > At the beginning you can find:
>> > #ifndef __MPIR_VERSION
>> > // we are gmp
>> > #define NEED_MULMOD
>> > #elif __MPIR_VERSION < 1 || (__MPIR_VERSION == 1 &&
>> > __MPIR_VERSION_MINOR < 3)
>> > #define NEED_MULMOD
>> > #endif
>>
>> > ...you will see, this means: if someone is testing GMP or a version of
>> > MPIR before 1.3, be _as_slow_as_possible_. The reason? This way MPIR
>> > will look like being fast :-D
>>
>> > The "application" is very simple, it performs a "Pepin's Test for k"
>> > i.e. test if "3^((F_k-1)/2) == -1 mod F_k", where "F_k = 2^(2^k)+1".
>>
>> > How would you write such an application? You would probably think you
>> > can use the documented function mpz_powm...
>> > The test doesn't do this, because this could be fast on libraries
>> > different from MPIR-1.3, and the goal is to be _slow_... so it will
>> > use a loop and the _undocumented_ function mpn_mulmod_2expp1. This is
>> > a test to see how the library perform with a typical application, and
>> > uses a function that NO application will use, for the simple fact that
>> > _it_is_NOT_documented!
>> > You can try:
>> > mpir-1.3.0$ grep -ri mulmod doc/mpir.*
>>
>> > Nothing, no answer, it is not documented at all...And if you are not
>> > using MPIR-1.3? will the test use something different? NO! It will
>> > perform the computation using an _as_slow_as_possible_ substitute for
>> > that function.
>>
>> > NO APPLICATION WILL EVER BE SO CRAZY, THIS IS NOT AN APPLICATION, IT'S
>> > A FAKE!!!
>>
>> > I'll not analyse the ridicule "substitute", I'll do for the next
>> > "application", because it is absurd exactly in the same way!
>>
>> > Next application: mersenne_prime_p.c
>> > Here the "application" uses the Lucas-Lehmer test on a Mersenne
>> > number, now the loop make sense, because it is not a simple
>> > exponentiation, but a sequence of squaring-subtract, to be performed
>> > modulo 2^p-1.
>> > How would you implement it? With some clever reduction using mpn_add_n
>> > or initialising the modulo once and then using it again and again...
>>
>> > But here, again, the main goal of the person who wrote this code was
>> > to show that his mulmod function was giving a tremendous speed up, so,
>> > again, the fake-application uses an undocumented function. Let us look
>> > at the line where it is used:
>> > mpn_mulmod_2expm1 (rp, xp, xp, k, tp); // mpn_sqrmod_2expm1 would be
>> > faster
>> > Note the comment, using sqr can be faster! Then read the fake,
>> > as_slow_as_possible, implementation that is used if you are measuring
>> > speed of something different wrt MPIR-1.3:
>>
>> > void mpn_mulmod_2expm1 (mp_ptr xp,mp_ptr yp,mp_ptr zp,mp_size_t
>> > k2,mp_ptr tp)
>> > {mpz_t x,y,z,m;mp_size_t n,tn;
>> > n=BITS_TO_LIMBS(k2);
>> > mpz_init2(y,k2);mpz_init2(z,k2);mpz_init2(m,k2);mpz_init2(x,2*k2);
>> > mpz_set_ui(m,1);mpz_mul_2exp(m,m,k2);mpz_sub_ui(m,m,1);
>> > MPN_COPY(y->_mp_d,yp,n);tn=n;MPN_NORMALIZE(y->_mp_d,tn);y-
>> >>_mp_size=tn;
>> > MPN_COPY(z->_mp_d,zp,n);tn=n;MPN_NORMALIZE(z->_mp_d,tn);z-
>> >>_mp_size=tn;
>> > mpz_mul(x,y,z);
>> > mpz_mod(x,x,m);tn=x->_mp_size;if(tn>n)tn=n;
>> > MPN_COPY(xp,x->_mp_d,tn);if(tn<n)MPN_ZERO(xp+tn,n-tn);
>> > mpz_clear(x);mpz_clear(y);mpz_clear(z);mpz_clear(m);
>> > return;}
>>
>> > The guy who wrote this fake application decided to implement the
>> > needed sqrmod with the slowest possible strategy. Directly using mpn?
>> > no, there is the risk to be fast:
>> > - let's allocate four mpz on the fly (this means for every iteration!)
>> > - let's recompute the modulus in mpz on the fly (it is constant for
>> > the full run and it is recomputed every iteration!!!)
>> > we should exploit the fact that this function will always be called
>> > with yp==zp, but again we run the risk to be efficient, and the author
>> > did NON want that, because this function is used for other libraries,
>> > to be compared with MPIR... and they must be slowed down! So, you
>> > perfectly know (read the comment above) that yp==zp, but
>> > - copy the memory _twice_ in _two_different_ new locations...
>> > This way mpz_mul will see two different pointers and will _NOT_ use
>> > sqr! Clever way to avoid any possibly faster primitive!!!
>> > - copy back the result (the third copy, to be repeated for any cycle!)
>> > - free the memory...(for the same variables that will be used
>> > [recreated] again in the next step).
>>
>> > It is quite obvious, if you read the code of this two functions that
>> > it was written with one goal in mind, show that any library without
>> > those two functions was slow... or, to be more exact, that any other
>> > library (i.e. not MPIR-1.3) was slow.
>>
>> > BUT THIS IS A FAKE!
>>
>> > As a conclusion, on my laptop, MPIR is able to be faster than GMP
>> > !!!!!!!!ONLY CHEATING!!!!!!!
>>
>> > You guys are very funny!!!! :-D
>> > Because the cheating is so evident that when your library is slower on
>> > all operation, the fake application is 3-4 times faster with your
>> > funny-library... and your benchmark is so.... ingenuous .... to
>> > conclude that overall the funny-fake-library is faster!!!!
>> > RIDICULOUS!!!!!
>>
>> > But now be serious, and confess... MPIR is not a library, it's a
>> > joke! :-D
>>
>> > AH AH AH AH!!!!
>> > Adios!
>>
>> > 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
>> > athttp://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.
>
>
>
>
--
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.
