Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python performance myths and fairy tales

lwn.net

Post reply on HN
Print view View original

111–120 of 221 posts

Re: Python performance myths and fairy tales

#111

Post by nu11ptr »

nyrikki wrote: post #105
nu11ptr wrote: post #62

Earlier quoted context omitted.

I would argue this isn't true. It is a big part of what makes it slow. The fastest interpreted languages are one to two orders of magnitude slower than for example C/C++/Rust. If your language does math 20-100 times slower than C, it isn't fast from a user perspective. Full stop. It might, however, have a "fast interpreter". Remember, the user doesn't care if it is a fast for an interpreted language, they are just tr…

The 200-100 times slower is a bit cherry picked, but use case does matter. Typically from a user perspective, the initial starting time is either manageable or imperceptible in the cases of long running services, although there are other costs. If you look at examples that make the above claim, they are almost always tiny toy programs where the cost of producing byte/machine code isn't easily amortized. This quote fr…

I'm not so much cherry picking as I am specifically talking compute (not I/O,stdlib) performance. However, when measured for general purpose tasks, that would involve compute and things like I/O, stdlib performance, etc., Python on the whole is typically NOT 20-100x times slower for a given task. Its I/O layer is written in C like many other languages, so the moment you are waiting on I/O you have leveled the playing field. Likewise, Python has a very fast dict implementation in C, so when doing heavy map work, you also amortorize the time between the (brutally slow) compute and the very fast maps.

In summary, it depends. I am talking about compute performance, not I/O or general purpose task benchmarking. Yes, if you have a mix of compute and I/O (which admittedly is a typical use case), it isn't going to be 20-100x slower, but more likely "only" 3-20x slower. If it is nearly 100% I/O bound, it might not be any slower at all (or even faster if properly buffered). If you are doing number crunching (w/o a C lib like NumPy), your program will likely be 40-100x slower than doing it in C, and many of these aren't toy programs.

Re: Python performance myths and fairy tales

#112

Post by Demiurge »

jerf wrote: post #48
btown wrote: post #16

I think an important bit of context here is that computers are very, very good at speculative happy-path execution. The examples in the article seem gloomy: how could a JIT possibly do all the checks to make sure the arguments aren’t funky before adding them together, in a way that’s meaningfully better than just running the interpreter? But in practice, a JIT can create code that does these checks, and modern proces…

That makes it so that in absolute terms, Python is not as slow as you might naively expect. But we don't measure programming language performance in absolute terms. We measure them in relative terms, generally against C. And while your Python code is speculating about how this Python object will be unboxed, where its methods are, how to unbox its parameters, what methods will be called on those, etc., compiled code i…

I love this “real work”. Real work, like writing linked lists, array bounds checking, all the error handling for opening files, etc, etc? There is a reason Python and C both have a use case, and it’s obvious Python will never be as fast as C doing “1 + 1”. The real “real work” is in getting stuff done, not just making sure the least amount of cpu cycles are used to accomplish some web form generation.

Anyway, I think you’re totally right, in your general message. Python will never be the fastest language in all contexts. Still, there is a lot of room for optimization, and given it’s a popular language, it’s worth the effort.

Re: Python performance myths and fairy tales

#113

Post by tekknolagi »

ActivePattern wrote: post #84
pjmlp wrote: post #80

Earlier quoted context omitted.

In Smalltalk, p x * 2 has that flow that as well, and even worse, lets assume the value returned by p x message selector, does not understand the * message, thus it will break into the debugger, then the developer will add the * message to the object via the code browser, hit save, and exit the debugger with redo, thus ending the execution with success. Somehow Smalltalk JIT compilers handle it without major issues.

Smalltalk JITs make p x * 2 fast by speculating on types and inserting guards, not by skipping semantics. Python JITs do the same (e.g. PyPy), but Python’s dynamic features (like __getattribute__, unbounded ints, C-API hooks) make that harder and costlier to optimize away. You get real speed in Python by narrowing the semantics (e.g. via NumPy, Numba, or Cython) not by hoping the compiler outsmarts the language.

If I may toot my own horn: https://bernsteinbear.com/blog/typed-python/

Re: Python performance myths and fairy tales

#114

Post by ic_fly2 »

stackskipton wrote: post #71
ic_fly2 wrote: post #28

It’s a good article on speed. But honestly the thing that makes any of my programs slow is network calls. And there a nice async setup goes a long way. And then k8 for the scaling.

SRE here, that horizontal scaling with Python has impacts as it’s more connections to database and so forth so you are impacting things even if you don’t see it.

