mpn_mul is embarrassingly slow

[Vincent Lefevre]

On 2018-04-24 14:11:34 +0200, paul zimmermann wrote:
>        Dear Torbjörn,
> 
> > What do you think about this stopgap change?
> 
> I would entirely drop all the squaring-related stuff from mpn_mul:
> the user/developer should call mpn_sqr instead (see my previous mail).

It is not clear that the user would necessarily do this,
in particular in an algorithm where up and vp can be equal
or not, depending on the context.

The test up == vp is done only when un and vn are large enough, so
that the overhead of this simple test would be relatively small,
with a potentially significant speedup in case up == vp.

> (I believe it is vn and not un that should be compared to
> MUL_TOOM22_THRESHOLD.)

Have you read the associated comment?

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)