Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

Which is more processor-intensive?

  1. Mar 25, 2016 #1
    What's more process intensive:

    5465411784154564 / 3


    5465411784154564 / 5746845218

    ie a big number / small number or a big number / big number?

    does it matter if I want to take the modulus instead?



    Accidentally messed up my title, if a moderator could change it that'd be great
  2. jcsd
  3. Mar 25, 2016 #2


    Staff: Mentor

  4. Mar 25, 2016 #3


    Staff: Mentor

    My guess is that both operations are equally expensive in terms of processor cycles. When you have arithmetic operations like this, you need to think about the types that could be used. The dividend (number being divided) is too large to fit in 32 bits (an int or long in C), but would fit into 64 bits. In your examples, the dividend and both divisors are integer values, so integer division could be performed, but the result will be an integer.

    If you want a precise answer, floating point division could be used, but neither a 32-bit floating point type (a float in C) nor a 64-bit floating point type (a double in C) would be able to hold all of the digits, so the answers wouldn't be that precise.
    Same concerns as above.
  5. Mar 25, 2016 #4
    Both calculations will take the exact same amount of time.

    Don't worry about optimizing things like math of plain data types, optimization of algorithms is always a better use of your time, any time savings at the bit-manipulation level is usually negligible.

    Secondly, the compiler is usually much smarter than you when it comes to optimizing this sort of thing. The proper use of registers and L1 cache makes a difference several orders of magnitude above what you'd save by nitpicking POD math.

    For example:
    Code (Text):
    int x = y * 320;
    can be converted into assembly in two ways

    Code (Text):
    mov [y] ax
    mul ax 320
    mov ax [x]
    Code (Text):
    mov [y] ax
    mov bx ax
    shr ax 8
    shr bx 6
    add ax bx
    mov ax [x]
    The compiler knows that the second is actually faster and will compile it that way for you.
    Last edited: Mar 25, 2016
  6. Apr 21, 2016 #5
    The answers above are true for many 64 bit CPUs and a 64 bit integer data type.
    Usually way more critical is if the values you want to process are in a fast processor cache or need to be fetched from slower memory.

    Otherwise it really depends on the processor used (and it's division algorithm), or if you use a type like BigInteger in Java on their actual implementation/algorithm too.

    For example if it was implemented using Euclidian Division (which it's usually not, because that would be way too slow), then division by 3 would be slower than by the bigger number (because more iterations with substractions needed).

    Depending on the processor/algorithm, both the result of the division and the remainder (result of modulo) might be available at the same time without increased cost, that is why C++ offers std::div:

    If you are interested in algorithms for computing with big numbers, have a look i.e. at the libGMP (The GNU Multiple Precision Arithmetic Library):
  7. Apr 21, 2016 #6


    User Avatar
    Homework Helper

    Last edited: Apr 21, 2016
  8. Apr 22, 2016 #7
    That should have been Euclidian division by substraction, I can't edit it in anymore though, sorry for that mistake by me.
Share this great discussion with others via Reddit, Google+, Twitter, or Facebook

Have something to add?
Draft saved Draft deleted