Speed-up for loops
kushal.kumaran+python at gmail.com
Mon Sep 6 13:49:33 CEST 2010
On Mon, Sep 6, 2010 at 4:08 PM, BartC <bartc at freeuk.com> wrote:
> "Stefan Behnel" <stefan_ml at behnel.de> wrote in message
> news:mailman.470.1283712666.29448.python-list at python.org...
>> BartC, 05.09.2010 19:09:
>>> All those compilers that offer loop unrolling are therefore wasting
>>> their time...
>> Sometimes they do, yes.
> Modifying the OP's code a little:
> a = 0
> for i in xrange(100000000): # 100 million
> a = a + 10 # add 10 or 100
> print a
> Manually unrolling such a loop four times (ie. 4 copies of the body, and
> counting only to 25 million) increased the speed by between 16% and 47% (ie.
> runtime reducing by between 14% and 32%).
> This depended on whether I added +10 or +100 (ie. whether long integers are
> needed), whether it was inside or outside a function, and whether I was
> running Python 2 or 3 (BTW why doesn't Python 3 just accept 'xrange' as a
> synonym for 'range'?)
> These are just some simple tests on my particular machine and
> implementations, but they bring up some points:
> (1) Loop unrolling does seem to have a benefit, when the loop body is small.
> (2) Integer arithmetic seems to go straight from 32-bits to long integers;
> why not use 64-bits before needing long integers?
On 64-bit systems, integer arithmetic will go from 64-bit native
integers to long. Will using any emulated 64-bit type on a 32-bit
system actually be better than the python long implementation?
>From my 64-bit linux system:
In : n = 2 ** 40
In : type(n)
Out: <type 'int'>
In : n = 2 ** 80
In : type(n)
Out: <type 'long'>
> (3) Since the loop variable is never used, why not have a special loop
> statement that repeats code so many times? This can be very fast, since the
> loop counter need not be a Python object, and probably there would be no
> need for unrolling at all:
> repeat 100000000: # for example
> a = a + 10
More information about the Python-list