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
--
https://mail.python.org/mailman/listinfo/python-list
