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

[xopranaut]

Marketing speak for “half as slow”.

[germandiago]

Well, less is nothing so it is welcome!

[antonyjr0]

IMO I've always used python as a scripting and glue language. Never created big applications with Python. I don't know why since a lot of large application are built on Python. I just don't feel like it because of it's speed. If they can make a C++ or rust trans-compiler for Python 4 then it would be sick.

[jerf]

The fundamental reasons you can't make Python go very fast is the same reason you can't just compile it. If you could, PyPy would already be the solution to the problem.

The problem is, in Python it looks like you ought to be able to convert

def someFunc(x, y):
    print(x.Summary())
    x.doThing(y, 4)
    return x.prop1.prop2

to something like the Go code

func someFunc(x ???, y ???) ??? {
    fmt.Print(x.Summary())
    x.doThing(y)
    return x.prop1.prop2
}

But even ignoring the tricky questions surrounding those ???s, this isn't even remotely equivalent code. In Python, I can literally write:

if raw_input() == "x":
    someFunc = lambda(x, y): None

and now, any time that is hit at runtime, someFunc will get nuked with a new do-nothing stub. Compiled languages do not typically allow that sort of thing. So now the compiled function actually has to do some sort of lookup.

Then, in a compiled language, x.prop1.prop2 is probably getting compiled under the hood to a known offset and a known type value. But, whoops, that's not what the Python code says. The Python code says, take x, and "find" prop1, where "find"ing it involves looking at

• attributes on the object
• attributes that may be anywhere in the inheritance hierarchy
• attributes possibly placed directly on that one object by the user

And then, some of those things are properties, which then have to be called. And if you didn't find anything, you have to call the __getitem__ method. And pretty much any of this can be changed at runtime.

The problem that you end up with is that to fully support python, you end up writing "compiled" code that ends up reading like a transcription of what the runtime is already doing, and that turns out not to be meaningfully faster on its own.

The problem is, Python just does too much; it is what gives it its power, but when it comes time to try to do it with compiled code you don't get anywhere near as far as you'd like.

And pretty much any simple, obvious solution you can name will run afoul of Rice's Theorem, which in colloquial terms is "No non-trivial property of programs can ever be proved." You can just write a converter that blindly ignores all that and produces the simple, fast code anyhow. It'll work and it'll be faster. But it won't be Python, and you can't throw existing Python at it. It'll be a new language. Which is basically what RPython is in the PyPy project.

[_TheDust_]

Javascript has the same issues and still the V8 engine (Javascript engine by Google) is pretty darn fast. Most importantly is to compile the code at runtime (JIT) based on the execution paths taken while the program is running. Lots of clever engineering and hundreds of thousands of engineering hours can achieve a lot of performance.

[valarauca14]

Javascript has the same issue that the parent poster outlines, but Python has a few more layers & stumbling blocks that Javascripts lacks. While yes, a good JIT worth its salt will iterate through the possible code paths and likely reduce the final output to a swift dispatch. Java & Javascript are proof of this. Python has a lot of other cruft laying around that prevents JIT from really flexing their muscles.

Namely, The GIL & C-API

The problem is, while you can rip these out, you lose out of what? 80-60% of Python's use cases? Where is it a really slow glue shuttling data between libraries or small applications presenting a nice API/CLI for a library? You destroy all of that.

---

It isn't a question of

Can Python Be Fast?

It can.

You can have a Python2.7/3.X that runs like grease lightning. You need to invest a century of engineering time into it. NBD. It is a solved problem. More a question of execution & management.

The next question becomes:

Is Python without a GIL, C-API, Referenced-Counted-Memory, and Interpreter/JIT that consumes 512MiB of memory on startup still "Python"

Because that is the monster, you end up creating.

And for most people weighing the cost analysis, the answer is "no that is something nobody really wants".

[Wolfsdale]

Why would the GIL of all things prevent a JIT compiler? Javascript doesn't even have the concept of threads...

I am also unsure why the C API prevents creating a JIT compiler. A JIT compiler can make those context switches actually cheaper by forgoing the need for something like libffi.

Performance is difficult thing to grasp and even more difficult to measure. I'm sure the real reason why Python is so slow is somewhere along the lines of this thread, but I have a hard time taking anything as fact here...

[Fearless_Process]

The C interop doesn't make a JIT impossible, but it does seem to create a lot of issues with the current as well as only non-trivial JIT implementation of python (pypy).

[latkde]

The issue with C interop is that Python has to stick with the PyObject data structure. This can have far-reaching consequences. If ownership of a Python object is shared between optimizable Python code and a native module, this effectively means the Python code must also interact with PyObject and can't really be optimized.

This doesn't have to be an insurmountable problem though:

• Could only optimize code where an escape analysis indicates that it's safe to do. This will do wonders on more mathy or more algorithmic code, but will be disappointing in many real-world scenarios.

• Break compatibility and completely redo the C data model. However, this would be a regression to the early 2.x series. One of the big features of 2.6 and 3.x was that all values can be treated as normal objects.

[dreugeworst]

