Re: code optimization

[spx2]

in reply to code optimization

I was actually looking at this paper which describes in the first 3-4 pages how to compare continued fractions and I was wondering if converting your fractions to continued fractions and then carrying out a continued fractions comparison algorithm(which Flajolet describes in the first link in this post) would lead to faster running times.

Except.. it's pretty hard to compete with the cost of a division(which is rather low).

In any case, if Perl doesn't cut it as far as execution time, I would go for XS, or a pure C version.

[BrowserUk]

Except.. it's pretty hard to compete with the cost of a division(which is rather low).

Agreed. Almost no matter how this is coded, the runtime is going to be dominated by the time taken to read the data from the file. It's doubtful that you could achieve a meaningful saving even by moving to C.

[spx2]

Yes, I think the C version would however be faster by some factor not depending on the input size. That's because Perl has some overhead because of the data structures it uses, because of the garbage collection and so forth. There's also the silly version of comparing a/b < c/d by multiplying everything with bd then you reach ad<cb. Now, are two multiplications faster than a division, even if the multiplication is carried out with Karatsuba's algorithm (the article says that "Karatsuba is usually faster when the multiplicands are longer than 320–640 bits" and also gives complexity) or linear time multiplication ? I'm just wondering what the cost of a normal division is in relation to the cost of two multiplications..

[BrowserUk]

I'm not 100% certain, and I've failed to find confirmation with a quick search, but I am pretty sure that on Intel's recent (last 5 or so years) processors, 32&64-bit, that integer division and integer multiplication take the same number of clock cycles. I'll knock up a quick test to verify that though.