Python and the need for speed
bc at freeuk.com
Tue Apr 18 19:33:43 EDT 2017
On 18/04/2017 23:33, Erik wrote:
> On 18/04/17 11:30, bartc wrote:
>> On 18/04/2017 10:32, Erik wrote:
>>> improvements over the original huge switch() to dispatch the bytecodes
>>> to the correct handler appear to have made this type of optimization
>>> less effective.
>> What did they do to it, and on which version?
> It's the computed 'goto' stuff that I'm referring to. At the time, I was
> looking at 2.7.9 (which just has the big switch) and 3.5.0 (which has
> the computed gotos).
So that's 'label-pointers' which I assume must correspond to computed
goto. (I don't know why they should be faster than a switch; they just are.)
> Perhaps the Windows build process requires that things are stable and
> doesn't support this type of development at all. You should take this
> part of the discussion to python-dev if you want to be able to build and
> experiment with it on Windows.
(OK, I've complained enough times in other groups about open source
projects being too Linux-centric.)
>> If that had worked, then further optimisations are possible, such as
>> doing a pre-pass combining common operations, that would not be
>> worthwhile using 'official' byte-codes.)
> That is effectively what my experiments were doing - sort of -, but
> without introducing an assembler layer. I'm not convinced about that -
> given the right hints, a half-decent C compiler these days will produce
> pretty good code.
With the sort of lower level programs I write (in another dynamic
language not Python), such an assembly layer improved performance 2-3
times over using 100% HLL compiled using C and gcc-O3.
In fact the rest of the code didn't need such a hot compiler and didn't
need to be in C.
With less numeric but still internally intensive tasks such as
compilers, using the assembly layer was still over 50% faster than using
C and gcc-O3.
However, with the very high level programs that many people (not me!)
like to write in Python, any such advantages would narrow I think.
More information about the Python-list