# tuneup.c

**Kevin Ryde
**
user42@zip.com.au

*Thu, 06 Mar 2003 10:37:40 +1000*

Jason Moxham <J.L.Moxham@maths.soton.ac.uk> writes:
>*
*>* I writing a high and low part multiplication and as you are probably aware the
*>* benefit at very large sizes is very small , so I have a threshold to switch
*>* over to normal mpn_mul .
*
If the lowhalf form is no slower then there's probably no need to
switch.
>* However the tuneup program can not detect this
*>* crossover very well. Is there some sort of fudge factor (eg like
*>* function_fudge in struct param_t ) so that I can tell the tuneup program to
*>* switch over when mpn_mullowhalf is about within 1% of mpn_mul .
*
Hmm. Not really. Maybe stop_factor is close to what you need. If
it's 1.0 or just above 1.0 then I think the looping will end pretty
much as soon as method A is slower than method B. Combine that with
the function_fudge to stop when A is within a certain factor of B.
If the main loop in "one" doesn't suit then you can always do your own
thing with tuneup_measure. tune_jacobi_base is a simple example of
that, "fft" is a hairy example.
>* I really need
*>* something like this because for even larger sizes the speeds of the two
*>* functions are always about the same , so no definite crossover can be
*>* detected. This is more important for the highpart multiplication than the
*>* lowpart , as the probability of a detectible error increases with size.
*>* Note the "crossover" sizes are approx 16000 to 30000 limbs , ie well in fft
*>* ranges
*
Big sizes can be time consuming to probe, and I'm not sure accuracy
and reproducibility are terrific when time periods start to get big.
If there's not a lot of difference at the point your interested in
then I don't suppose it needs to be located too accurately.