[Python-3000] Math in Python 3.0

[Tim Peters]

[Giovanni Bajo]
>>> Since we're at it, do you have any idea on why Python is so slow
>>> when doing such bit-full code?

[Tim Peters]
>> Is it, compared to the other interpreted languages?  Doesn't look like it.

[Giovanni]
> Well, it seems like one of the few area where Python is slower than other
> scripting languages.

To which I can only repeat:  Is it, compared to the other interpreted
languages?  Doesn't look like it.

I was judging from the URL you gave, which presumably was meant to
illustrate your point:

    http://shootout.alioth.debian.org/debian/benchmark.php?test=nsievebits&lang=all

Python is significantly faster than JavaScript, Tcl and Ruby there,
and in the same ballpark as Perl.  Those languages have comparable
implementations for low-level operations.  The biggest surprise there
to me is why Perl didn't do better, since it has a direct
implementation of bit vectors (albeit oddly spelled), so doesn't need
the long-winded source-code manipulations to extract byte and bit
offsets needed in the Python, JavaScript, Tcl and Ruby programs.  It's
not surprsing to me at all that the latter 4 languages are much slower
than compiled languages, although it was something of a surprise that
Ruby is _so_ much slower on this task.

>> The cost of going around the eval loop once utterly swamps the
>> cost of doing a bitwise operation on native ints, so relative
>> interpreter overhead is massive.

> Yup. I was wondering if there's something else that is a known issue and
> could be optimized. It really "feels" a little too slower than it could be.

For example, the CPython interpreter special-cases builtin short
integers in the BINARY_ADD and BINARY_SUBSCR opcodes.  It does not
special-case them in the BINARY_AND or UNARY_INVERT or BINARY_LSHIFT
(etc:  any of the bit-fiddling opcodes) opcodes.  Those go thru
full-blown OO dispatch:  it's more expensive to _find_ the function to
execute, and it's more expensive to call the function you eventually
find, than it is to do the work inside the function.

Some of Python's operators are also more powerful, such as that
int_lshift() will detect overflow and automatically switch to
unbounded ints when needed.

> ...
> Even if I've been using Python as my primary language for some
> years now, it still feels like this kind of bit manipulation is really
> slower than the "average" slowdown you expect when you using Python.

Bit manipulation on HW-size ints may well be a worst case for
languages of CPython's general implementation.

> I mean, it's just my feeling, so I might be very wrong. But the fact that
> nsievebits is one of the *few* benchmarks where Python doesn't rate well
> among other scripting languages

I guess I don't know what you mean by "scripting languages".  When I
look at the URL I see Python doing fine in comparison with the
languages I believe have similar niches and implementations

> ...
> Also this one:
> http://shootout.alioth.debian.org/debian/benchmark.php?test=partialsums&lang=all.
> Even using the sum() builtin with a genexp is slower than the *naive*
> for-loop implementation in other scripting languages.

I really don't know what you're comparing Python with.  I never think,
e.g., of Fortran, C, C++, Eiffel, Ada or Pascal as being "scripting
languages".  The fastest one there I may think of as being "a
scripting language" is Lua, and it did very well on this task indeed.

Anyway, I doubt this belongs on the P3K list, so enough.