On Fri, 26 Feb 2016 07:54:26 +0100 isabella parakiss <izaber...@gmail.com> wrote:
> the problem with factor is that any naive implementation > will pale against the one in gnu coreutils. > > (gnu) > $ time factor 1267650600228402790082356974917 > 1267650600228402790082356974917: 1125899906842679 > 1125899906842723 real: 0m1.576s, user: 0m1.570s, sys: > 0m0.003s > > (yours with gmp) > $ time ./factor 1267650600228402790082356974917 > 1267650600228402790082356974917: 1125899906842723 > 1125899906842679 real: 1m11.109s, user: 1m11.013s, sys: > 0m0.013s > > (yours with tommath) > $ time ./factor 1267650600228402790082356974917 > ^C interrupted after 20 minutes > > from at least 50x to more than 1000x slower than the gnu > version. does this suck less? > > > --- > xoxo iza > Performance is not really something suckless concerns itself about. They favour solutions that are simpler to implement and maintain but asymptotically slower. But in the case of tommath, I don't think it is asymptotically slower, at least not much, it is just makes a hugh about of memory allocations. Which is a very expensive operation. It should however be noted, that factor(1) is not intended to factorise huge numbers or brake RSA numbers, in fact GNU factor will reject to difficult numbers. It should just be able to factor reasonably large numbers. I think 50 times slower than GNU factor is acceptable, but 1000 times slower is not. Keep in mind though, that the difference depends widely on the number that is being factorised.
pgppbEMezHf4l.pgp
Description: OpenPGP digital signature