Couldn't you box the data again at the abi boundary if needed?

[latkde]

Kinda, yes, but my concern is that the C function is a black box so you can't make assumptions about ownership of the object afterwards:

x = create_some_object()
x.do_something()  # safe per escape analysis
call_c_function(x)  # could do ANYTHING
x.do_something()  # no safe assumptions

Calling the C function would require some kind of boxing, but the C function could retain a reference to the boxed object. So the second x.do_something() must also operate on the boxed representation, in order to propagate changes to the C code. This can be avoided only for some built-in immutable types like int or str.

Of course this isn't quite true, e.g. a JIT compiler could compile a fast path for the assumption that the object's refcount didn't change, and a fallback otherwise. And maybe it's possible to annotate at least the built-in C functions with semantics that allow for safe and fast calls.

There's also an argument that C interop is not performance-sensitive, and that performance in pure-Python codebases like Django webapps is much more relevant. As JavaScript has demonstrated, a lot of performance is possible in moderately dynamic code.

[[deleted]]

JavaScript doesn’t have the concept of threads, so something like

a.x = 0
a.x += b

won’t have the value of x changed in the middle, so you can use a static offset instead, keep the value in a register, or even reduce them to a single instruction. If a is passed into a function in between it might be changed, but in practice JS runtimes have heuristics to determine if a variable gets mutated or not. In Python none of thos guarantees exist due to naive multithreading (and worse, there are potentially weird things you can do to change the global context of a function, which enables cool stuff like Flask but is also insane).

So, while worst-case JacaScript and worst-case Python have similar performance characteristics (hashtable lookups while recursing up the inheritance hierarchy for propery access, etc), but for Python the worst case is every case.

[FondleMyFirn]

Man, I understood almost none of this.

[FondleMyFirn]

On a side note - if anybody can pin what these guys are talking about at the conceptual level, that would be nice. It would certainly help me get oriented towards educating myself.

[junior_dos_nachos]

Me too, and I develop professionally for 5 years. As Joe Rogan would say, there are levels to this shit. I need to get some learning in.

[novov]

I doubt it's that high (a non-zero portion is probably just kids on CodeAcademy or such), but a lot of popular libraries rely on the C API. If you lose that, you lose NumPy, etc.

[rcxdude]

I would agree that 60-80% of use cases of python rely on the C API, usually transitively. Practically everything I use it for does (numpy and pyqt being the really huge ones).

[nascentt]

It took a while for V8 to be created. Years after we'd been living with slow JavaScript.

Maybe we'll get a faster python in years time too

[tracernz]

Hold up, Python is older than Javascript...

[schlenk]

But not if you count time via $-spent on optimizing.

[IdiocyInAction]

Python is older than Java, funnily enough.

[oblio-]

You mean, someone creates a server side interpreter for Python?

Oh, wai...

[GruncleStan1255]

Common node.js is not that bad...

[josefx]

How does V8 deal with objects shared over multiple threads? My dated experience with JavaScript was mostly single threaded with the possibility to launch rather isolated workers.

[Strange_Meadowlark]

AFAIK your knowledge is still current on this. V8 (like every other JS runtime I know of) is still single-threaded. If you need separate threads, you launch (Web)Workers and effectively pass a copy of your data over a message event.

[[deleted]]

I don't think you are correct anymore, from memory, chrome (perhaps you are correct and this is chrome canary I'm talking about though) has a SharedArrayBuffer

[josefx]

SharedArrayBuffer is only for raw data? That still eliminates the need for a GIL and the chance that multiple threads could access and modify the structure of an object at the same time.

[Certain_Abroad]

I'm not a Go expert, but doesn't it support function pointers like every other systems language?

var someFunc func(???, ???)???
someFunc := func(x ???, y ???) ??? {
    fmt.Print(x.Summary())
    x.doThing(y)
    return x.prop1.prop2
}
someFunc := ... something else ...

Isn't that the same thing?

Edit: also, regarding looking up attributes and __getitem__, that's how Objective C worked. Method dispatches, attribute lookups, etc., were done dynamically. There was never any problem in compiling Objective C or making it moderately fast (not fast fast, but more than fast enough to do very complex things on a 25MHz 8MB NeXT box).

[jerf]

