It's probably good enough until we implement various tricks to speed things up.
Bill.
On 9 March 2013 20:03, Fredrik Johansson wrote:
> On Sat, Mar 9, 2013 at 7:52 PM, Bill Hart
> wrote:
>>
>> Thanks. We'll put that patch in at the next release.
>>
>> Does 3x seem to be optimal?
>
>
> I don't k
On Sat, Mar 9, 2013 at 7:52 PM, Bill Hart wrote:
> Thanks. We'll put that patch in at the next release.
>
> Does 3x seem to be optimal?
>
I don't know if it's optimal, but it seems reasonable (if the FFT threshold
is assumed to be accurate for balanced multiplication). It should be ok
since I'm n
Thanks. We'll put that patch in at the next release.
Does 3x seem to be optimal?
Bill.
On 9 March 2013 16:03, Fredrik Johansson wrote:
> On Sat, Mar 9, 2013 at 4:35 PM, Bill Hart wrote:
>> OK, well I'll add this to the long MPIR todo list.
>>
>> When we next update MPIR we'll attempt to find a
On Sat, Mar 9, 2013 at 4:35 PM, Bill Hart wrote:
> OK, well I'll add this to the long MPIR todo list.
>
> When we next update MPIR we'll attempt to find a robust patch for this.
I just changed the FFT threshold test in mpn/generic/mul.c to
if (ABOVE_THRESHOLD (un + vn, 2*MUL_FFT_FULL_THRESHOLD
OK, well I'll add this to the long MPIR todo list.
When we next update MPIR we'll attempt to find a robust patch for this.
Bill.
On 9 March 2013 15:26, Fredrik Johansson wrote:
> On Sat, Mar 9, 2013 at 4:03 PM, Bill Hart wrote:
>> In theory, the FFT should handle very unbalance operands just f
On Sat, Mar 9, 2013 at 4:03 PM, Bill Hart wrote:
> In theory, the FFT should handle very unbalance operands just fine.
> But as you can see it is a matter of tuning at some points.
>
> Obviously we should be using something else at this size.
>
> The right way to handle really unbalanced operands
In theory, the FFT should handle very unbalance operands just fine.
But as you can see it is a matter of tuning at some points.
Obviously we should be using something else at this size.
The right way to handle really unbalanced operands like this is to
keep the smaller operand in Toom format and
There seems to be a pretty serious tuning issue with (highly)
unbalanced multiplication in mpir-2.6.0:
38 x 1400 bits takes 155 us
39 x 1400 bits takes 895 us
This is with
model name : Intel(R) Xeon(R) CPU X5675 @ 3.07GHz
and
gmp-mparam.h -> mpn/x86_64/nehalem/westm
