in reply to Re^3: bigint == horrible performance?
in thread bigint == horrible performance?

So I removed "use bigint" .. lo, and behold! It runs .. fast.

Arbitrary precision math is, regardless of the language in which it is written, much, much slower than fixed precision. It is the nature of the beast. If you know how arbitrary precision math works it will not come as any surprise.

It therefore falls to the developer to understand that and only use arbitrary precision when it is actually required.

I have a tendency to get somewhat exasperated when I see people offering Math::Big* as a solution to problems where there is a perception of a "precision problem", when 95% of them have far simpler and more efficient solutions.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^5: bigint == horrible performance?
by syphilis (Archbishop) on Nov 08, 2011 at 12:17 UTC
    Arbitrary precision math is, regardless of the language in which it is written, much, much slower than fixed precision

    I didn't do any benchmarking but my hunch is that the real slowdown wrt the op's code (when used with bigint) came about as a result of the multiplication and division operators being replaced by function calls.

    But then ... replacement of "operators" with "function calls" is really part and parcel of how arbitrary precision math works, so I'm not sure that stating my "hunch" actually contributes anything terribly useful ... even if it *is* correct.

    Cheers,
    Rob
[reply]

      The slowdown comes in (at least) three stages. Perhaps more depending upon which back-end is being used behind the bigint front of house.

      1. Overloading the operators adds one level of subroutine call to each math op.
      2. The call into the back-end library adds a second.
      3. A third level comes from getting access to the memory in which the numbers are actually stored.

        With native opcodes, the value is at a fixed offset and the actual operations are essentially a single assembler instruction (processor opcode).

        With the libraries, you have the XS to C wrapping layer, then the library call, then dereferenceing and casting to get access to the number hanging off the PV.

        And with arbitrary precision and larger-than-register fixed precision, you have the condition testing to see if the number has multiple elements and the loops needed to propagate carries etc.

      I was not laying any criticisms. If you need the precision, then the costs -- whatever they are -- simply have to be paid. But using bigint 'just in case', or as a 'cure' for perceived 'inaccuracies' in floating point is the wrong way to go.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
Re^5: bigint == horrible performance?
by moodywoody (Novice) on Nov 08, 2011 at 11:01 UTC
    Of course you're right. I pray excuse that I come from java land where everything not totally foolproof comes with giant warning signs. One gets used to that.
[reply]

In Section Seekers of Perl Wisdom