Python and the need for speed

[bartc]

On 18/04/2017 23:33, Erik wrote:
> On 18/04/17 11:30, bartc wrote:
>> On 18/04/2017 10:32, Erik wrote:
>>
>>> the
>>> 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.

-- 
Bartc