Do you still need an add-on library to use more than one core?
Eh? Multiprocessing has existed since 2.X days.
Python performance myths and fairy tales
11–20 of 221 posts
Re: Python performance myths and fairy tales
#12I really hope PyPy gets more popular so that I don't have to argue Python is pretty fast for the nth time.
Even if you have to stick to CPython, Numba, Pythran etc, can give you amazing performance for minimal code changes.
Re: Python performance myths and fairy tales
#13Is it just me or does the talk actually confirm all its Python "myths and fairy tales"?
Re: Python performance myths and fairy tales
#14Good job on dispelling the myth of "compiler = fast". I hope SPython will be able to transfer some of its ideas to CPython with time.
You would think Luajit would have convinced people by now. But most people still think you need a static language and an AOT compiler for performance.
Re: Python performance myths and fairy tales
#15So 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?
Because computers are more than 100x faster than they were when I started programming, and they were already fast enough back then? (And meanwhile my coding ability isn't any better, if anything it's worse)
Re: Python performance myths and fairy tales
#16I 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 processors will branch-predict the happy path and effectively run it in parallel with the checks.
JavaScript, too, has complex prototype chains and common use of boxed objects - but v8 has made common use cases extremely fast. I’m excited for the future of Python.
Re: Python performance myths and fairy tales
#17I didn't read with 100% focus, but this lwn account of the talk seemed to confirm those myths instead of debunking.
Re: Python performance myths and fairy tales
#18So 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?
It's much more than 1%, it is what enables commonly used libraries like pytest and Pydantic.
Re: Python performance myths and fairy tales
#19Good job on dispelling the myth of "compiler = fast". I hope SPython will be able to transfer some of its ideas to CPython with time.
Where was this dispelled?
Re: Python performance myths and fairy tales
#20I didn't read with 100% focus, but this lwn account of the talk seemed to confirm those myths instead of debunking.
Yep, for me it confirms all the reasons why I think python is slow and not a good language for anything that goes beyond a script. I work with it everyday, and I have learned that I can't even trust tooling such as mypy because it's full of corner cases - turns out that not having a clear type design in a language is not something that can be fundamentally fixed by external tools. Tests are the only thing that can make me trust code written in this language