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
12 => 32.1 => 1211, 1514 => 113, 141 => 1129, 1412
Here for comparison are the original times I reported for MPIR and GMP 5:
8 : 87725 6791
10 : 3241 635
12 : 80.3 25.0
The improvement using your powm is not so great when things get large,
but now the comparison is much more reasonable!
So in retrospect, yes it should *definitely* have been implemented at
least using powm. But the reason it was not (I presume) is that powm
cannot be used efficiently as a replacement for mpn_mulmod_2expp1. It
was coded with that in mind, nothing else. I think it is much, much
harder to come up with a simple replacement for the mpn_mulmod_2expp1
function without just doing precisely what we do in MPIR 1.3.0.
Now, GMP actually has such a function in GMP 5 and we will definitely
be changing the benchmark to reflect this. Just give us a little time.
Bill.
2010/1/11 Bill Hart <[email protected]>:
> 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
> functions for such a machine without access to one. I'm sure Jason
> would have liked to try.
>
> As I suggested, you might try the --build=pentium4 thing if you want
> to see if it will go any faster. I don't guarantee it, but you might
> be surprised.
>
> Bill.
>
> 2010/1/11 Bill Hart <[email protected]>:
>> 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 name of our function to match. Not much point
>> documenting it then is there!
>>
>> If you had asked about this, you might have found there was a good
>> reason for it! You seem overly eager to find some fault....
>>
>> Bill.
>>
>> 2010/1/11 Gianrico Fini <[email protected]>:
>>> 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 some
>>> lines of code.
>>> This bench_two program _is_a_silly_fake_!!!!
>>>
>>> I wrote in another thread, because I wanted to have an explicit
>>> subject.
>>> Try to remove the cheating programs, then tell me again if "you do
>>> quite well" in an "overall program".
>>>
>>> And do not expect any other help from me, you cheater!
>>>
>>> I'll go and sleep the sleep of the just (I hope it means the same
>>> thing as in my mother-language)... what about you?
>>>
>>> Gian.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "mpir-devel" group.
>>> To post to this group, send email to [email protected].
>>> To unsubscribe from this group, send email to
>>> [email protected].
>>> 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
