I missed this yesterday... (I was sleepy)
On 11 Gen, 03:50, Bill Hart wrote:
> > 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.
You say the real function is a joke, and the alter
On 11 Gen, 04:44, Bill Hart wrote:
> Take as much time as you like. I think I would be quite impressed if
> it really works for all inputs and is relatively fast. I am not sure I
> could do it properly in 10 lines (unless they were exceptionally long
> lines). You have to do a bit shift and subtra
Take as much time as you like. I think I would be quite impressed if
it really works for all inputs and is relatively fast. I am not sure I
could do it properly in 10 lines (unless they were exceptionally long
lines). You have to do a bit shift and subtract, then deal with the
carries. Then there a
> What will you do if I win?
Ok... I'll know it tomorrow...
--
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...@go
On 11 Gen, 04:09, Bill Hart wrote:
> That's all rubbish and you know it. My reply to you, which you keep
> quoting, was in reply to you where you are talking about Case's
> benchmarks. It was in that context.
>
> You lied. You cheated. And you know it.
>
> Still waiting on those 10 line patches.
No problems. Sleep well.
And can I suggest that next time when you find a problem, discuss it
with us, rather than just calling us cheaters and ridiculing us.
There's something like 300,000 lines of code in MPIR (much of it from
the original GMP project - give credit where it is due). In such a
v
Oh, sorry
It's better for me to really go to bad.
'night!
Gian.
On 11 Gen, 04:11, Bill Hart wrote:
> Go back and read what I wrote.
>
> 2010/1/11 Gianrico Fini :
>
> > Hei! And what about the same mess on mersenne?
>
> > Gian.
>
> > On 11 Gen, 04:03, Bill Hart wrote:
> >> Hi Brian,
>
> >>
Go back and read what I wrote.
2010/1/11 Gianrico Fini :
> Hei! And what about the same mess on mersenne?
>
> Gian.
>
> On 11 Gen, 04:03, Bill Hart wrote:
>> Hi Brian,
>>
>> I don't know if you've been following the discussion with Gianrico
>>
>> but would it be possible to change the ben
That's all rubbish and you know it. My reply to you, which you keep
quoting, was in reply to you where you are talking about Case's
benchmarks. It was in that context.
You lied. You cheated. And you know it.
Still waiting on those 10 line patches. One to speed up nextprime and
one to implement a
Hei! And what about the same mess on mersenne?
Gian.
On 11 Gen, 04:03, Bill Hart wrote:
> Hi Brian,
>
> I don't know if you've been following the discussion with Gianrico
>
> but would it be possible to change the benchmark code so that when
> running the benchmark linked against GMP it
> it wasn't a fake argument at all. Your claim was that these Core 2
> benchmarks of Case's show that MPIR is only faster for multiplication
> above 10 digits and nothing else. But that is completely *false*,
> (his benchmarks didn't show that at all - you lied, and his benchmarks
> only includ
Hi Brian,
I don't know if you've been following the discussion with Gianrico
but would it be possible to change the benchmark code so that when
running the benchmark linked against GMP it prints something like:
"Warning: using (slow) *simulated* mpn_mulmod_2expp1" in the Fermat test."
A
2010/1/11 Gianrico Fini :
> Pardon?
>
>> Because it is not possible to come up with an efficient replacement
>> for mpn_mulmod_2expp1 using powm. The object of the benchmark was to
>> show what is possible using a new mpn function we had added and which
>> (at the time) was not available in GMP.
>
2010/1/11 Gianrico Fini :
> On 11 Gen, 03:14, Bill Hart 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 functi
Pardon?
> Because it is not possible to come up with an efficient replacement
> for mpn_mulmod_2expp1 using powm. The object of the benchmark was to
> show what is possible using a new mpn function we had added and which
> (at the time) was not available in GMP.
I do really not follow you... let
On 11 Gen, 03:14, Bill Hart wrote:
> Ha ha, very funny cheater. Your function is only faster for full limbs!!
Well, Fermat numbers with k>=5 use 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 kn
2010/1/11 Gianrico Fini :
>> With all due respect, I think you are vastly underestimating the
>> difficulty of providing robust, efficient, well tested code for your
>> benefit. There's tens of thousands of lines of code been put into the
>> MPIR library, and to just dismiss it all as a joke becaus
> With all due respect, I think you are vastly underestimating the
> difficulty of providing robust, efficient, well tested code for your
> benefit. There's tens of thousands of lines of code been put into the
> MPIR library, and to just dismiss it all as a joke because you found
> something which
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. Bu
2010/1/11 Gianrico Fini :
> It is not a matter of GMP5! on my laptop GMP4 is faster than MPIR, but
> your fake_bench_two claims it is slower!
> Why? Because it does not use the _documented_ (it is there from YEARS,
> not days) function mpz_powm!
> It does a _fake_ exponentiation using a _SL
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.0
+0100
+++ mpir_bench_two/fermat_prime_p.c.orig2010-01-11 01:47:44.0
+01
Your suggestion to instead use powm in GMP does indeed make things faster.
I used the powm function which has been in GMP for a long time (this
time using GMP 4.3.2 because powm itself has reportedly been improved
in GMP 5):
8 =>36422
10 => 1518
It is not a matter of GMP5! on my laptop GMP4 is faster than MPIR, but
your fake_bench_two claims it is slower!
Why? Because it does not use the _documented_ (it is there from YEARS,
not days) function mpz_powm!
It does a _fake_ exponentiation using a _SLOOW_ stupid trick
instead of squ
Also, the reason we haven't optimised things for your machine is that
at present none of our build farms contains such a machine, none of
the developers owns one, none of our friends own one. It is just very
hard to get hold of one.
It is *absolutely impossible* for us to optimise the assembly
fun
I don't know if there is a version of mpn_mulmod_2expm1 in GMP 5 or
not though. Does their p1 version allow negative values for n? I
didn't check.
Bill.
2010/1/11 Bill Hart :
> Hey, the GMP 5 library now has a version of our mpn_mulmod_2expp1.
> It's also undocumented I believe, but we can now us
Yes, it comes across the same way in English! You got your point across.
We don't document functions that are not available in GMP because when
they implement the same functions (which they have now done) they
invariably choose a different name (which they did), which means we
have to change the n
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
Hi cheater,
> Some of the program benchmarks that we have in our full benchmark
> suite tell a completely different story, putting MPIR well ahead for
> those sorts of things. They show that in an overall program, we do
> quite well.
Those programs are FAKE! Unfortunately for you I'm able to read
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.
I had an even better idea. Your p6/mmx supports, from what I can
tell, sse2. Therefore you can probably try:
./configure --build=pentium4-unknown-linux-gnu ABI=32
This may actually speed things up for you! (No guarantees, but there
is a good chance it will work).
If you are not using linux, jus
Brilliant!!
2010/1/10 Case Vanhorsen :
> On Sun, Jan 10, 2010 at 2:02 PM, Bill Hart
> wrote:
>> Thanks Case,
>>
>> those are very useful timings. I see more of what I expected to see
>> for unbalanced multiplication, especially here:
>>
>> 5NxN mpz multiplication: MPIR 1.3.0 GMP 5.0
On Sun, Jan 10, 2010 at 2:02 PM, Bill Hart wrote:
> Thanks Case,
>
> those are very useful timings. I see more of what I expected to see
> for unbalanced multiplication, especially here:
>
> 5NxN mpz multiplication: MPIR 1.3.0 GMP 5.0.0
> 1000 digits: 0.2064 sec 0.000
Thanks! I think it is more likely to be the tuning than the compiler
in this case. But that is only a guess, based on what I know of the
way the FFT code works.
I see that all the new FFT TABLE2 tuning values are missing entirely
(not your fault, but ours). What you might like to try, when you fin
Yes, of course.
$ls -lrt gmp-mparam.h
lrwxrwxrwx 1 giangian27 2010-01-10 17:19 gmp-mparam.h -> mpn/
x86/p6/mmx/gmp-mparam.h
$ cat gmp-mparam.h
/* Intel P6/mmx gmp-mparam.h -- Compiler/machine parameter header
file.
Copyright 1991, 1993, 1994, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006
Actually, here are some really old timings I have which illustrate
this point. They are for a K8 Opteron system and compare GMP 4.2.1 (a
very old version) with GMP 0.9.0 (our first public version). About the
*only* difference was the assembly code. See how the change in speed
of that affected nearl
Sure, but as I mentioned, right at the start, the speed of
multiplication is critical for almost everything. That is why it is
the most important benchmark.
And the speed of multiplication is critically dependent on the speed
of the basecase assembly case, which, on your machine, is slower in
MPIR
Let's abandon GMP5 alone for a while.
On my CPU, GMP432 get this values:
Category base=> 1546, 1104
Program rsa (weight 1.00) => 398, 284
Program pi (weight 1.00) => 4.46, 3.18
Program bpsw (weight 1.00) => 2.31, 1.65
Program wagstaff (weight 1.00) => 10.7, 7.62
Program mersenne
Thanks Case,
those are very useful timings. I see more of what I expected to see
for unbalanced multiplication, especially here:
5NxN mpz multiplication:MPIR 1.3.0 GMP 5.0.0
1000 digits: 0.2064 sec 0.1863 sec
5000 digits: 0.00023417 sec 0.0002170
On Sun, Jan 10, 2010 at 1:18 PM, Bill Hart wrote:
> You are of course welcome to choose whichever package best meets your
> needs. And indeed on your particular system, it seems GMP may well do
> that for you at present.
>
> One thing you should bear in mind however. Here are some times as they
>
Just to illustrate the last point, here is the list of all assembly
files in MPIR that have been added or improved since MPIR 1.2.0, i.e.
since the last release:
32 bit x86 assembly code
A /mpir/trunk/mpn/x86/applenopic/aorsmul_1.asm
A /mpir/trunk/mpn/x86/applenopic/c
You are of course welcome to choose whichever package best meets your
needs. And indeed on your particular system, it seems GMP may well do
that for you at present.
One thing you should bear in mind however. Here are some times as they
have changed over the past year and a half:
K8
Multiplicatio
Indeed the p6/mmx uses the default values for those missing tuning
values, which are in gmp-impl.h, for example MUL_TOOM4_THRESHOLD is
set to 400, which is reasonable.
It's curious that the FFT still triggers the assert with the last 6
lines replaced with the original ones that we provided.
Thank
It seems that also on your platform (32 bits you too?) MPIR is faster
only for one thing: multiplication (or squaring) above 10 digits,
up to 30%.
And slower almost everywhere... somewhere +100% or more...
This strengthen my decision...
Gian.
On 10 Gen, 18:47, Case Vanhorsen wrote:
> I'll t
Ok, I'm trying this too: selectively taking some output (all except
last 6 lines FFT_MUL and SQR_MUL) of make tune, and copy it into gmp-
mparar.h (to try to work around code instability that simply tuning
triggers)...
--MPIR-1.3.0-rc4--
$ mpir_bench_two/bench_two
Running MPIR benchmark
GenuineIn
That's very interesting. It clearly shows that the further from
"balanced" that the division is, the worse our (ancient) code
performs.
I'm certainly looking forward to sorting out our division code.
Bill.
2010/1/10 Case Vanhorsen :
> I'll toss in my benchmark results. :-)
>
>
Actually, if you take the tuning values that are missing at the end of
the tuning file and replace them with the values we supplied
(MUL_FFT_TABLE, SQR_FFT_TABLE, etc) you will probably find the
assertion goes away. The assertion was left there on purpose to
indicate that the FFT is most definitely
You'll find that all the very large stuff will be markedly worse after
tuning. One of the reasons we are replacing the FFT is that at present
the only people that can tune it are us, and it takes hours!
But thanks again for the comparisons.
Bill.
2010/1/10 Gianrico Fini :
> I see the comparison
I see the comparison is more balanced on you machine. The impressive
unbalance is in the numbers of the Mersenne and Fermat test.
By the way, I tested it all again with gcc-4.4 and with the result
from (cd tune;make tune) inserted in gmp-mparam.h... for all the three
libraries.
Results for GMP-5.
I'll toss in my benchmark results. :-)
GMPY performance benchmark
Decimal string to mpz: MPIR 1.3.0 GMP 5.0.0
10 digits: 0.0021 sec 0.0022 sec
100 digits: 0.0063 sec 0.0066 sec
500 digits: 0.
Sure, it's interesting to compare.
On my 64 bit machine (Selmer):
K10-2:
Squaring: MPIR 1.3.0 GMP 5.0.0
===
128 x 128 : 56715728 55997671
512 x 512 : 11350749 13487276
8192 x 8192 : 149696 151687
131072 x 131072 :
Sorry, I don't have a 64-bit processor... I'm working on somehow old
hardware, usually.
Anyway I think there is also another problem in my measure, I did not
"tune".
I was trying an update of the compiler to gcc-4.4...
Then I'll recompile the three libraries, retune them, recompile again,
and test
Thanks very much for taking the time to run those!!
We suffer a little here because of suboptimal assembly code we provide
for your (32 bit?) Pentium M processor, as can be seen from the
multiply scores for small sizes (which are dominated by the assembly
performance).
MPIR 1.3:
8192
I tried, on my laptop. I couldn't work with their own test, so I used the
one I've found on MPIR main page. I paste here the result (I'm running
Gentoo, gcc-4.3.4).
--GMP-4.3.2--
$ mpir_bench_two/bench_two_gmp
Running MPIR benchmark
GenuineIntel Family 6 Model 9 Stepping 5
Intel(R) Pentium(R) M p
Thank you very much for suggesting me this short discussion.
I also explored the site of that project, and I've seen they have a
link in evidence on the main page about supporting campaign against
software patent.
I also played a bit with the libraries and they work smooth. Thanks
again!
Gian.
On
54 matches
Mail list logo
