Python performance myths and fairy tales • Hacker News Board

Re: Python performance myths and fairy tales

#51

Post by Krssst » Wed, Aug 06, 2025, 1:17 PM UTC

quantumspandex wrote: post #7

So we are paying 99% of the performance just for the 1% of cases where it's nice to code in. Why do people think it's a good trade-off?

Performance is worthless if the code isn't correct. It's easier to write correct code reasonably quickly in Python in simple cases (integers don't overflow like in C, don't wrap around like in C#, no absurd implicit conversions like in other scripting languages).

Also you don't need code to be fast a lot of the time. If you just need some number crunching that is occasionally run by a human, taking a whole second is fine. Pretty good replacement for shell scripting too.

Re: Python performance myths and fairy tales

#52

Post by teo_zero » Wed, Aug 06, 2025, 1:26 PM UTC

I don't know Python so well as to propose any meaningful contribution, but it seems to me that most issues would be mitigated by a sort of "final" statement or qualifier, that prohibits any further changes to the underlying data structure, thus enabling all the nice optimizations, tricks and shortcuts that compilers and interpreters can't afford when data is allowed to change shape under their feet.

Re: Python performance myths and fairy tales

#53

Post by dgan » Wed, Aug 06, 2025, 1:26 PM UTC

aragilar wrote: post #42

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

Isn't this just a specific example of the general rule of pulling out repeated use of the same operation in a loop? I'm not sure calls out to C are specifically slow in CPython (given many operations are really just calling C underneath).

they are specifically slow. there was a project which measured FFI cost in different languages, and python is awfully bad

Re: Python performance myths and fairy tales

#54

Post by pjmlp » Wed, Aug 06, 2025, 1:33 PM UTC

aragilar wrote: post #50

pjmlp wrote: post #21

Basically, leave Python for OS and application scripting tasks, and as BASIC replacement for those learning to program.

And yet, most of what people end up doing ends up being effectively OS and application scripting. Most ML projects are really just setting up a pipeline and telling the computer to go and run it. Cloud deployments are "take this yaml and transform it some other yaml". In as much as I don't want to use Fortran to parse a yaml file, I don't really want to write an OS (or a database) in Python. Even something like djang…

I would rather use Fortran actually, not all of us are stuck with Fortran 77.

Ironically Fortran support is one of the reasons CUDA won over OpenCL.

Having said that, plenty of programming languages with JIT/AOT toolchains have nice YAML parsers, I don't see the need to bother with Python for that.

Re: Python performance myths and fairy tales

#55

Post by Ulti » Wed, Aug 06, 2025, 1:36 PM UTC

_aavaa_ wrote: post #25

Ulti wrote: post #24

Feel like Mojo is worth a shoutout in this context https://www.modular.com/mojo Solves the issue of having a superset of Python in syntax where "fn" instead of "def" functions are assumed static typed and compilable with Numba style optimisations.

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

More of a question of /will/ Mojo eventually be entirely open source, chunks of it already are. The intent from Modular is eventually it will be, just not everything all at once and not whilst they're internally doing loads of dev for their own commercial entity. Which seems fair enough to me. Importantly they have open sourced lots of the stdlib which is probably what anyone external would contribute to or want to change anyway? https://www.modular.com/blog/the-next-big-step-in-mojo-open-...

Re: Python performance myths and fairy tales

#56

Post by _aavaa_ » Wed, Aug 06, 2025, 1:38 PM UTC

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?

It has helped prevent problems. I am not worried about a python suddenly adding a clause stating that I can’t release a ML framework…

Re: Python performance myths and fairy tales

#57

Post by _aavaa_ » Wed, Aug 06, 2025, 1:39 PM UTC

Ulti wrote: post #55

_aavaa_ wrote: post #25

Earlier quoted context omitted.

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

More of a question of /will/ Mojo eventually be entirely open source, chunks of it already are. The intent from Modular is eventually it will be, just not everything all at once and not whilst they're internally doing loads of dev for their own commercial entity. Which seems fair enough to me. Importantly they have open sourced lots of the stdlib which is probably what anyone external would contribute to or want to c…

When it has become open source I will consider building up expertise and a product on it. Until it has happened there are no guarantees that it will.

Re: Python performance myths and fairy tales

#58

Post by andylei » Wed, Aug 06, 2025, 1:40 PM UTC

nu11ptr wrote: post #49

The primary focus here is good and something I hadn't considered: python memory being so dynamic leads to poor cache locality. Makes sense. I will leave that to others to dig into. That aside, I was expecting some level of a pedantic argument, and wasn't disappointed by this one: "A compiler for C/C++/Rust could turn that kind of expression into three operations: load the value of x, multiply it by two, and then stor…

The previous paragraph is

> Another "myth" is that Python is slow because it is interpreted; again, there is some truth to that, but interpretation is only a small part of what makes Python slow.

He concedes its slow, he's just saying it's not related to how interpreted it is.

Re: Python performance myths and fairy tales

#59

Post by Ulti » Wed, Aug 06, 2025, 1:43 PM UTC

_aavaa_ wrote: post #57

Ulti wrote: post #55

Earlier quoted context omitted.

More of a question of /will/ Mojo eventually be entirely open source, chunks of it already are. The intent from Modular is eventually it will be, just not everything all at once and not whilst they're internally doing loads of dev for their own commercial entity. Which seems fair enough to me. Importantly they have open sourced lots of the stdlib which is probably what anyone external would contribute to or want to c…

When it has become open source I will consider building up expertise and a product on it. Until it has happened there are no guarantees that it will.

Well the "expertise" is mostly just Python thats sort of the value prop. But yeah building an actual AI product ontop I'd be more worried about the early stage nature of Modular rather than the implementation is closed source.

Re: Python performance myths and fairy tales

#60

Post by _aavaa_ » Wed, Aug 06, 2025, 1:46 PM UTC

Ulti wrote: post #59

_aavaa_ wrote: post #57

Earlier quoted context omitted.

When it has become open source I will consider building up expertise and a product on it. Until it has happened there are no guarantees that it will.

Well the "expertise" is mostly just Python thats sort of the value prop. But yeah building an actual AI product ontop I'd be more worried about the early stage nature of Modular rather than the implementation is closed source.

Sure, that’s the value prop of numba too. But reality is different.