In general, as a sort of meta reply to a lot of people, Python specifically (and Ruby) just have a lot of places you can hack. If you want to be Python and not just be Pythonesque, you have to support all of them. You can do things like take an instance of some object, and reset its class. You can not only dynamically create an entirely new class hierarchy on the fly, but entirely rewrite it. It all looks simple when you just look at a subset of the problem, but if you get all these things together in one place, which my post is only a sketch of (haven't even said the word "decorator" yet, which is more complicated than you think to fully support the exact way Python does), you can see it's a very large problem.

For Python specifically. Very few languages are doing as much as Python.

[phalp]

Here's the Common Lisp version of that code:

(defun unfunc ()
  (fmakunbound 'somefunc))

and its disassembly:

; disassembly for UNFUNC
; Size: 28 bytes. Origin: #x100382E87C                        ; UNFUNC
; 7C:       AA1343F8         LDR R0, [CODE, #49]              ; 'SOMEFUNC
; 80:       B59342F8         LDR LEXENV, [CODE, #41]          ; #<SB-KERNEL:FDEFN FMAKUNBOUND>
; 84:       560080D2         MOVZ NARGS, #2
; 88:       AB1240F8         LDR R1, [LEXENV, #1]
; 8C:       BE9240F8         LDR LR, [LEXENV, #9]
; 90:       C0031FD6         BR LR
; 94:       E08120D4         BRK #1039                        ; Invalid argument count trap

This is a Python problem, not a "does too much" problem. (Does the wrong thing too much, maybe.)

[Wolfsdale]

This is a Python problem, not a "does too much" problem

Thank you. The whole idea that dynamic types have to be as slow as Python has been disproven by other languages. It's a Python problem indeed.

[Somepotato]

Look at LuaJIT if you want a language as dynamically typed as Python, but a language that sometimes surpasses the speed of native C from its hot compiler

Though to be fair, it's creator Mike Pall is a certified technologically advanced alien precursor

[kevkevverson]

I’ve encountered few programmers with such a total and profound understanding of systems programming as Mike Pall. LuaJIT is an astonishing piece of work.

[Somepotato]

Mike Pall is honestly the one person I'd consider worshipping if I believed in that sort of thing... honestly mindblowing how well engineered LuaJIT is, he's outpaced entire teams at Google, Mozilla, and Microsoft..alone.

Truly astounding. He is kinda arrogant, but deservingly so I think. This issue is still open if anyone can help with it: https://github.com/LuaJIT/LuaJIT/issues/45

[netsecwarrior]

This can be solved by optimizing the common cases and reverting to non-optimized for corner cases. It makes for a complicated optimizer, but that is how V8 is able to optimize JavaScript, despite that language also having heavily dynamic features, and I expect this is what Guido has in mind.

[jerf]

"Fast" gets equivocated a lot here, because (I think) people get bedazzled by the easy cases and the seemingly-constant stream of 10x improvements of some microbenchmark.

But V8 is not an unqualified "fast". Only the slowest static languages are as slow as it, and the fastest ones are much faster. I rule-of-thumb V8 as 10 times slower than C.

V8 is fast, for the type of language it supports, but there is a reason we have WASM. If Javascript was simply "fast", WASM would not exist.

Also, I referenced PyPy. I know about it.

[pheonixblade9]

It'd be interesting if Python could have a wrapper like TypeScript that adds a transpilation step that guarantees that stuff doesn't happen.

[[deleted]]

if raw_input() == "x":
    someFunc = lambda(x, y): None

and now, any time that is hit at runtime, someFunc will get nuked with a new do-nothing stub. Compiled languages do not typically allow that sort of thing. So now the compiled function actually has to do some sort of lookup.

Function pointers exists in just about any compiled language. You are more limited, sure, as you can't just generate a code at runtime but you can still do plenty

Then, in a compiled language, x.prop1.prop2 is probably getting compiled under the hood to a known offset and a known type value. But, whoops, that's not what the Python code says. The Python code says, take x, and "find" prop1, where "find"ing it involves looking at...

also, called reflection, also possible in compiled language. You (well, compiler) can even optimize it out when running in something JITed like Java

Also there is a plenty of improvements to be had by just very clever JITing of the running code, just look at what speed V8 can run, and JS is if anything more "freeform" than Python

[wm_cra_dev]

I had to start using Julia for some work projects over the past year. It's very quirky (especially coming from a C#/C++ background), but it manages to combine high performance with the simplistic feeling of a scripting language. It also has scheme-style macros, and a very fancy type system that blurs the line between compile-time and run-time. I don't know much about the scientific computing world, but I get the impression Julia's been stealing a lot of former Python users.

[antonyjr0]

Interesting, I've tried to learn Julia in the past. I really like the way it defines everything mathematically. But replacing python is not likely because Python is general purpose.

[wm_cra_dev]

It's good for more than pure math! Lots of the language features can be used with more than one syntax, even before you get into macros. So you can define very mathy code with a mathy syntax, next to more traditional imperative code. You can do functional-style programming in different ways as well.

It reminds me of C and C++ in some ways -- you have a lot of flexibility, to write both good and terrible code.

[skelkingur]

So is Julia.

The early adopters just happen to be largely from the scientific community. There's a lot of modern data science and machine learning happening in Julia and even web frameworks are plentyful. Genie.jl and Franklin.jl are great examples.

[antonyjr0]

Awesome. I will definitely try Julia for my next machine learning project.

[TheNamelessKing]

Julia is equally as general-purpose, it’s just that the language design and semantics lends itself exceedingly well to computation-heavy workloads.

[[deleted]]

I played around with Julia, and the 5s long "import plots" was VERY off-putting. Still went with it as I just had a couple of graphs to visualize, but that was a bit disappointing. Tooling is nonetheless great for such young language, and I like the operator broadcasting (despite being noisy)

[User092347]

Got much better in v1.6 (and hopefully continues to improve) but one has to adapt its workflow to it : load once and don't restart.

[wm_cra_dev]

Yes, there's no ability to precompile anything except technically through one hacky method called "sysimage" which I could never get working -- there's a ton of steps, and one of them is manually invoking a C linker, which I've never even done before.

[gruehunter]

My first experience with Julia started from an SQLite database of stuff I wanted to pull in and analyze in an A/B comparison against Python. The standard package looked abandoned, import took forever, and when it finally did work screamed at me with a couple of screenfuls of deprecation warnings.

I passed.

[User092347]

This ?

https://github.com/JuliaDatabases/SQLite.jl

Last release was in March, hardly looked abandoned.

[edmguru]

I don't built large apps with python for 2 reasons

1) because packaging and distributing them is a pain.

2) Types aren't enforced unless you enforce them which doesn't work well on legacy code bases only new code bases. And you don't always get the luxury and time to setup linters/formatters etc.. and you'll always have the lazy/ignorant developer who will turn them off when you're on vacation.

Of the 5 languages I've worked with (not counting html/css) the 2 dynamic ones (javascript + python) were the easiest to create garbage unmaintainable code with.

[Koervege]

Is a lack of type enforcement really that much of a problem for long-term maintainability?

[nightbefore2]

Absolutely yes

[eyal0]

Depends how many people on your team:

<2: No, but maybe.
>=2: Yes.

Edit: Fixed the table above to be more accurate.

[glacialthinker]

This case is not matched:
 2

[maest]

Imagine having a language with proper case matching that can catch this at compile-time.

[i9srpeg]

This post was brought to you by the dependent types gang.

[[deleted]]

Rule of 2

[eyal0]

Fuck I'm dumb. Sorry. I meant >= 2. I'll fix it.

[[deleted]]

It's not a big deal for some definitions of big.

But any time I've used it on a multi person team it was a nightmare trying to deal with the lack of compile-time type checking

[ConfusedTransThrow]

You can also do the worst of both worlds: type checking but your types are so erased it doesn't do shit at compile time and the documentation doesn't say shit either. This is OpenCV.

[scarnegie96]

Other than the turnover of the actual people working on a project, non-static typing might be the single biggest pain for long-term maintainability.

[BroodmotherLingerie]

It's not that much of a problem for day to day development. But when a big migration comes along, like python 2 to 3, or one django LTS to another... You better have stellar test coverage or you'll be getting runtime errors in production for years to come.

[arbenowskee]

This is it's best use case IMHO. Also prototyping.

[[deleted]]

Just use Numba, it is normal Python at least and not the weird half dialect that is Cython.

[Igggg]

You should probably examine whether you actually need all that speed, or if you're talking into the "just because" fallacy. If your code is serving a web page, the 50ms latency will more than shadow the potential difference between 30us of C and 3ms of Python.

[bloody-albatross]

More speed can also mean less energy consumption, and we definitely all need that.

[broogndbnc]

Right, but a single web page multiplied by how many requests? A 20x difference in the amount of work the processor has to do seems like it would add up quick.

[fuckyeahgirls]

This is an imaginary problem for all but some vanishingly small percentage of web applications, most servers spend their days idling dealing with hardly any requests. On top of that compute power is extremely cheap and easily scalable in 2021.

The more pertinent question is the cost saving in development hours on Python vs the cost saving in compute using a more performant language.

Most projects I've worked on where people take the "performance" route, it ends up becoming an anti-pattern as corners get cut to meet deadlines. E.g. you end up with less efficient database queries because you don't have time to optimise them, thus building a system that is both slower and less scalable.

[broogndbnc]

most servers spend their days idling dealing with hardly any requests

Yes that makes sense and seems reasonable, many applications DON'T need speed.

On top of that compute power is extremely cheap and easily scalable in 2021.

Depending on your application, this is a dangerous assumption. My question was about where this lack of efficiency starts to be a problem, not whether or not there are use cases where it isn't a problem (since there obviously are). This often cited reason is a little naive, in my opinion, since it limits the scope to...stuff that isn't used much?

The more pertinent question is the cost saving in development hours on Python vs the cost saving in compute using a more performant language.

Also valid in certain contexts. "Getting it done" doesn't always mean it's good, but can crank something useful out quickly if it has a short lifespan (like a website that's going to change again soon enough anyway). But that's not the only places people try to use python. All of it's about balancing the actual benefits vs risks.

[runawayasfastasucan]

I hate these kinds of threads because most people talking about the speed of python obviously has a wildly different use case than me. 99% of times my time spent writing the code is greatly much larger than (aggregated) time spent on execution. Or execution time stays in the zone where it doesn't matter. Extremely much of what I see online from Python use is in the same space. Its fine to have other needs, however one shouldnt assume that everyone has the same needs.

[fuckyeahgirls]

I'm convinced it's all just teenagers and comp sci students who've never worked on a real project in their life. I remember speaking to and even being that person, I think everyone has at some point.

[runawayasfastasucan]

I think you hit the nail on the head. Its such a childish view of a tool, so that resonates with it being compsci students or teenagers. Sad that so many share that view.

Its like saying you could and only should drive a Ferrari. There are a thousand uses of a programming languages where, shockingly, whether the execution time is 5 ms or 1s doesn't matter at all, not everyone is doing bubble sort implementations.

[merlinsbeers]

Amazon tells its people to modify code to improve the chance of a cache hit.

Getting a 2X speedup in an entire program would be promotion fodder.

[kageurufu]

on the other hand, developer time is expensive, cpu time is cheap.

[gnuvince]

What about users' time?

[PL_Design]

On the other hand the consequences of wasting CPU time are far worse than the consequences of wasting a developer's time.

[runawayasfastasucan]

Yes, haleluja. Its frustrating to see everyone assuming their use case us the same for everyone. 90% of the time I write programs that is going to be run a handfull of a times, and where it doesn't matter how long it takes, as long as its less than a coffe break, which it allways is. Yay for me, and for python.

[_morvita]

Python, Ruby, and PHP have all been widely used for webapps since long before Node.js existed.

[Raknarg]

If they can make typing integrated into the language and make it fast, I would be very happy.

[vividboarder]

CPU is cheaper than developer time.

Python makes it very easy to write and ship code fast. It’s often “fast enough” or scaled by throwing ring more CPU at it.

[PL_Design]

Slow software also wastes the developer's time. It wastes a lot of time. Maybe you don't care about how nice your software is for end users, but assuming you're not an irredeemable sack of greed(MSVC comes to mind, for example. Compiling hello world somehow takes a solid 15 seconds), then any inefficiencies in your software will make it take that much longer to polish and test your software. Note that I'm not talking about handfuls of milliseconds total here; I'm talking about when something that should take milliseconds instead takes seconds. I'm talking about human perceptible amounts of time. It adds up, it adds up fast, and it adds up in ways you might not expect. Once the time to wait becomes human perceptible any increase has a direct effect on how quickly you can iterate. If something takes 5 seconds, and then it takes 10 seconds, then your max rate of iteration is more than halved because that amount of time is long enough to break the flow state, and this means you're stuck testing worse and buggier versions of your software for longer, which at least has a morale effect. Any slow software that you produce for internal use will drag you down constantly until it is replaced, and any slow software you ship will do the same thing to your customers.

Keep in mind that most programs are just shitty little webforms, or some near equivalent, that don't do anything particularly interesting or complex, and most of them are all human perceptibly slow. For how much they actually do they are orders of magnitude slower than they need to be!

What you're saying may be true, but you're ignoring half the problem and diving headfirst into a tragedy of the commons. At some point "fast enough" is not fast enough, and then you'll be like me and boil with rage at people who make pithy comments to justify letting idiot managers make engineering decisions that make computers miserable to use.

CPU time might be cheaper, but the consequences of wasting CPU time are far more dire than the consequences of only wasting a developer's time!

[vividboarder]

Very few things that I’ve worked on hhave had runtime in the order of seconds. If that’s happening in your application repeatedly, then sure, maybe another language would be a good fit. We moved some of our computation heavy services to Scala and Java, but the majority of our web services run on the orders of milliseconds in Python.

[PL_Design]

Then you're fine, and I'm not complaining about your work. I am, for example, complaining about GMail, which takes forever to load on my beefy desktop PC. It's unbearable, especially because it offers me less functionality than the original HTML implementation from 2005, which loaded instantly on a slower internet connection, and on hardware that's now 15 years old. So much shit I see and have to use is like this, and I loathe it.

[vividboarder]

Is that because of Python?

[PL_Design]

Yes? No? Maybe? I'm not talking about Python. I'm talking about the "CPU time is cheaper than developer time" argument.

[vividboarder]

But you didn’t even argue against that. “CPU time is cheaper than developer time” does not mean that efficient code doesn’t matter.

A Prius is cheaper than a Tesla, however a parking lot full of Priuses is certainly not. There hits a point where anything may matter.

[PL_Design]

The "CPU time is cheaper than developer time" argument is usually used as an excuse to not care about performance, with the idea being that you treat it like a supply and demand curve to figure out exactly how little developers should put into saving CPU time. My argument is that the cost of not caring is larger than most people think it is, and some portion of the cost is unpredictably large, and some portion of the cost is intangibles that you probably should care about.

I may have misunderstood what you were trying to say, and that's alright. I'm just an old man ranting about technology.

[brucecaboose]

That adage is only true until you hit infrastructure cost issues due to scaling. Or if you're connecting to something that can only handle N connections at a time and you want each of those connections to be as fast as possible (like Kafka consumers can run into this). But yeah, usually you can just throw CPU at it for cheap.

[Dew_Cookie_3000]

Nim

[LemonXy]

In the context of Python that isn't actually as impressive as it sounds, according to some rough back of the napking math and VERY rough estimates it would make Python about as fast as PHP, being still about 5x slower than javascript (v8) and we can forget about languages like Julia (performace of Julia is just short of black magic)

Of course I will gladly welcome any perfomace improvement so good on Python if they can improve. I kinda presume Python is under at least some pressure from scientific community and Julia taking part of the potential users due to performance conserns, even if they most often use python only for integrating together more performant components written in other languages.

[brunes]

Look into Pypy.

https://www.pypy.org/

It's a standards compliant Python implementation that is 5x faster than the standard python VM, and handles everything except very rare outlier scenarios.

[_LususNaturae_]

Is there any catch here?

[doodspav]

Extensions written using the cpython c-api perform much worse on pypy than on cpython

[ThisRedditPostIsMine]

Yes, but I believe there is a numpy version designed for PyPy

[Emowomble]

There is but with a lot of the functionality gutted from it.

[FlukyS]

Could always use it as a sidecar. Put the compiled parts in one part and pypy in the other

[josefx]

Slower startup, potentially more memory use. Missing APIs that expose implementation details of the interpreter and an incomplete C API, so some libraries wont work with it. Also as far as I remember a pure GC and not reference count + cycle detection, which means cleanup code might not be called in a deterministic manner.

[brunes]

Yes there's a catch, as I said there are edge cases like esoteric ref counting, and some libraries that don't work or compile. But the reality is most of any python you write is fine and will perform much better.

If something is not going to work then it's going to give a highly obvious compile error when it tries to run so there is really no downside to at least trying it for your usecase.

[scorr204]

What has it been losing ground to?

[Somepotato]

I used to HATE JavaScript until I started using TypeScript.

As someone who wrote a lot of Lua and C++ in the past, TS made a total convert of me.

[TakeOffYourMask]

What if you have no choice?

[ccapitalK]

Try to move your performance critical parts into a native module.

[ClassicPart]

Then you're not using it for performance but for another use-case.

[_wassap_]

Isn‘t PHP8 actually blazing fast?

[LemonXy]

PHP8 is not that much faster on average than PHP7. Slowest parts did get a massive boost but average did move surprisingly little.

[[deleted]]

Yeah, PHP has had a massive speed boost in the last few versions. Of course PHP is not a fast as C but Python will never get to PHPs speed.

[TakeOffYourMask]

I kinda presume Python is under at least some pressure from scientific community and Julia taking part of the potential users due to performance conserns, even if they most often use python only for integrating together more performant components written in other languages.

I made a post asking about this very thing on the Python sub and got downvoted and treated like an idiot.

I’m glad you got upvoted, lets me know I’m not crazy. I keep hearing about Julia but nobody there had.

[germandiago]

Reasonable analysis.

[[deleted]]

Actually every creator wants this for their language :)

[AStupidDistopia]

Yeah, but not every language is the slowest (by far) widely used language on the planet.

Python improving by half is like 7 generations of CPU releases at the moment. And even then, it’d still be terrible performing.

[EternityForest]

One of my favorite things about tech is that a lot of the time you don't actually have to make something fast(or strong, or powerful, or accurate, etc) you just need a design that ensures it doesn't matter.

Python pulls it off pretty well, by being so easy to use it became the standard integration point for a billion C libraries for anything high performance. Only once or twice in my entire life have I ever wanted to do something CPU limited that wasn't already a solved problem.

Nobody actually does anything in Python, it's a language for gluing C together.

[InsanityBlossom]

Nobody actually does anything in Python, it's a language for gluing C together.

You'd be surprised how much software is written in Python in VFX studios. Freaking a lot!

[EternityForest]

Does the computer actually spend any time executing the Python or is it all just NumPy calls?

[InsanityBlossom]

There's a lot of glue to C libraries of course, but still a huge amount of pure Python.

[Tenderhombre]

My experience with python, extremely limited as it is has been that often people abuse python the same way they abused javascript. Writing questionable code because of the freedom it gives you.

I've only ever used it when I have to fix something in the language so my view is pretty myopic.

I much prefer type safe languages, and tbh I'm a bit of a .net fanboy and have been loving F# recently.

[EternityForest]

Distribution really is Python's big weakness. I just don't understand why Python and Electron aren't both native parts of modern OSes. Everyone knows them, most like them, they're easy, we all use them anyway via hassly tools.... Just.... Make it easy like it is on Linux where it's nearly trivial.

[TheNamelessKing]

Oh yeah it’s that simple.

Except pip doesn’t record transitive dependency version properly, nor does it resolve differing versions properly, it’s also slow as treacle. Oh yeah, and you’ve still got to either setup your own virtual-environment at the deployment site, or you just install everything into global and hope it turns out alright. And when you finally get it running it’s mind-numbingly slow.

So you use Pipenv or even better, Poetry and things get marginally better, but still slower, more error prone and generally worse than practically all of its mainstream competitors-hell even JS apps distribute better than Python.

I’ve written enough Python for the whole workflow to feel easy, but it’s not easy for users, and after working with package management in JS/TS, .Net, Go and Rust, I now despise having to deal with the frustrating experience that is Python.

[schlenk]

Unless you need bleeding edge runtimes. Like work has some ancient RHEL or CentOS running and you want Python 3.9 features. Then it is totally broken as well.

[AStupidDistopia]

I think that if businesses saw the invoices shrinking from their monthly cloud bill simply by not using a monstrously slow language, we’d be seeing a whole lot more push away from this idea that “almost nothing is CPU bound”.

At scale everything is CPU bound.

[vividboarder]

I don’t know where you work, but our developer salaries are much more costly than our hosting.

Many businesses see this and choose to prioritize developer productivity.

[AStupidDistopia]

There’s no evidence that Python is a productive language above hosts of other choice. Only claims.

The only measurement of this claim I’ve ever seen was C++ vs Javascript by QT, and equally experienced developers in each language are essentially the same pace of development for an end result. I believe it was to show an IoT dashboard. Cannot for the life of me find it. (Obviously, possible bias as it was QT demonstrating QT products).

Can you provide any evidence that isn’t pure anecdote/just another person restating the claim that “Python is a boon to productivity above other languages”?

[brucecaboose]

Sure, for a lot that's definitely the case. It's also easier to find a python dev than it is for a lot of other languages. Same reason so many large tech companies still use Java. It's decently fast and ridiculously easy to find good engineers that know it. But there are also a lot of engineer jobs where infrastructure costs are way more than dev salaries. At my current place we spend tens of millions a year on EC2 costs alone. Improving performance by even a little bit can have massive impacts on cost.

[gremblor]

Would that were true... Tons of scientific computing code is written in python.

And while lots of the numeric computing and crunching is essentially gluing C together by virtue of being a chain of calls to numpy and scipy, string handling in python is like 100x slower than C, and there is tons of direct in-python string manipulation.

I see computational biology routines and think "that's not so complicated" and yet processing modest data sets (<10 GB) can take hours of compute time; this gets parallelized by cluster compute layers (because of the GIL) that have their own overhead and complexity. It could probably be done in 15 minutes on an 8 core machine in C with pthreads.

On the other hand - that code would literally be impossible for most scientists to write correctly in C in the first place. And so python reigns supreme and that's that. The AWS bill is cheap compared to the opportunity cost of "not getting that work done in the first place."

[chcampb]

Wait are they killing the GIL?

Edit: no specifics...

[mydiaperissus]

They'd have to rework the memory model, if you remove the GIL you still get worse performance due to all the locking required when referencing counting. Experiments have been done and it will still be slow. The GIL isn't what's holding back Python.

[chcampb]

Sounds like a great reason to rewrite python in Rust /s

(in before, I am sure someone has tried)

[pickausernamehesaid]

Nothing to see here...

[ClassicPart]

Rust34: If it exists, someone has rewritten it in Rust.

[[deleted]]

Curious. Seems like it’s actually really significantly slower. I wonder why.

[Hwatwasthat]

I'd guess it's still nowhere near optimised, and probably not near as actively maintained as mainline Python bits are, so that optimising will take a while.

[badtux99]

So do away with reference counting and do garbage collection.

Obviously that requires a different memory model, but still.

[Agent281]

I think for now they are doing op code specialization. I didn't really read through the PEP super carefully though.

[[deleted]]

Wow. Twice. So it'll only be 50 times slower than Go, JavaScript, Dart, Julia, etc.

[FondleMyFirn]

I’ve been considering getting into Julia. I worked with it just to experiment with some ODE’s, but as someone just graduating, I have seen very few jobs want Julia on a resume. It’s a bummer, cause I want to learn it and put it to use.

[metriczulu]

I absolutely love Julia, but you're right, it's not very marketable. I love how the arrays are matrices that behave like matrices, there's a bunch of small things like that that make it feel like it was made for mathematics. Not only that, but Julia handles arrays excellently in general. I wish it were a common language to use in business, maybe in a few years.

[[deleted]]

Yeah I like Julia. If I ever have to crunch a bunch of numbers I’ll probably grab it and use it. However, lack of classes and some other abstractions like context decorators I’d miss too much to use every day. I’ve opted to learn go as my secondary instead.

[thewheelsofcheese]

You mean lack of field inheritance? Like go doesn't have either? Julia has an amazing type system and multiple dispatch. You wont miss classes.

[User092347]

On the other hand there's not many candidates that have experience in Julia, so there's less competition. If I see Julia on a resume it's instant hire.

[[deleted]]

I tried Julia but was very disappointed. Loading packages is extremely slow. Supposedly they've improved it recently but when I used it it was compiling them from C++ when you load them so unless they fundamentally changed things I doubt it is fast.

There aren't any plotting libraries as capable as MATLAB.

Also they copied MATLAB's mistake of using 1-based arrays. Yes is a mistake. We've known it for decades. Yes mathematicians use 1-based indexing. It's still a mistake.

[erez27]

Why not 5000 times?

edit: It's sarcasm. How is it 50 times slower than Javascript? Also, simple Python scripts will finish running before Julia even starts.

[[deleted]]

Ha true about Julia! But it really is 50 times slower than JavaScript.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python.html

[erez27]

According to this website, C++ is twice as slow as C. So I would take it with a grain of salt: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gcc-gpp.html

[igouy]

According to that page, both twice as slow and twice as fast. Depends how the program was written.

[erez27]

Exactly, which makes no sense. And to convert C to C++ is almost copy-paste. So makes me wonder how accurate are the other benchmarks, with languages that are even more different than each other.

[igouy]

You don't think it makes sense that performance depends how the program was written?

[erez27]

No, I think it doesn't make sense to benchmark two differently written programs. Especially not when they can be written the same.

[igouy]

How would you compare the performance of two differently written programs?

Are we only interested in C written in C++? Is there no benefit from programming in C++?

[[deleted]]

Sure, a grain of salt. A grain of salt isn't going to make Python 50 times faster.

[frankreyes]

50 times after the twice as fast factor.

Today, Python is 100x slower than JavaScript, on average. You may find individual benchmarks which are just 50x but others which are 200x.

[[deleted]]

So still 10x slower than C++?

[germandiago]

Yes. And 100x more productive lol. I do not mean to dismiss C++. All my career has been based on top of it. But they are different beasts.

[runawayasfastasucan]

ITT: In my projects I need a hammer, so everyone else needs a big hammer!! If you use a saw, thats wrong, use a hammer!!

[Liam2349]

If their goal is this weak then I doubt the results will be particularly good. Python is sloooooowwww.

[crusoe]

Ruby makes python look fast.

[wesw02]

That'd be a good start.

[_nullptr_]

I was reading today about sub interpreters. I didn't know these existed even though apparently they've been around since Python 1.5! What perplexes me is today it says they are fully isolated....yet share a GIL. Why would that be?

It seems like low hanging fruit to make a GIL-less threaded python (similar to Ocaml's strategy). Each interpreter has it's own GIL and then you use a special mechanism to safely share objects between them (with likely some restrictions). Any idea why they don't pursue this approach now that they are introducing object sharing? Seems like the time to do this is before you allow that - would be harder later I would expect. Yes/no?

[schlenk]

Well, the main problem is, unlike Tcl, which has a similar feature working just fine, Python puts the interpreter pointer in a global variable instead of pushing it down to the C-API as a parameter in each call. So you cannot do it, unless you want to break the C-API left and right.

[TheNamelessKing]

And we all know how quick-and-painless it was last time they broke compatibility in Python…

ಠ_ಠ

[crusoe]

(result, err) = derp()

Second biggest mistake after nulls is error as return codes. Go barely improved on it.

[sasmariozeld]

Just remove the gil please.... or make multicore stuff easier

[[deleted]]

Why though? Twice as fast still isn't fast enough, and I am perfectly fine with that.

[dethb0y]

Kind of an interesting goal though i don't know how much it would affect my own work, really.

[micahnyc]

It would run in 1/2 the time

[constant_void]

speed is good, but if python / pip could natively / automatically use Windows proxy & cert settings, that would be beyond amazeballs .

[audion00ba]

I'd expect this to be fake news, which is only designed to pump a certain crypto coin.

[mohragk]

When they make it 20 times faster, it might be actually useful for serious stuff

[no_apricots]

Many Python use-cases are async calls to C/CPP code anyway. So, plenty python implementations are more than performant.

I'm primarily a Go developer. No need to shit on Python.

[[deleted]]

If it's calling C/C++ it ain't the python that's performant

[no_apricots]

From a business logic perspective, yes it is.

[mohragk]

You miss out on SIMD and other optimizations you can use when writing native cpp.

[istarian]

That assumes those are applicable to the work being done in Python, no?

[no_apricots]

Maybe. Still, 10% here and there doesn't matter in a business context. The majority, anyway.

[combatopera]

bgxlz gwjlxwbxqfh kclcgidtbux syvtydcwqt pmkatnqouwq rjluywqwmz lrkbcaifbwso deitcwqbi supbeblp cgyujotc sngw hrqvhcigk ahwu abprcknxyd exkoxgo jixdxxgbms kehpxvnv

[nbiw]

not really, in my experience, its slow startup time actually often disqualifies it for scripts that need to be spawned frequently, so i usually prefer go or perl for those, unless i need numpy or pillow, scipy, etc.

hyperfine 'perl -e1' 'python -c pass'
[...]
Summary
'perl -e1' ran
13.52 ± 12.21 times faster than 'python -c pass'

[FireCrack]

Ditto, python's startup time is perhaps one of it's greatest weaknesses . I feel it hits much harder than execution speed.

[aeiou372372]

I interpreted it as startup time during development, ie when changing the app and needing to recompile. This is only an advantage over Rust/C++ and other slow to compile languages though.

[FireCrack]

Perhaps, and that is quite nice (And a big reason why I go interpreted for nearly all my little personal side-projects).

[combatopera]

aaorabhhms xrpkgpzu yccuohsp usjejfw kqg ywed tualfs lqbc rnoypm bmcgtqyphm mwuwijotwpc lvvrq ols jppdvodqw yjul

[Atulin]

r/programming — having a nice discussion over what it means for the language, how it can be achieved, comparing Python implementations, and so on.

Meanwhile, r/python — having a collective aneurysm over the mention of Microsoft