Hacker News Reader

Comment by pjmlp | Hacker News Reader

While it is nice that this option is available, it would be much better if Python itself would embrance the necessary runtime capabilties to not have to rely on it.

View on HN

This is not going to happen. GvR has successfully ignored Cython and PyPy for decades and has attached himself to a JIT project at Microsoft (has anything emerged?).

CPython is in the hands of not really productive bigcorp representatives who care about large legacy code bases. My guess is that CPython will be largely the same in 10 years, with the usual widely hyped initiatives that go nowhere ("need for speed etc.").

> who care about large legacy code bases

It's clear that Python's main strength is its vast libraries, priority number one is not breaking them. If it could be possible to speed up Python without breaking changes I would be surprised precisely because with so much large codebases speed and efficiency would translate directly to money.

Yeah, it took over a decade to switch from Py2 to Py3 due to the breaking changes it brought. I'd rather not to have such a large change again, ever.

They really missed an opportunity when they made the switch from py2 to 3 to break things a bit more but give more improvement in exchange

Completely agree. I think GvR was too conservative. And yet he had lot of backslash, it's easy for me now to criticize several years later after the fact, I only have respect for the work done. I think it was in the mind of everyone the Perl 5/Perl 6 transition.

While it's true speed was not a priority, I think most of those initiatives didn't try hard to work with upstream.

The Microsoft funded project is different, they're merging things. I don't think they've started on a JIT translator yet, though, last time I looked they were busy picking lower-hanging fruit. From watching their communications, I think they might get there at some point.

It's not as simple as just emitting machine code, though. To get something in the same magnitude of typical C code, you need to deduce types and peel away the boxing and unboxing layers.

To write fast Cython, you basically need to write in C and control everything including Python API calls. No runtime will help with this.

That is really only true if you want to squeeze every drop of performance out of Cython. For the first 80% of performance gains you don't have to go that deep.

That is another thing that is nice about Cython, you don't have to learn all of Cython to be productive. Take your existing python function and just add some type annotations and you'll see real performance gains. Then you can profile your code and see what the next bottle neck is and fix that and so on.

So, yes, Cython gives you the power to manually control the GIL and the Python API calls and manage your own memory management and layout for those corner cases where that is what you need. Most of the time you can happily ignore all of that and get almost all of the speedup available.

Common Lisp and simlar languages are a prof of what is possible.

Writing a much faster language runtime for a language that looks quite a bit like Python is easy. The hard problem is writing a faster language runtime that is 100% compatible with all current python programs (and their extensions) out in the world.

But this is not necessary. The python developers just need to specify this fast subset of the language, and let people use to create libraries. Over time, we would have a growing set of libraries written in the fast subset.

People have. See PyPy and Pythran for two examples currently under active development. Instagram has such a project as well that they recently released. I know there have been others. None of them seem to catch on. It seems that most people don't actually want a faster subset of python. They want either all of python or none of python (by switching to another language all together)

I'm not and have never been a game developer, but I think that a decent analogy here might be how many game studios write the core engine in C++, and then do a lot of the high level game logic and scripting in an interpreted language such as Lua or their own dialect of lisp.

I would guess that there's a clear separation of responsibilities, and each of the two languages is very well-suited to what it's being used for. There's not really a whole lot of anxiety about getting Lua (or whatever) to pull out all the stops you see in a compiler like SBCL or interpreter like V8, because these communities were never looking for a single language that could cover all uses cases in the first place. To steal an analogy I used the other day from myself, I'm guessing they don't want a spork all that badly because they're plenty happy with using a fork and a spoon.

That's how the community of people doing scientific computing and suchlike in Python tends to feel about things, too.

Pypy is not really practical. It requires you to stop using many features of Python. What Python needs is a fast subset that is supported within the main implementation.

What do you mean? Pypy supports all of python. (not necessarily all of the C API, but that's somewhat a WIP and somewhat a result of the overly-expansive C API.)

This is related to the idea of EPython that we are working on (as we have funding): https://github.com/epython-dev/epython

It currently emits Cython for the C-backend (and PyIodide). It is very alpha currently, but if people are interested in helping, get in touch.

I don't think 100% compatibility should be a goal. The maintainers really need to step up and guide the community through a tough but important transition (reducing the API surface for C-extensions to some sane subset so the implementation can be optimized--see things like h.py) or Python will remain in its very slow local optimum while the world moves around it.

Yes, we just went through one "tough but important" transition (Python 2->3) and it sucks to have to do this so often, but it's the price we pay from making bad bets (in this case, unnecessarily exposing the entire CPython interpreter as the C-extension API surface on the assumption that it will never be necessary to make CPython faster because people who need speed will just write the slow parts in C).

People are starting to forget non-trendy languages only to reinvent the wheel or resolve non-issues. It is not strictly related to languages. Such a common phenomena based on my observations. I did not like history of IT, but now I believe it is necessary, at least for your own sub-field or something.

The parent is talking about Python (specifically CPython, I assume), not Cython. Moreover, performance isn't a binary and there's lots of headroom for CPython to improve if they would be willing to drive the community through a breaking change (but the Python community generally assumes that any kind of breaking change necessarily has to look like the Python 2->3 transition and there's no political will for this). Note how many interpreted dynamic languages absolutely trounce CPython for anything that isn't a microbenchmark.

Don't count on it - switch to Julia instead.

Julia is great if you can afford to spend 5 minutes sitting around for your session to load, but most people have things to do.

When's the last time you've tried it? Load times are way better. New improvements for code caching have been merged in 1.8, and native code caching is coming in 1.9. It's a complex problem due to Julia's aggressive specialization and composability, so you can't just expect Julia to do it like other compiled languages.

Check out this recent writeup from a core dev: https://discourse.julialang.org/t/precompile-why/78770/8

Julia has its own heap of issues, but five minutes is a load of bull:

    > time julia -e 'using Plots; plot(rand(10, 5), rand(10))'
    
    ________________________________________________________
    Executed in    5.77 secs    fish           external
       usr time    5.74 secs  214.00 micros    5.74 secs
       sys time    0.57 secs    0.00 micros    0.57 secs

This is also on a fairly old version at that:

    > julia -v
    julia version 1.6.3

Regardless, this conversation was to be about Cython; it which deserves a lot of praise in its own right as a tool in your toolbox to make the blasted snake run faster.

Also, if you make a sysimage, startup time can be reduced to <1s. This doesn't get a ton of publicity because many of the more active Julia devs are developing lots of packages and/or developing Julia which makes this less applicable to them, but if you are waiting more than a few seconds to load packages that you aren't a developer of, sysimages are a wonderful quality of life improvement.

How many times a day are you starting sessions?

I don't use julia, but I start python sessions multiple times per day.

I work in Python, but I might restart, create new sessions, etc anywhere between 1-100 times a day depending on what I am doing.

Yeah, looking forward for Julia to pressure Python.

Would love to but community is way to small for my use case :(

what's your use case?

Reply on news.ycombinator.com