On 10/22/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Tim]
> >> I assume it's the overflow-checking that's the major time sink,
>
> [Adam Olsen]
> > Are you sure?
>
> No -- that's what "assume" means <0.7 wink>. For example, there's a
> long chain of function calls involved in int(string) too.
>
> > <https://sourceforge.net/tracker/index.php?func=detail&aid=1334979&group_id=5470&atid=305470>
> >
> > That patch removes the division from the loop (and fixes the bugs),
> > but gives only a small increase in speed.
>
> As measured how? Platform, compiler, input, etc? Is the "ULONG_MAX /
> base" part compiled to inline code or to a call to a library routine
> (e.g., if the latter, it could be that a dividend with "the sign bit
> set" is extraordinarily expensive for unsigned division -- depends on
> the <compiler, HW> pair in use)? If so, a small static table could
> avoid all runtime division. If not, note that the number of divisions
> hasn't actually changed for 1-character input. Etc.
AMD Athlon 2500+, Linux 2.6.13, GCC 4.0.2
[EMAIL PROTECTED]:~/src/Python-2.4.1$ python2.4 -m timeit 'int("999999999")'
1000000 loops, best of 3: 0.834 usec per loop
[EMAIL PROTECTED]:~/src/Python-2.4.1$ ./python -m timeit 'int("999999999")'
1000000 loops, best of 3: 0.801 usec per loop
[EMAIL PROTECTED]:~/src/Python-2.4.1$ python2.4 -m timeit 'int("9")'
1000000 loops, best of 3: 0.709 usec per loop
[EMAIL PROTECTED]:~/src/Python-2.4.1$ ./python -m timeit 'int("9")'
1000000 loops, best of 3: 0.717 usec per loop
Originally I just tried the longer string so I hadn't noticed that the
smaller string was slightly slower. Oh well, caveat emptor.
--
Adam Olsen, aka Rhamphoryncus
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
