On 15/05/2015 07:05, Gregory Ewing wrote:
BartC wrote:
It appears to be those "<=" and "+" operations in the code above where
much of the time is spent. When I trace out the execution paths a bit
more, I'll have a better picture of how many lines of C code are
involved in each iteration.
The path from decoding a bytecode to the C code that
implements it can be rather convoluted, but there are
reasons for each of the complications -- mainly to
do with supporting the ability to override operators
with C and/or Python code.
If you removed those abilities, the implemention
would be simpler, and possibly faster. But then the
language wouldn't be Python any more.
That's the challenge; programs must still work as they did before. (But
I suppose it can be exasperating for CPython developers if 99% of
programs could be made faster but can't be because of the 1% that rely
on certain features).
Still, I'm just seeing what there is in CPython that limits the
performance, and whether anything can be done /easily/ without going to
solutions such as PyPy which are unsatisfactory IMO (by being even more
fantastically complicated, but they don't always give a speed-up either).
For example, there is a /specific/ byte-code called BINARY_ADD, which
then proceeds to call a /generic/ binary-op handler! This throws away
the advantage of knowing at byte-code generation time exactly which
operation is needed.
(Unless I'm just looking at a bunch of macros or maybe there is some
inlining going on with the compiler reducing all those table-indexing
operations for 'Add', with direct accesses, but it didn't look like it.
I'm just glad it doesn't use C++ which would have made it truly
impossible to figure out what's going on.)
(BTW since I'm having to use Linux to compile this anyway, is there a
tool available that will tell me whether something in the C sources is a
function or macro? (And preferably where the definition might be located.))
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
