On 11 Gen, 12:35, Bill Hart wrote:
> Nah, the discussion is over.
Ok, you chose the easiest way: to escape.
> Your suggestion of me donating code to the FSF shows you have totally
> missed the point.
It was too much, I realised while trying to write the 10 lines... too
easy for such a big price
> I am afraid that you are misusing my benchmark, which I provede as a
> way of monitoring aspects of MPIR development.
[...]
> It is NOT intended for use in comparing MPIR and GMP and, as you have
> quickly discovered, it is completely inappropriate for this.
I'm afraid you should explain this to
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
> 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.
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
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
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
> 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
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 :
>
> > It didn't took me so much time as I feared to understand why the use
> > of bench_two on GMP4.3 and
hould 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 :
>
> > It didn't took me so much ti
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.
iously
> sped up this assembly function and we had not, so even GMP 4.3.2 will
> be faster.
>
> Anyhow, while you are still there, can you please post the contents of
> the gmp-mparam.h file that you used when the fac_ui test failed the
> assert. That would be a great help to us!
>
e days it cannot be done by hand. We have
> special optimisation tools for doing it, and it takes large amounts of
> CPU time, and human hours, to do the optimisation work. Progressively,
> over time, all the code will get optimised, but it is a long process!
>
> Bill.
>
>
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
> 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.
>
> > B
89.6 96.0
> 16384 : 2.86 2.96
>
> Mersenne:
> ===
> 3217 : 138 43.6
> 4253 : 67.6 21.8
> 4423 : 59.7 20.1
> 9689 :
Toom functions. Pretty good work on their part!!
>
> I'd be curious to compare on a 64 bit machine where there should be
> little to no assembly bias. It looks to me that perhaps we still come
> out around the same on the pi test.
>
> Bill.
>
> 2010/1/10 Gianrico F
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
ttle one can do.
>
> At any rate, the "invention" is so obvious, and there is so much prior
> art, that a trial would hopefully invalidate it.
>
> Bill.
>
> 2010/1/8 Gianrico Fini :
>
> > Patents are very dangerous for free-software! We should be more strict
&
Patents are very dangerous for free-software! We should be more strict
on this!
Gian.
On 5 Gen, 21:15, Bill Hart wrote:
> HP has apparently tried to patent what looks to me (the description is
> too vague to be sure) like breaking decimal numbers up into chunks
> which fit into words.
>
> http:/
25 matches
Mail list logo
