How to make Python run as fast (or faster) than Julia

[Chris Angelico]

On Tue, Feb 27, 2018 at 12:03 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Mon, 26 Feb 2018 22:34:00 +1100, Chris Angelico wrote:
>> Removing the GIL from CPython is not about "speeding up" the language or
>> the interpreter, but about improving parallelism.
>
> It is about speeding up threaded code which is CPU-bound. I call that
> speeding up the language :-)
>
> Hypothetically, it could also speed up even unthreaded code.

In its purest sense, no, it cannot speed up unthreaded code. Since
many Python programs are single-threaded, this restricts the benefits
to those programs which can actually parallelize, but the penalties
(mainly overhead) usually apply to all programs.

> Some language features could internally launch threads and operate using
> implicit parallelism. For instance, map(func, seq) could run in parallel
> in separate threads whenever Python knew that func had no side-effects,
> say for built-ins. There are also parallel algorithms for bignum
> arithmetic. If threads were quick enough, I'm sure we could come up with
> many more examples. Hypothetically speaking.

These are ways of converting single-threaded code into multi-threaded
code, which could then benefit from parallelization, which can reduce
wall-time for the process as a whole.

> (In practice, the old hope that parallel computing would speed everything
> up turned out to be flawed. Relatively few tasks are embarrassingly
> parallel, most have sequential bottlenecks, and many are inherently
> sequential.)

Exactly; and it goes further: many modern programmers do not think in
terms of parallelism. Even event-driven code takes a bit of getting
your head around. Why are async functions preferred over threads? It's
not JUST because today's OSes have thread count limits far below
socket limits - if that were the sole justification, we wouldn't have
language-level support for async/await - it'd be a niche technique
used only in the highest-throughput applications. No, async functions
are preferred because they *reduce the points where context switching
can occur*, thus making it easier *for the programmer*. If there were
a way for the language to automatically run things in parallel, the
biggest risk is that the programmer who wrote it can no longer
understand it.

>>> (If it weren't for the EU government funding it, PyPy would probably be
>>> languishing in oblivion. Everyone wants a faster Python so long as they
>>> don't have to pay for it, or do the work.)
>>
>> Hm, I didn't know the EU was funding PyPy. Okay. Cool.
>
> I don't know if they still receive funding, but I know that PyPy really
> only got going in a big way when they got a grant from the EU. I think it
> paid for at least one developer to work on it full time for a year.
> DuckDuckGo is probably your friend if you care about the details.

Meh, I don't care that much about what the EU does or doesn't fund.
Was just a mild case of curiosity. I had about as much interest as my
savings account accrued last year.

I'm glad _someone_ funded PyPy, anyhow. It's a great demonstration of
what can be done.

ChrisA