Hacker News Reader

Comment by TekMol | Hacker News Reader

I had to look up what Cinder is. Yay, a faster fork of CPython! For the love of God, please get those improvements to CPython. The world needs it!

> It's no secret how they made their runtimes fast.

So why is nobody doing it? The ecosystem that would benefit from it must be gigantic. Hell, I am a solo indie developer and I would happily pay $500 to see Python make a jump to match PHP's performance! If we extrapolate this to the whole Python ecosystem, the value of a fast CPython must be Billions.

> C extensions are already available in Python

What I meant is inline. So inside of a py file, you can rewrite the one function which you identified as the bottleneck. In C or another language.

View on HN

> So why is nobody doing it?

Mostly, resources.

Giants spent their energy speeding things strategically:

・ Google wanted Chrome to win, so they spend their effort on JS.

・ Facebook was a PHP shop, so they worked on make it fast.

・ MS had to promote .net, so they optimized c#.

Now you also have to remember that:

・ it's a hard problem

・ python is not a performance oriented language, so it was not a priority

・ when data science became popular, c-extensions were usually enough to get the perfs you wanted

・ once you have a working python code reaching perfs limit, you could start a rewrite in a fast compiled language (Google did it with go, dropbox with rust, etc). But this could take years before you need it. Youtube ran fine on PHP then Python for almost a decade. Python can take you very, very far. In fact, I'd say half the time somebody says python is too slow for them, it's because they are doing something wrong. Case in point, I have a half-million users/day streaming website running on Python. It's been running for 10 years, and needs only one dev to maintain it.

・ the PSF had no money (https://pyfound.blogspot.com/2012/01/psf-grants-over-37000-t...), and most work on python was from people on their free time. Very few paid devs on Python for decades, compared to other languages

・ there are actually a lot of improvements on tooling for perfs on python. Multiprocessing have fantastic pools and shared memory. We have asyncio (not to mention uvloop). c-extensions release the GIL, so you can use threads for parallelism with numpy. Most people are just not aware of it.

・ Python is very old, 4 years older than java. It has been design way before multi-core laptop were a thing. And so the GIL is everywhere.

・ python is in a very unique position: it's the second best language for anything. Meaning it's been used by data scientist, web devs, geographers, sysadmin, pen testers, os maintainers and biologists alike. They all have very different tooling, dev envs and workloads. Speed doesn't mean the same things for all of them. E.G: a slow starting JIT that speeds up a web server would destroy the use case for cli tools. Mercurial has not computational speed problems, but import time is killing it. But lazy imports would make debugging and new comers learning curve harder. What if they speed up things for them, but slow them down for you?

・ 2->3 made the entire community change averse. And to get speed, you need to break the C api somehow. Hence the Handle Python project.

So the previous attempts to speed up Python were by either interns, or people doing it out of passion/curiosity. A lot failed (unladen swallow, pyston1, etc). Some were successful but only for some dimension of speed and/or doing some compromises (pypy, stackless...). Some are still WIP (Pydgin, pyston 2..). The solutions that succeeded the most are actually side stepping the problem (cython, numpy, numba, dask) but usually became popular although some very good projects still deserve more light (nuitka, mypyc...)

It's only now that Python is becoming such a huge deal that MS hired Guido to work on general computational speed for cPython. Now that there is attention, money and dedication on the problem, you can already things moving in the bug tracker (coroutine unwrapping, c stack skipping calls, HandlePython, etc). It's going to take time. Millions have already been invested in V8 to make the JS slug go steroid, so catch up is not for tomorrow.

> What I meant is inline. So inside of a py file, you can rewrite the one function which you identified as the bottleneck. In C or another language.

You can already do that with cython. And there are alternative for rust, nim, go...

That's also why python speed is usually not a priority: you can rewrite your hot spot in another language and keep most of your python code.

Now, I'm glad python speed is now something the right people work on. But there were very good reason it hasn't happen until now.

The way you say it, it feels like "wow, nobody has though of that before!".

That's not what happened.

> MS hired Guido to work on general computational speed for cPython.

van Rossum applied at Microsoft, they took him and he chose that project.

van Rossum had never shown any interest in JITs before. While at Google, he maintained that Python was fast enough. While at Dropbox, he initiated Asyncio (fixed and improved by many people) and integrated typing (Jukka Lehtosolo).

If a fast JIT emerges, it will likely be by existing Microsoft JIT experts. They should familiarize themselves with the cliquish nature of Python, rampant credit taking by those who did not do the work, and sidelining and active defamation of those outside the clique once the work is done.

It could be a major career disaster to get involved with these people.

For the last Python release, 3.10, a lot of new names were put under the spotlight.

I disagree, I think Python is usually a community where people gets the respect they are due.

> Facebook was a PHP shop, so they worked on make it fast.

Tangent: Facebook's work on PHP was largely a technical dead-end. Their work on HipHop and HHVM was never accepted upstream, and eventually resulted in their forking PHP into a separate and incompatible language called Hack, which basically nobody uses outside of Facebook.

In the meantime, the upstream PHP project hasn't been standing still. The core development team has made a number of significant improvements to PHP performance. By 2015 or so, PHP 7.0 matched the performance of HHVM, and newer versions have improved upon that. (PHP 8.0 added a JIT compiler, for example, which can dramatically boost performance for some applications.)

> What I meant is inline. So inside of a py file, you can rewrite the one function which you identified as the bottleneck. In C or another language.

Have a look at cython – it provides exactly that.

But can you swap out CPython for Cython in - say - a Django stack and things go smooth?

Every time I look up how to replace CPython with something faster for Django, everybody who tried it (in production) is of the opinion that it was surprisingly painful and is not worth the hassle.

I use Cython for the small part that has a tight loop in a Django project. Using Cython with Django itself sounds difficult, but the Falcon framework looks like it uses Cython.

> What I meant is inline.

See Cython.

It requires a lot of money and the C API is restrictive when trying to perform aggressive optimization.

Reply on news.ycombinator.com