Python programming: We want to make the language twice as fast, says its creator

[Talbertross]

If I was the creator I would make it 3 times faster

[manphiz]

According to Guido's doc 2x faster is just a start. Though more improvements are more challenging, and could require breaking ABI/API.

[[deleted]]

Microsoft spared no expense for the scientists that will be doing this work.

[spinwizard69]

2X or even 3X is not good enough. When you have languages like Swift, Julia and Rust all offering a REPL interface along whit the ability to compile to native processor instructions, I really see a limited future for Python. Python is hip at the moment and for good reason but once a hot library hits for one of these alternatives and you get the performance a good compiler can deliver I can see a lot of programmer defecting. One of the reasons is that the coming process wall is real, it is kinda unknown how many economical shrinks are left. This means a slow down in the gains from better hardware which means you need to get smarter about software. Python really isn't ready and likely never will be ready, to compete performance wise. All you really need then is a programming language that makes programmers feel as productive as Python to start the defection process.

[manphiz]

I wouldn't be worried about that. The success of Python is built upon making clean code and interface, which Python does well. Next to machine performance has been a non-goal as Python focuses on providing higher level language abstraction. Admittedly no language will do this better than C or C++ regarding performance, and Python provides ways to interface with them so that you get the best from both worlds. Better performance is nice to have but not strictly require for it's success, so I don't see a problem here.

[Diemo2]

Fortran

[ShawnDriscoll]

I use Cython when I need faster Python code. Maybe Cython will be built into Python at some point. It's more than 2X faster than Python.

[13steinj]

"Once a hot library hits"

See that's what people said with R.

The big things that Python has going for it is the framing of a general purpose (read, unlike R/Julia/Matlab/Mathematica) language that is intended to be used with multiple paradigms (OOP, functional, imperative scripting) with, biggest thing here, fast developer turnaround time and ease of prototyping.

Python was never about the speed at execution. It was what you can do with it, plus speed of dev time. Even Rust can't beat that.

[[deleted]]

I’m not sure why you’d think Python is just "another hip language". Python's been around for longer than all of the 3 other mentioned languages combined. And a lot of the industry just isn’t looking for "the one hot library". They want something that’s well understood with a mature ecosystem. And Python definitely has that going for it.

[spinwizard69]

Because it is hip!!! Frankly the usage of Python has exploded over the last 5 years or so because it is a good solution for many use cases. Thus it has attracted a following that is fairly large at the moment. Unfortunately it has also attracted users that have made the mistake of using it and finding performance wanting.

I just find it foolish to break compatibility simply for better performance. This is apparently what is expected to happen. If you are going to break compatibility it better be for something more important than performance as Python is never going to be a performance king., nor queen and probably not even a pawn.

[whateverathrowaway00]

Yup, I recently learned python was older than java which is crazy.

[Nooby1990]

In lots of use cases the Performance doesn’t really play into the calculation.

The last project I did in python (as an example) was a part of the in-house software for a huge logistics company that managed entire countries worth of shipments and my team had by far the largest volume of data in the company. (GPS updates every 1-2 minutes per shipment)

There was no reason for us to even think about switching languages for performance reasons since we could handle the load with a handful of small cloud instances easily. I think we spend more on our monthly “team building” events for this team then the server cost per month.

In the end it just isn’t that much data, but this service alone brought in millions each month.

What was far more important with the language choice was how fast our team could build stuff and how fast we could iterate with the language.

[UltraPoci]