Meh, even with basic async I’ve been able to overload azure’s premium ampq offering memory capacity.

But yes managing db connections is a pain. But I don’t think it’s any better in Java (my only other reference at this scale)

Re: Python performance myths and fairy tales

#115

Post by Alex3917 »

Mithriil wrote: post #108

> His "sad truth" conclusion is that "Python cannot be super-fast" without breaking compatibility. A decent case of Python 4.0? > So, maybe, "a JIT compiler can solve all of your problems"; they can go a long way toward making Python, or any dynamic language, faster, Cuni said. But that leads to "a more subtle problem". He put up a slide with a trilemma triangle: a dynamic language, speed, or a simple implementation.…

> A decent case of Python 4.0?

I definitely agree with this eventually, but for now why not just let developers set `dynamic=False` on objects and make it opt in? This is how Google handles breaking Angular upgrades, and in practice it works great because people have multiple years to prepare for any breaking changes.

Re: Python performance myths and fairy tales

#116

Post by zahlman »

Mithriil wrote: post #108

> His "sad truth" conclusion is that "Python cannot be super-fast" without breaking compatibility. A decent case of Python 4.0? > So, maybe, "a JIT compiler can solve all of your problems"; they can go a long way toward making Python, or any dynamic language, faster, Cuni said. But that leads to "a more subtle problem". He put up a slide with a trilemma triangle: a dynamic language, speed, or a simple implementation.…

> A decent case of Python 4.0?

I think "Python 4.0" is going to have to be effectively a new language by a different team that simply happens to bear strong syntactic similarities. (And at least part of why that isn't already happening is that everyone keeps getting scared off by the scale of the task.)

Thanks for the reminder that I never got around to checking out Julia.

Re: Python performance myths and fairy tales

#117

Post by zahlman »

ActorNightly wrote: post #103
dgan wrote: post #32

"Rewrite the hot path in C/C++" is also a landmine because how inefficient the boundary crossing is. so you really need "dispatch as much as possible at once" instead of continuously calling the native code

>how inefficient the boundary crossing is For 99.99% of the programs that people write, the modern M.2 NVME hard drives are plenty fast, and thats the laziest way to load data into a C extension or process. Then there is unix pipes which are sufficiently fast. Then there is shared memory, which basically involves no loading. As with Python, all depends on the setup.

The problem isn't loading the data, but marshalling it (i.e, transforming it into a data structure that makes sense for the faster language to operate on, and back again). Or if you don't transform (or the data is special-cased enough that no transformation makes sense) then the available optimizations become much more limited.

Re: Python performance myths and fairy tales

#118

Post by Philpax »

richard_todd wrote: post #107
pu_pe wrote: post #85

Python and other high-level languages may actually decrease in popularity with better LLMs. If you are not the one programming it, might as well do it in a more performant language from the start.

In my workflows I already tend to tell LLMs to write scripts in Go instead of python. The LLM doesn't care about the increased tediousness and verbosity that would drive me to Python, and the result will be much faster.

I saw a short post to this effect here: https://solmaz.io/typed-languages-are-better-suited-for-vibe...

Re: Python performance myths and fairy tales

#119

Post by dragonwriter »

jerf wrote: post #48
btown wrote: post #16

I think an important bit of context here is that computers are very, very good at speculative happy-path execution. The examples in the article seem gloomy: how could a JIT possibly do all the checks to make sure the arguments aren’t funky before adding them together, in a way that’s meaningfully better than just running the interpreter? But in practice, a JIT can create code that does these checks, and modern proces…

That makes it so that in absolute terms, Python is not as slow as you might naively expect. But we don't measure programming language performance in absolute terms. We measure them in relative terms, generally against C. And while your Python code is speculating about how this Python object will be unboxed, where its methods are, how to unbox its parameters, what methods will be called on those, etc., compiled code i…

> After all, the interpreter is just C code too.

What interpreter? We’re talking about JITting Python to native code.

Re: Python performance myths and fairy tales

#120

Post by Philpax »

alankarmisra wrote: post #29
_aavaa_ wrote: post #25

Earlier quoted context omitted.

Mojo NOT being open-source is a complete non-starter.

Genuinely curious; while I understand why we would want a language to be open-source (there's plenty of good reasons), do you have anecdotes where the open-sourceness helped you solve a problem?

In the earlier days of rustc, it was handy to be able to look at the context for a specific compiler error (this is before the error reporting it is now known for). Using that, I was able to diagnose what was wrong with my code and adjust it accordingly.
Post reply on HN