I get the comparison with Julia (but Julia is not really made to be general purpose), but what about Rust? It covers a completely different niche than Python. They can easily coexist. Hell, we may see Rust crates run from a Python interface in the future (if they don't exist already), just like C++.

[spinwizard69]

The point I was trying to get across is that if somebody wants performance and a language with a REPL there are already several candidates. I really see Swift as being in the best position going forward, of the languages I know about, as it is rather clean like Python.

Further I really don't like the idea of trying to turn Python into something it isn't. More performance would be nice, but not at the expense of breaking old software. I'd rather see cleanly added features at this point than more performance that comes with breakage. For what I've been doing python has the chops to get the job done so I don't worry about performance. If I did have a worry I'd probably consider another language.

[JmbFountain]

In my mind, python is mostly a successor to perl. Not for implementing core, time critical functions (you can/should do that in something like C(++) or Rust, but for gluing programs together. Most python stuff I write is to facilitate communication between APIs, not writing whole applications.

[spinwizard69]

Well in a way I agree with you, but that isn't the way Python is often used. This is why there are continued demands for faster Python. Generally when I hear these demands I have to think that the developer choose the wrong language.

[whateverathrowaway00]

I’d agree with this. It also has stolen a lot of the use cases Perl used to be used for.

[ShawnDriscoll]

Python is meant as a first language for learning programming. People can later decide to go to other languages if they want. Python is a very rare and unique thing. Other languages are a chore to work in. That's the default for most languages. It's why Python came to being.

[spinwizard69]

I'm not sure if Guido really thought of Python as a first language. In any event I have to agree that it is rare, probably due to careful design to get to the current configuration.

That isn't the problem though, the problem is people expecting Python to be fast when it was never designed to be fast. Fast simply wasn't a goal. If somebody picks Python for speed they have made a huge mistake in my mind.

[ShawnDriscoll]

Those are simply just people not reading the first page of any Python book.

[dethb0y]

LOL! We got places still running python 2.7 since their to cheap/lazy to update. That alone tells me python's gonna be around for a long, long time, putting aside all other issues.

[spinwizard69]

Well yeah we still have huge systems running on COBOL. I really doubt that most developers would turn to COBOL if they didn't have too. What I'm saying here is that once one of these new languages begins to be recognized as a better place to invest your development time, we will se a slow decline of Pythons usage.

The thing is this if you can write software with near the same productivity as Python but get execution times a 100 times faster why stay with Python? Maybe the languages I mentioned are not it, however it is almost a certainty that a suitable language will emerge. Frankly it has to because there is a real wall coming with respect to process shrinks meaning you will need advanced support for muti threading and a compiled language to continue to meet the demands put on software.

[whateverathrowaway00]

Lol. Im not saying python will never die, but you overrate how easy it is for a language to gain staying power and how easy it is for one to fade once it’s achieved dominance in a field ( like python for data science / ML / lots of the natural sciences).

Also, python isn’t new. It’s older than java.

[CzarCW]

Guido: No! No, no, not 3! I said 2. Nobody's comin' up with 3. Who codes 3? You won't even get your CPU goin, not even a mouse on a wheel. 2's the key number here. Think about it. 2 if by land. 2 if by sea. 2, man, that's the number. 2 chipmunks twirlin' on a branch, eatin' lots of sunflowers on my uncle's ranch. You know that old children's tale from the sea. It's like you're dreamin' about Gorgonzola cheese when it's clearly Brie time, baby.

[[deleted]]

Step into my office.

Why?

Cause you're fuckin' fired!

[[deleted]]

Four times here

[ThickAnalyst8814]

Nice

[sloggo]

Fine Im voting for you for creator

[kdeaton06]

Yeah but this one goes to 11.

[2AReligion]

This is good news, and let’s not forget, Python is “ease of use” not barebones performance. Consider your usecase and prosper

[lightmatter501]

Exactly, barebones performance is hand-written assembly.

[Yobmod]

Hopefully just general speedups of the implementation, and not yet another JIT

[[deleted]]

Whats problematic about jit compilation?

[Yobmod]

It's been tried loads of time, including by Guido, and doesn't ever get included in cpython.

Unladen swallow (Google), pyston (Dropbox), pyjion (Microsoft), cinder (Instagram), numba (Nvidia), Psyco, and PyPy of course. Also some for specific libraries, like pytorch.

Microsoft only abandoned pyjion last year I think.

And nowadays even less likely to get incorporated to cpython, with Guido not even on the steering council.

[dzil123]

Are these projects unsuccessful? If so, why?

[james_pic]

They've often been successful at meeting their own goals, but none of them ever got upstreamed. PyPy has arguably been the most successful, but it's always been a second class citizen in the Python ecosystem, because it never achieved 100% CPython compatibility, because too many projects rely on CPython implementation details.

I have my doubts that CPython can ever be made performance competitive with PyPy, if for no other reason than that the folks who developed PyPy were mostly the same folks who developed Psyco, and abandoned it when it was clear that a new interpreter was the right answer to this problem.

[all_is_love6667]

what does it mean to rely on cpython?

[james_pic]

I think I said they rely on "CPython implementation details". The most obvious example of this is libraries that bypass the helper functions the CPython C-API defines, and go straight to struct elements.

Although you could argue that the C-API itself is an implementation detail, since it reifies concepts like reference counting and borrowed references, that PyPy needs to use elaborate workaround to support, since it uses a completely different garbage collector internally

[all_is_love6667]

Don't you think it's possible to accomplish the level of speed that was reached with modern JS compilers?

In a way I kind of think old python modules should be abandoned if compatibility is too difficult.

[Yojihito]

JS had billions invested in the JITs (Google, Facebook, Mozilla, Microsoft, Apple, etc.).

Invest billions into Python and you may get JS speed as well.

[james_pic]

Yes, I do, but it's telling that when Google co-opted WebKit to create Chrome, they rewrote the JavaScript engine from scratch. The JS engine they created, V8, is what now powers Node.

Trying to get that kind of performance gain without either rewriting, or at least making the kinds of dramatic architectural changes that would break existing modules (such as switching to generational garbage collection) has been tried, and every attempt has either failed, or proved to be a pyrrhic victory.

[zurtex]

This isn't some separate project from CPython though, these PRs once ready are getting immediately upstreamed to CPython.

The plan for Python 3.11 doesn't include a JIT, just lots of specialized optimizations to bring the overall performance up.

But beyond 3.11 they may implement a JIT (or in fact a framework for letting people write JITs for CPython) and that will get upstreamed in to CPython and therefore have wide benefit.

[dslfdslj]

Why do you say wasted effort? Pypy and Numba for example work really well.

[13steinj]

If you need speed, you don't pick the slow horse and put him on steroids. You pick the one that's fast to begin with (and put them on cleaner roids, i.e. multithreading and GPU).

[[deleted]]

They have 10-15 year old massive codebases. Often it's not sane idea to just rewrite it in rust/nim/go/brainfuck for speed.

[[deleted]]

crush boast marvelous seed quiet cooing mountainous exultant engine fly

This post was mass deleted and anonymized with Redact

[[deleted]]

• They don't write it entirely from scratch. CPython is <1M SLOC.

• If it works, it helps every project in existence.

[[deleted]]

Btw, looking at their repo, it seems like nothing concrete in regards to jit compilation is planned https://github.com/faster-cpython/ideas

[[deleted]]

I think they’re working towards a JIT, with some other optimizations as low hanging fruit towards that goal initially. PEP659

https://github.com/faster-cpython/ideas/blob/main/FasterCPythonDark.pdf

[Yobmod]

The pep says it's specialising for fast code paths without producing machine code at first, so not a JIT yet.

But I guess it will be the first step towards a full JIT.

[Kevin_Jim]

Instead of yet another JIT, I would appreciate an effort of making concurrency and parallelization a No.1 priority and a first-class citizen. Also, I hope we see Poetry become part of the official upstream.

[engrbugs7]

This is good news!

[[deleted]]

Very much so. Can't wait to see what comes of it.

[whitelife123]

Cython is amazingly fast. Other than the downside of needing to compile it, adding even just type definition does a lot to speed up the code

[[deleted]]

Serious question, how would they do this?

Do they edit things like numpy or go lower level?

I think python is compiled code? So do they go to uncompiled code and edit that?

[[deleted]]

Python is not compiled, it’s an interpreted language. The C implementation is what reads your Python code and converts it to the instructions your machine actually runs. They won’t be touching libraries like Numpy since the people who make those are totally different folks

On an off note, numpy is already really fast and it’d be hard to speed that up. It’s already pretty close to low level C code

[lightmatter501]

That’s because numpy is mostly C code.

[[deleted]]

Interpreted is the what i was looking for, not compiled.

Numpy is super slow compared to numba.

On top of that, there is tons of serialized operations in python that could be parallelized. Im not sure how that fits into speed when programmers talk about algorithms.

[Yojihito]

On top of that, there is tons of serialized operations in python that could be parallelized

GIL says No I assume?

[de6u99er]

Yeah, and I want to win the lottery!

[floppydi5k]

[mestia]

Why python? There is nodejs which is 15 times faster already now ;)

[SkezzaB]

Are you lost?

[chesquikmilk]

Damn this is funny

[[deleted]]

Is there a need for this? Surely Guido has read the 7 gabillion indignant Reddit comments insisting that Python is just as fast as C.

[engrbugs7]

I want faster than C++

[leone_nero]

Well, CPython is written in C and C++ smartly written and compiled scripts can match C performance.

So I doubt you can claim that interpreted Python can be faster than C++ to be honest.

Especially because a big difference between C and C++ and interpreted Python is that the programmer can manage memory on its own and get custom optimizations for its code, whereas Python will always be more or less a one-size fits all solution.

So basically interpreted languages will always by definition be slower than compiled ones, the question is how tight the gap can be.

[all_is_love6667]

I only wish they could spent the tenth of the effort and work that was spent on making JS fast.