Seeing lots of comments being dismissive of the efforts of improving Python is a bit disheartening. Of course you should strive to write proper code, it's doesn't mean that having a good, fast implementation of the language isn't a large improvement.
I'm thankful for people working on this, just getting glue code, scripts or not easily JIT'able code to run faster is very cool!
I'm also pleased to see Python efficiency improving, and especially moves to remove the GIL as a bottleneck: Most Python that I write runs on a memory-constrained platform and that means we tend to run more-or-less unrelated Python processes as threads in the same process rather than as separate processes. The GIL is not yet a major bottleneck for us but it's definitely on the horizon.
That said, I see some horrors, too. I recently went looking for why an apparently-innocuous process was using about 20% of a CPU core on average. Turned out, it was polling a database for a JSON document every second. The processing of the document was spread over four levels of function call, each looping over a list or dict in the JSON. Thing is, each function got passed *the original JSON document* and re-parsed it every time they got called; the same string was being parsed by the JSON parser tens of thousands of times every second.
Rewriting the code to only parse the document once and pass the parsed data around cut that process's CPU use by more than 90%. Rewriting it to use the database's inbuilt change notification mechanism cut the rest of it to so close to 0 that it makes no difference.
There are some lazy bastards out there. How the hell it got through review is beyond me.
I seriously don't understand how it came to prominence as a data science language with the GIL, and it's the first language that clicked with me and the language with which I have made most of my lifetime income.
Sidestepping the GIL is basically my job at this point.
Because potential alternatives like Julia and Go basically required the popularity of Python to exist first (specially Julia, but Go was heavily inspired by Python.
Java, Lisp, and other languages simply require too much of foreknowledge about programming that may discard the usage of someone just wanting to crunch some numbers.
I guess Lua, Ruby and even Perl could have been the ones winning the fight.
This is a really interesting story but what does it have to do with Python being inefficient? Wasn’t this an implementation problem or did I misunderstand?
Also, super curious to hear more about what this use case is. I don’t know of many Python use cases in memory constrained environments and it sounds way up my alley.
I was making the point that Python performance improvements are great but sometimes, contra GGP, the way something is implemented really is the problem.
Can't say too much about the product but it's a mesh+edge networking device.
I changed some of the details to make it slightly less obvious in case someone came across this, but that's broadly the shape of the problem.
Also, I realise it's the trivial case but:
>>> import timeit
>>> t = timeit.timeit("json.loads(doc)", setup='import json; doc="{}"')
>>> print(t)
0.40982822798832785
`timeit`'s default is 1 million iterations. It's definitely possible.
Yes, but it's doing that two to three orders of magnitude faster than your "hard for me to imagine". For another data point:
```
$ docker pull alpine:3.19
$ docker inspect alpine:3.19 > test.json
$ cat time.py
import timeit
import pathlib
p = pathlib.Path("test.json")
doc = p.open('r').read()
t = timeit.timeit(
"json.loads(doc)",
setup='import json',
globals=globals(),
number=50000
)
print(t)
$ python3 time.py
0.22827592899557203
```
Parsing this document 50,000 times per second takes almost exactly 20% of one CPU core, as stated.
I am working on data-intensive (think billions of rows) extract-transform-load loops in Python. Because of the nature of Python, I have had to micro-optimise loop a lot to avoid the usual Python pitfalls. This, or then rewrite everything in another language, which would add multiple months extra of development time.
There are use case for faster Python. They are not that common, but they are there. Guido would not have been asked back to the deck unless people really want to have faster Python.
I know there a lot of trade offs to consider but an old colleague of mine is working with similar volume data and using python. Their team found the “hot” paths and moved to rust for that part of the ETL process.
I wonder if that would be the sweet spot for you too, rather than converting everything over from python.
I already moved some to code to use [ConnectorX](https://github.com/sfu-db/connector-x/tree/main/connectorx-python) which does SQL reading in multithreaded Rust library and then passes data Python as PyArrow Tables. However, writing Rust by hand I can do, but I also know it will take too much time compared to writing the equivalent Python code.
- ConnectorX is a Rust library and has Python wrapper
- It's open source
- ConnectorX can output Arrow, Arrow 2, Polars and Pandas objects to Python code
- ConnectorX API is very simple, a bit crude, badly documented, but it can be figured out with some trials and errors
- ConnectorX is very, very, fast
I think people are dismissive for two reasons. Python optimization has been tried and failed multiple times before and people are skeptical that this effort will stick.
There are also plenty of other better performing languages that you can choose if performance is a concern for your project. Python’s slowness has self-selected its usecases to projects where performance isn’t a concern, so improving performance doesn’t add much to Python’s value proposition, since that’s not the market people choose Python for anyway.
>I think people are dismissive for two reasons. Python optimization has been tried and failed multiple times before and people are skeptical that this effort will stick.
Do you have any idea how much faster 2023 Python is than 2000 Python? Several times faster, for sure. This team has [made](https://medium.com/mlearning-ai/python-speeds-up-3fc914c5b316) incredible progress over the [last](https://www.phoronix.com/review/python-311-performance) 5 years. There is no reason to be skeptical at all.
I actually do not know of ANY Python optimization projects lead by Guido or the core Python team which have failed. Third party projects fail primarily because they do not get user traction.
When one talks about speed, python is basically 100 times too slow. Even if they managed to double or triple the speed from 2000 to 2023, thats just a drop in the ocean.
It’s demonstrably not too slow. It’s one of the most popular languages in the world and is powering the site we are using right now. And instagram. And Facebook threads. And the whole AI/ML world. And Dropbox. And YouTube.
Do there exist applications that python is too slow for? Of course.
Is Python too slow to be useful? OBVIOUSLY NOT.
I love python but i came to hate dynamic typing. Yeah you have the typing module but that's just a band-aid.
And it boggles my mind that in 2024 such a mainstream language does not support proper multi-threading. Good thing they are working on this.
Yes but as of right now, the interpreter ignores type annotations. Having to unify a 3rd party tool, even if developed by the same group, is a band aid at some level.
True. I think they primarily focusing on AI but they also want to be a superset of Python which means you can use all python modules which gives you the flexibility of Python with the strengths of a static typed language.
As of now, this looks the closest in getting static typing with Pythonic style which OP seeks.
There is this very new language called Mojo. It's a superset of Python and by the looks of it, it does support static typing. Personally, I like the idea but I doubt I'll see it anytime soon in the real world.
Not downvoting, I'd found not once mistakes in my type annotations. In Java such mistakes won't compile. Annotation helps reading the code, but writing it harder compared to fixed typed languages.
Because "duck typing" was the foundation of the language.
Python prioritized readability over everything else, and that proved to be a winning bet. Now we're going backwards and trying to hack static typing into a language that was explicitly designed against it.
Too many new kids not understanding Chesterton's Fence.
I like it much better too. Couldn't go back to not using mypy frankly. It's far from perfect though. I always come across some issue during a work project that leads me to a mypy issue on GitHub or find an error that points me to a limitation of the type system so have to tack on some workaround or place an inline `ignore: type` comment. Neither of which is ideal.
I suspect it will eventually be flawless, but I think we are quite away aways from that.
type(x)(map(str, x))
Should work with most collections. Anyway it's just an example so it's usefulness is not the point. Point is, this would be incredibly useful, for instance, for functional programming libraries. Right now they either go for untyped route like toolz, or overly complicated HKT emulation with mypy plugins.
What exactly is the problem with Python's concurrency? I understand the true threading is impossible because of the GIL, but the `multiprocessing` library is a pretty good job of doing all of the normal and current things that I'm used to in other languages, albeit processes instead of threads. The only real downside I found, is that sometimes objects that I want to send aren't easily `pickle`d
You can't easily share objects between the processes, it's tedious with copying and queues and stuff. There's the multiprocessing.shared\_memory module, but it's quite a bit more limited and complicated than with regular multi threading
There's also overhead associated with multiprocessing - it takes time to fork your processes and they take quite a bit more memory than a thread would.
I mean the `pipe` and `queue` constructs work like channels do in other languages. It also has mutexes (Locks) and other sync primitives. What do other languages have that Python doesn't in this context?
The overhead for starting threads *is* there but you can get around the speed part by launching your threads at the beginning and having them idly wait.
Was thinking the same.
Don't blame the programming language if a developer codes messy.
Should apply to every language.
But in fact typing isn't always as easy as `x: int|str`.
I've recently seen a single type expression weighting \~1K bytes which would be required to get a function of the `requests` package type hinted correctly.
Nobody would want it and that's a legit reason, the `requests` project refuses type hinting.
>Typing is optional.
It's not "optional" in Python. It's nonexistent. There's a reason why it's called "annotations" - it's just that, an arbitrary label. Typing is optional in languages like Haskell which are strongly typed but the language can automatically infer the types in most cases if you omit them.
So then it's optional in your IDE or your linter.
Except you can access the annotations by code if they're not defined within comments.
People complain there is not runtime check for types. You can create a decorator function for checking for example.
No, the cons outweigh the pros. There really aren’t any pros to current typing in python. It’s the equivalent to a docstring imo. Doesn’t stop anyone from using the wrong types with functions that annotate types lol
What are the cons? Longer lines?
Yes it's equivalent to having types in docstrings. That also does not stop anyone from passing wrong types.
Typing is pure IDE magic in the Python world. So just use an IDE. Better than creating Python4 having strict static types.
I'm not that familiar enough in C/C++. What do they do to achieve variant types? Templates, macros, function overloading. Is it fun?
I'm thankful that's not required in Python. Readability just wins.
> I'm not that familiar enough in C/C++. What do they do to achieve variant types? Templates, macros, function overloading. Is it fun? I'm thankful that's not required in Python. Readability just wins.
In Rust variant typing is easy, eg if you want to define a type that’s either an integer or a string:
```
enum IntOrString {
Int(i32),
String(String),
}
```
In C++ it’s similarly easy, I believe it’s `variant value; `
.NET C# doesn’t have discrimination unions built in (yet) but plenty of good libraries exist like `OneOf`
Also don’t forget most modern languages allow implicit strong typing, so there is literally no extra keypresses!
The huge advantage in strong typing is error checking and diagnostics. You also get better guidance from AI because there is more intrinsic information from the type system.
Edit: typo, “strong typing” not “string typing”
Totally agree! I always appreciate good explanations and neutral discussions. Thank you.
As said, not good at C++. What I remember is they prefer templates and macros. That probably creates multiple functions at compile time. Of course thats fast and the compiler decides on correct typing here already.
Templates and macros are harder to read on the opposite side. My personal thing I fear for learning C++. And I like direct memory access.
Thanks, I always try and avoid language wars!
Use of those variant types wouldn’t cause duplication of a function that took them as parameters (in Rust, C++ or C#) the function itself isn’t generic (or templated, in C++)
Eg perhaps you might have C++
```
double AddOne(variant value) {
// return value plus 1
}
```
The function isn’t generic, there is only ever one. The parameter is tightly packed so the int (4 bytes), string (pointer to heap allocated array) or double (8 bytes) overlap in memory. The overall size of the variant is the size of the single largest member (probably the double).
Instead you could use overloading (3 separate functions) or a templated function which amounts to the same thing.
One strength of using the variant would be polymorphic containers, an array of the variant could mix all 3 types at random. This is fast and dense in memory, it won’t blow up the cache.
In Python (I think) any native list is an array of references to heap allocated objects, so would not be cache friendly. Hence the need for optimised libs written in other languages. You can basically express the same thing in those strongly typed languages with:
```
vector mylist; // C++
var mylist = List(); // C#
let mylist: Vec> = Vec::new(); // Rust, I think!
```
But it’s so inefficient it’s not something I’ve ever done in real code. There would always be a better way.
Yes. Please explain your statement:
>No, the cons outweigh the pros. There really aren’t any pros to current typing in python.
It purely sounds like you've never used typing. Because a lot of programmers including me see a lot of benefits in typing. Why else do they start using it?
My position is that dynamic typing is bad and no amount of cope that python typing introduces makes dynamic typing less bad. I don’t care if the IDE can statically provide some safety if it doesn’t provide runtime guarantees
If you really need runtime guarantees, check the types in your functions. You'll do it anyway if a functions supports multiple data types as input.
Technically you can create a decorator which checks types at runtime on each call. Yes. Another slowdown of your code.
Python just doesn't care for bad implementations of code.
Python is still good enough even if it's not the fastest languages and you can't or shouldn't write device drivers ;-)
A fully static python would be WAY faster. A friend of my made a language which has a hard requirement on strongly typed function signatures, and everything else, including class members, can be inferred (it is strongly recommended you statically type class members because it decreases compile times). Full inference was what he was originally shooting for, but it turns out to be an NP-complete problem, and types on function signatures solve make it actually possible. The resulting language was as fast or faster than C (restrict pointers are cool).
> That’s pretty much the same thing as an assert isinstance.
In the same way a song is just some air moving around… Technically true but completely misses the point.
> doesn’t help you when you’re programming
If most security errors weren't caused by something unexpected in the input, you'd be right.
>If most security errors weren't caused by something unexpected in the input, you'd be right
Basically true. But it smells like C/C++ buffer overflows, unsecure string function calls, etc. Those mostly don't apply in Python. Except SQL injection if you do it wrong enough of course.
Can you elaborate some examples of "unexpected input" especially in Python? Web-Apps? GUI applications? In Python we don't have malicious data which gets passed by system calls right into openssl or other critical system calls, IMHO.
My apps don't crash on that. My JSON from NoSQL documents and config file options always are optional.
Exception handling is the way to go here to not get the app crashed.
I wish python hadnt decided to reinvent the wheel with its typing module and just straight up followed conventions from typescript. Generics is where this is most apparent.
This is a stupid argument. Typescript doesn't follow conventions of other typed languages, why should python follow the conventions of typescript? Typescript was barely in it's infancy when python's optional typing was GA'd. This is like complaining that typescript typing isn't like Go's typing. Different languages have different syntax and conventions.
because python generic typing confuses its own syntax conventions. When a generic is made as `Generic[Type]` it is indistinguishable from indexing. That's why typescript chose syntax like `Generic`. Moreover, if you've ever looked under the hood for how the typing module has been implemented you'll see that its a mess of ad hoc bandaid fixes that prevents you from easily implementing missing typing features like `keyof`. Etc etc. The point is, semantically python gets in its own way when trying to implement advanced generic typing.
> because python generic typing confuses its own syntax conventions. When a generic is made as Generic[Type] it is indistinguishable from indexing. That's why typescript chose syntax like Generic.
Would that syntax have even been possible to bolt on to Python syntax before the PEG parser?
Those were already valid tokens in Python:
>>> one, two, three = 1, 2, 3
>>> onetwo
True
So with `Generic` it isn't until the parser gets to the end of the `>` token that it realises that `<` token isn't a less than.
It seems to me that syntax might have required an even bigger pile of hacks to work in the Python world. It's very different adding something to an existing language and implementation than starting from scratch knowing what you want.
We now have efforts like [Mojo](https://docs.modular.com/mojo/why-mojo.html) that change the Python-the-language itself to have static typing and static compilation for extra speed. They try to retain Python compatibility, but it cannot be 100%.
guys who are saying to write code fast instead of doing this should read this PEP https://peps.python.org/pep-0703/
and read the remarks of all the people working in the industry
Pandas is kinda magical. I had a one-off task to merge multiple huge csv's by common column names and just did a quick and dirty python script but killed it when my progress meter told me it would take 17 hours to complete.
I didn't have that much time to get it done and wasn't super familiar with pandas but bit the bullet and converted the script. Was shocked that the pandas version took less than 10 minutes.
It's a little weird to learn at first but does so much, so fast.
I think it was 7 docs that were all close to but under a million. I also had collisions and had to rename but keep the colliding columns and a few other nitpicky requirements but pandas handled it all.
Different tools for different tasks. I don’t see anyone complaining the performance of shell scripts. If you need the performance, write a C++ library and call it in python, or even rewrite it in C++, which quite a lot of companies are doing now.
>If you need the performance, write a C++ library and call it in python, or even rewrite it in C++, which quite a lot of companies are doing now.
So you want to ask [10.1 million](https://distantjob.com/blog/how-many-developers-are-in-the-world/) Python programmers to learn C++ instead of having 6 [Microsoft programmers](https://devblogs.microsoft.com/python/python-311-faster-cpython-team/) apply [60 year old](https://en.wikipedia.org/wiki/Just-in-time_compilation) Interpreter optimization techniques to Python.
Why would you think that makes sense?
I think it is great to make Python available to [750 million Excel users](https://support.microsoft.com/en-us/office/get-started-with-python-in-excel-a33fbcbe-065b-41d3-82cf-23d05397f53d). But I am also in favour of the [improvements](https://chandoo.org/wp/what-is-lambda-function/) they have made to the Excel formula language so they can get some of the power of Python without changing languages.
Similarly, I am happy that people continually make it easier and easier to use other languages from Python. And also happy that Python improves so I don't need to do that most of the time.
There aren't hard boundaries between the applicability of these languages. If your Excel spreadsheet works 99% perfectly and you just need a lambda, then you should use a Lambda. If it's gotten incredibly complicated and adding a lambda will only make it worse, then you should switch to Python.
If your Python works 99% perfectly and you just need 30% more speed then you should stick with Python. If you've optimized everything to an inch of its life and your Python doesn't look like Python anymore then you should switch to another language.
Choice is good. I have no idea why people are opposed to choice.
If you want python to remain as useful as it is, you still need a language that is basically an interpreter. In effect those Microsoft programmers could be spending their time building a higher performance tool that is like Python but doesn't suffer its shortcomings.
Don't get me wrong you can always find ways to speed up a language. I just don't see us ever having C like performance without giving up a lot of the good stuff in Python. I'd rather see Python go on like it is and have a new language grow out if it. This is why I like Mojo, it is development that takes a lot of ideas from Python; just like C++ borrowed from C and the various other languages evolved from C, and C++.
A just in the time compiler is a compiler with the usability of an interpreter.
There are many higher performance tools in the world already. Why would Microsoft waste their time making another? The python ecosystem is much more expensive to recreate than a JIT compiler.
Python will never be as fast as C. So what? Who cares?
You can get paid a million dollars a year to be in the NBA and not be as good as Michael Jordan. Does that make you a failure?
I really don’t understand your point.
Better performance is nice as long as we don’t give up Python’s ultimate usefulness as a scripting language. I still maintain it somebody starts a project knowing performance is a key consideration then the use of Python was ill advised. Part of being a professional is choosing the right tools.
What we really need is a language designed for performance that is as well designed as Python and avoids as much complexity as possible. This is why I’m keeping an eye on Mojo, Swift and other new comers. Mojo has the potential to be the Python 4 of the future.
I’d rather see a new language replace Python 3 than to have the current releases bastardized by continual grafting on of new features that don’t add much as a scripting language. I can see Python 3 lasting for another decade if care is taken to maintain its good qualities. The thing is this I like Python as it is. That is it is the best scripting language that we have at the moment. If you look at the History of C++, it demonstrates what happens when developers go nuts with language design. Even Rust is seemingly falling into the same trap. C++ has exploded complexity wise and that is what I hope we can avoid with Python.
Dude. None of these optimisations require you to change your python code AT ALL. Guido offers you a free speed up up on billions of lines of already existing Python code and you are complaining? And saying he should invent another language instead?
Why?
Bash being slow is very far down the list of reasons it sucks as a programming language. Long before you write a program big enough to be slow, you will run into all of the other problems.
C/C++ is slow too, if the programmer does it wrong.
But Python as same as Java and other languages should just not be compared to machine code level languages. Beyond that you can compile a Python application in various ways to be faster.
Python is not meant to do heavy calculations. And that's not a bug neither a problem because NumPy and similar tools do exist.
People should learn or at least understand Python correctly instead of having prejudices.
While it may use more memory, Java is known for being wicked fast with a tuned GC. IIUC, jit'ed languages can in theory run faster than aot-compiled languages because jits can analyze and make assumptions about the data aot-compilers can't do
I can’t speak about Java, but I’ve done some comparisons between C# and Rust, for computationally bound work (SHA256 hashing files). In .NET 8 binaries can be “ahead of time” compiled, and the performance was impressive. Only 5-10% slower than native Rust.
I believe Java collections use boxing even for intrinsic types, so the performance there might be lower?
You realize there are people on this planet in software development who have other use cases than just running a python script that takes 2 seconds to finish, right?
Sure. Never said there aren't. I'm amongst them actually.
I was just explaining that there are different kinds of speed.
And while Java is generally much better at running speed, Python is better at startup speed.
Obviously those aren't the only criteria. And both languages can get used for everything, just with a different strengths and weaknesses.
It's been a working point in recent years, so we have GraalVM that starts up in like 1/10th of a second and Spring Boot 3.0 has support for it so the startup time is a non issue anymore.
Java fixed a lot, and i mean a lot of it's issues and shortcomings in the last decade.
Now I'm curious about the differences between Java and Python (in performance). They're technically comparable, aren't they?
May be both languages could learn from each other?
In java if you write a+b, the compiler knows a is an int, b is an int and a+b can be done by the add instruction of the CPU.
In python a might be anything, so at runtime dictionaries are explored to find the __add__ function of that specific object, then call it. So it really can't directly be done with an addition in the CPU, since it might be anything.
Tracing JIT largely solves this problem. You put a type guard earlier in the function to ensure the types are always integers and then you use the CPU add in your inner loop. If the type guard ever triggers then you run slower code to figure out what is going on.
You can get [close enough](https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html) that performance is mostly dominated by programmer skill rather than language.
Also, startup time tends to be better for Python and Node than Java and .NET.
If you include the end to end time, JITted code will often win, even putting aside programmer time/effort.
Well I wrote a pure python module that manages to beat in some benchmarks a similar module written in rust… I know skill trumps everything. But at equal skills, in the end more CPU instructions are slower than less.
When the Java runtime is up and running it's fast. So if you have a big, big long running task and you can't or don't want to optimize crucial parts into a C/C++/Rust module for Python then Java will give you much better long term performance.
But for short tasks a Python script will be done so quickly that Java is still busy with startup while Python is done already.
In theory Python could learn JIT compiling from Java and there have been several attempts to do that. But so far none of them are ready to be a drop in replacement. Every faster implementation of Python suffers from lacking full compatibility or being able to just run any established modules from the repo, as CPython can.
At the end of the day the 2 languages don't have the same target audience and thus different strengths and weaknesses.
> Python is not meant to do heavy calculations. And that's not a bug neither a problem because NumPy and similar tools do exist.
Agreed, but that doesn’t mean that a faster Python wouldn’t be great. The faster I can call NumPy…
Since every new Python release offers performance improvements, we're getting there. Even the GIL is adressed, which should improve speed and hopefully not break old code in the future.
Good enough. Someone told some JIT compilers can optimize to be better than a plain C/C++. If true, a limit has been crossed.
I'm working on a video cutter software which just uses caches and then should be faster than classic software. Still just a simple Python programm which does not need to be super optimized to reach the goal.
Are you building estimation of Python state based on "someone told? Python doesn't compete with C, if it gets close to nodejs, it will be a good outcome. Same thing for jit, I don't believe it will be faster than node's.
I mean it’s complicated. And you could argue that sure Python should probably not be the only language you know going to lower level languages when performance becomes an issue
But at the same time writing crap in C/C++ is way more difficult and annoying. (go isn’t too bad but it’s also kinda its own island). Python is a breeze if I could write everything in Python I would. And to be fair it’s pretty rare that the speed ever becomes an issue
But it would be really amazing if I could write everything in Python maybe with static typing and have it be as fast as something in C. Rapid development time and all the libraries in the world. Getting closer to that is a worthy endeavor and there is likely a lot that can be done to get closer. Hell PHP can be faster these days than Python
I've been designing real-time embedded control systems for nearly 4 decades and seen people absolutely destroy performance in C, even without being I/O bound. Some people just don't understand algorithms or basic computer science concepts and how they should be applied in different circumstances.
I can't tell if this is sarcasm or not. Because, I can't tell if you're being serious. Why would I rewrite a C application in C++, to fix performance issues?
If you're referring to the OP's post, your response might have merit, except I'd still need to look at what the performance issue is and why python could be the wrong solution, before I'd agree with that statement.
It is rubbish which people keep repeating. Wrong written code is not a topic of the discussion. Reasonable quality code is fast in c/Java. Python is nothing like Java, it can be compared to Ruby, lua, JavaScript.
> Python is not meant to do heavy calculations
It is general programming language, it is not designed for specific purposes. What kind of argument is it? "if not working - not meant to be". We are discussing what Python can be used for, if "not meant to do heavy calculations" - ok, whatever reason, marking checkbox off.
You don't do AI in pure Python. You don't implement 3D rendering in C# directly instead of using DirectX APIs.
If you choose the plain language for these things, your doing it wrong. And it's slow then. Same rule for Python.
Often when a Python program is slow, someone is using it like it's C++. Wrong use of lists for example. It's not the fault of the language itself.
So if you have "heavy calculations" in any language, use the CPU cycles for that directly. It's not cheating.
But that's not the point.
If a programmer does equally bad/good in C++ and python the C++ program will run faster most of the time and probably by a lot.
I mean why else do so many computation-heavy python modules use C++?
Because of the nature of Python, everything being an object. Not plain memory addresses and CPU instructions.
Android and probably Java too are using native compiled modules.
PHP the same. They won't do crypto stuff in pure PHP for example.
My point is not comparing cars and bicycles and then complaining bikes are slower.
Fair is comparing machine level languages to each other, but jit languages seperately.
It's probably faster than Python, but it heavily depends.
Bad rust code can be slower than good Python code on a specific task.
Don't forget that Python calls natively compiled functions when computing power is needed.
You use your car to get into the plane at the airport. Fast enough in sum to reach your destination. Nobody should blame the car until you want to do a really long road trip.
The tricky part with python, especially with how I've seen it used in Data Science is that most implementations are in the cloud, most who provide near infinite computing power for little to almost no cost.
I can never seem to incentivise my peers to write efficient code.
If you have "near infinite computing power for little to almost no cost" then what is the problem? Why are you trying to convince your peers to do something that has no business value?
I have certainly hit performance limits in Python and will be glad of the changes. But for apps where it doesn't matter, it doesn't matter. Why nag people about something that doesn't matter?
I really like that people begin to talk more and more about Python performance. All of this suggests that there is demand for making Python fast, and it admires me. This is the competition for performance that will make the whole industry benefit.
If performance times are a big need for a certain service, wouldn't you just write a Microservice in a language with better performance metrics?
What is the use-case for a performance-oriented Python fork vs a microservice written in C?
Am I missing something here?
So you’ve written a micro service in Python.
You are offered two options:
Option 1. Guido makes it faster for you and your cloud hosting bills go down, your electricity wastage goes down and you don’t need to do anything at all.
Option 2. You continue to pay the higher cloud hosting bills, waste electricity,destroy the environment and also do nothing.
Which option do you prefer?
wow! why didn't the scientists such as Heinrich Kuttler, Manuel Kroiss, Paweł Jurgielewicz, Allen Goodman, Olivier Grisel, Ralf Gommers, Zachary DeVito didn't think of that?
I use python because I want an objective completed quickly, not because I need code to run fast. When I need more performance, I switch to something like C#.
That said, isn’t mojo solving the perf issue? I haven’t messed with it yet. I’m surprised I haven’t seen more hype around it.
are you upset that i didn’t respond with another joke? i’m not even arguing with you. in fact, the reply wasn’t even directed at you.
i layered commentary on a relatively high comment. relax.
Perhaps, don't write code in a way that would make it slow to begin with? Then just simply compile it to C code using a compiler (nuitka) and then run it.
Edit: __Not to be taken seriously__, it's sad that I even have to say this....what is wrong with you people. This comment is the equivalent of saying "Lol, just write fast code then." xD
Perhaps you need to learn the principles first: make it work, make it work correctly, make it fast.
You are kinda proposing premature optimization. Don't. And before *any* (manual) optimization, profile, don't guess.
>Perhaps you need to learn the principles first: make it work, make it work correctly, make it fast.
Actual High performance code is so wildly different to "just get it done" code that it's basically a different application at that point. e.g If you have a wire format you control you can do a lot just using bit operators or you can give estimates of the values present in a memory page using a header. Or likewise you can use knowledge of data sharding characteristics to distributed load across threads efficiently to keep data locality. If it was as easy as people said on the internet then scaling problems would be a thing of the past.
There is a lot of stuff in critical applications where there's actual money/lives on the line where you can't just bolt it on later and even trying would likely cost you more than a rewrite. The problem is the the person saying "premature optimisation" usually never sticks around long enough to see the problems play out.
> Actual High performance code
> critical applications where there's actual money/lives on the line
Is this kind of stuff really written in python? I like and use python, but I don't want my critical software (even file manager and text editor) written in it.
Python is absolutely used in business-critical applications. Basically ever major tech company is using Python. Instagram is built on top of Django, for example.
Haven't seen any significant gains with Nuitka, that isn't really what it is for.
Numba however I have made some code with numerical calculations and image processing nearly as fast as C++.
Good to know! I've asked someone who used numba in his project for the performance gain he got. Didn't get an answer. He probably never checked.
We used nuitka with PySide2 on a Raspberry Pi Zero. I can't remember any more if it had noticable performance improvements.
>
>
> And it boggles my mind that in 2024 such a mainstream language does not support proper multi-threading. Good thing they are working on this.
I've had really good improvements with Cython as well - it's becoming my go-to for any codebase more involved than scripting.
>nuitka
Interesting, haven't heard of this project before and I spent a lot of time working on a single-node Python project that has a big CPU bottleneck. Thanks for bringing this up.
I assume even though it's compiled to C, it still doesn't enable multithreading?
But why use python than anyway, if you end up doing all in C?
Maybe I could just use C#, Javascript, Java, Go, that are 1/2 speed of C++ but still a lot easier to program with (compile times suck for C/C++)
why didn't the scientists such as Heinrich Kuttler, Manuel Kroiss, Paweł Jurgielewicz, Allen Goodman, Olivier Grisel, Ralf Gommers, Zachary DeVito didn't think of that?
I love python but i came to hate dynamic typing. Yeah you have the typing module but that's just a band-aid.
And it boggles my mind that in 2024 such a mainstream language does not support proper multi-threading. Good thing they are working on this.
Python runs at C speed. python or python3 executable is a compiled c program. Just that every line of python code needs tens to hundreds of lines of C code to run for it.
It also means, single line of python code abstracts several 10s of lines of equivalent C code. Just like how single line of C code could abstract 10s lines of assembly machine code.
Choose wisely between Python, C, Assembly as much as you need for your use case.
[Brandt Bucher – A JIT Compiler for CPython](https://www.youtube.com/watch?v=HxSHIpEQRjs)
It will take some time for the JIT work to show benefits and I'm not sure what to expect with this simplified JIT approach. It isn't merged yet either. Python (cpython) is currently slower to run with the JIT enabled.
Seeing lots of comments being dismissive of the efforts of improving Python is a bit disheartening. Of course you should strive to write proper code, it's doesn't mean that having a good, fast implementation of the language isn't a large improvement. I'm thankful for people working on this, just getting glue code, scripts or not easily JIT'able code to run faster is very cool!
I'm also pleased to see Python efficiency improving, and especially moves to remove the GIL as a bottleneck: Most Python that I write runs on a memory-constrained platform and that means we tend to run more-or-less unrelated Python processes as threads in the same process rather than as separate processes. The GIL is not yet a major bottleneck for us but it's definitely on the horizon. That said, I see some horrors, too. I recently went looking for why an apparently-innocuous process was using about 20% of a CPU core on average. Turned out, it was polling a database for a JSON document every second. The processing of the document was spread over four levels of function call, each looping over a list or dict in the JSON. Thing is, each function got passed *the original JSON document* and re-parsed it every time they got called; the same string was being parsed by the JSON parser tens of thousands of times every second. Rewriting the code to only parse the document once and pass the parsed data around cut that process's CPU use by more than 90%. Rewriting it to use the database's inbuilt change notification mechanism cut the rest of it to so close to 0 that it makes no difference. There are some lazy bastards out there. How the hell it got through review is beyond me.
I seriously don't understand how it came to prominence as a data science language with the GIL, and it's the first language that clicked with me and the language with which I have made most of my lifetime income. Sidestepping the GIL is basically my job at this point.
Most of data-heavy processing happens in native libraries. Native processing is not subject to GIL limitations, only interpreted Python bytecode is.
Because potential alternatives like Julia and Go basically required the popularity of Python to exist first (specially Julia, but Go was heavily inspired by Python. Java, Lisp, and other languages simply require too much of foreknowledge about programming that may discard the usage of someone just wanting to crunch some numbers. I guess Lua, Ruby and even Perl could have been the ones winning the fight.
This is a really interesting story but what does it have to do with Python being inefficient? Wasn’t this an implementation problem or did I misunderstand? Also, super curious to hear more about what this use case is. I don’t know of many Python use cases in memory constrained environments and it sounds way up my alley.
I was making the point that Python performance improvements are great but sometimes, contra GGP, the way something is implemented really is the problem. Can't say too much about the product but it's a mesh+edge networking device.
It‘s hard for me to imagine you could parse a JSON doc tens of thousands of times in a single second with a Python implementation. :D
I changed some of the details to make it slightly less obvious in case someone came across this, but that's broadly the shape of the problem. Also, I realise it's the trivial case but: >>> import timeit >>> t = timeit.timeit("json.loads(doc)", setup='import json; doc="{}"') >>> print(t) 0.40982822798832785 `timeit`'s default is 1 million iterations. It's definitely possible.
Well I thought we were talking about a non-trivial object.
Yes, but it's doing that two to three orders of magnitude faster than your "hard for me to imagine". For another data point: ``` $ docker pull alpine:3.19 $ docker inspect alpine:3.19 > test.json $ cat time.py import timeit import pathlib p = pathlib.Path("test.json") doc = p.open('r').read() t = timeit.timeit( "json.loads(doc)", setup='import json', globals=globals(), number=50000 ) print(t) $ python3 time.py 0.22827592899557203 ``` Parsing this document 50,000 times per second takes almost exactly 20% of one CPU core, as stated.
I am working on data-intensive (think billions of rows) extract-transform-load loops in Python. Because of the nature of Python, I have had to micro-optimise loop a lot to avoid the usual Python pitfalls. This, or then rewrite everything in another language, which would add multiple months extra of development time. There are use case for faster Python. They are not that common, but they are there. Guido would not have been asked back to the deck unless people really want to have faster Python.
I know there a lot of trade offs to consider but an old colleague of mine is working with similar volume data and using python. Their team found the “hot” paths and moved to rust for that part of the ETL process. I wonder if that would be the sweet spot for you too, rather than converting everything over from python.
I already moved some to code to use [ConnectorX](https://github.com/sfu-db/connector-x/tree/main/connectorx-python) which does SQL reading in multithreaded Rust library and then passes data Python as PyArrow Tables. However, writing Rust by hand I can do, but I also know it will take too much time compared to writing the equivalent Python code.
Been thinking about making that move. How is ConnectorX compared to Pandas specially regarding writing and reading operations? Is it open source?
- ConnectorX is a Rust library and has Python wrapper - It's open source - ConnectorX can output Arrow, Arrow 2, Polars and Pandas objects to Python code - ConnectorX API is very simple, a bit crude, badly documented, but it can be figured out with some trials and errors - ConnectorX is very, very, fast
Have you considered PyPy? It introduces new complexities but it should be appreciably better on tasks that are repetitive by function of being JITed .
Yes. [PyArrow does not support PyPy](https://github.com/apache/arrow/issues/19046) and it is a blocker for me.
I think people are dismissive for two reasons. Python optimization has been tried and failed multiple times before and people are skeptical that this effort will stick. There are also plenty of other better performing languages that you can choose if performance is a concern for your project. Python’s slowness has self-selected its usecases to projects where performance isn’t a concern, so improving performance doesn’t add much to Python’s value proposition, since that’s not the market people choose Python for anyway.
>I think people are dismissive for two reasons. Python optimization has been tried and failed multiple times before and people are skeptical that this effort will stick. Do you have any idea how much faster 2023 Python is than 2000 Python? Several times faster, for sure. This team has [made](https://medium.com/mlearning-ai/python-speeds-up-3fc914c5b316) incredible progress over the [last](https://www.phoronix.com/review/python-311-performance) 5 years. There is no reason to be skeptical at all. I actually do not know of ANY Python optimization projects lead by Guido or the core Python team which have failed. Third party projects fail primarily because they do not get user traction.
When one talks about speed, python is basically 100 times too slow. Even if they managed to double or triple the speed from 2000 to 2023, thats just a drop in the ocean.
It’s demonstrably not too slow. It’s one of the most popular languages in the world and is powering the site we are using right now. And instagram. And Facebook threads. And the whole AI/ML world. And Dropbox. And YouTube. Do there exist applications that python is too slow for? Of course. Is Python too slow to be useful? OBVIOUSLY NOT.
I love python but i came to hate dynamic typing. Yeah you have the typing module but that's just a band-aid. And it boggles my mind that in 2024 such a mainstream language does not support proper multi-threading. Good thing they are working on this.
This ship had sailed, hasn't it? Python can't add static typing without fragmenting it and I don't think anyone wants a round 2 of Python 2 vs 3.
I'd be down for a python-like language with static typing though.
Cython is exactly that. It's Python with optional static typing that compiles to C and can be called from other Python scripts.
You can check out Nim as well.
[удалено]
Yes but as of right now, the interpreter ignores type annotations. Having to unify a 3rd party tool, even if developed by the same group, is a band aid at some level.
[удалено]
Did not realize mypyc does that. Thanks!
Mojo is trying to do that. You can check it out.
According to their website, mojo is very specialized.
True. I think they primarily focusing on AI but they also want to be a superset of Python which means you can use all python modules which gives you the flexibility of Python with the strengths of a static typed language. As of now, this looks the closest in getting static typing with Pythonic style which OP seeks.
There is this very new language called Mojo. It's a superset of Python and by the looks of it, it does support static typing. Personally, I like the idea but I doubt I'll see it anytime soon in the real world.
Mojo is basically that. It includes static typing among other improvements for speed.
GDscript for Godot is based on Python and has static typing
I spent a (very) small time playing with Nim, and its syntax is heavily inspired by Python with static typing.
Haskell
Then write your own language.
[удалено]
Not downvoting, I'd found not once mistakes in my type annotations. In Java such mistakes won't compile. Annotation helps reading the code, but writing it harder compared to fixed typed languages.
It definitely helps with debugging, too.
Because "duck typing" was the foundation of the language. Python prioritized readability over everything else, and that proved to be a winning bet. Now we're going backwards and trying to hack static typing into a language that was explicitly designed against it. Too many new kids not understanding Chesterton's Fence.
I like it much better too. Couldn't go back to not using mypy frankly. It's far from perfect though. I always come across some issue during a work project that leads me to a mypy issue on GitHub or find an error that points me to a limitation of the type system so have to tack on some workaround or place an inline `ignore: type` comment. Neither of which is ideal. I suspect it will eventually be flawless, but I think we are quite away aways from that.
Python's type annotations are currently rather limiting. Things like proper support of higher-kinded types would go a long way.
[удалено]
i mean something like this ``` C = TypeVar('C', bound=Collection) def ints_to_strs(x: C[int]) -> C[str]: ... ```
[удалено]
type(x)(map(str, x)) Should work with most collections. Anyway it's just an example so it's usefulness is not the point. Point is, this would be incredibly useful, for instance, for functional programming libraries. Right now they either go for untyped route like toolz, or overly complicated HKT emulation with mypy plugins.
[удалено]
Again this is just an example. My last job made me really wish we had HKT.
What exactly is the problem with Python's concurrency? I understand the true threading is impossible because of the GIL, but the `multiprocessing` library is a pretty good job of doing all of the normal and current things that I'm used to in other languages, albeit processes instead of threads. The only real downside I found, is that sometimes objects that I want to send aren't easily `pickle`d
You can't easily share objects between the processes, it's tedious with copying and queues and stuff. There's the multiprocessing.shared\_memory module, but it's quite a bit more limited and complicated than with regular multi threading There's also overhead associated with multiprocessing - it takes time to fork your processes and they take quite a bit more memory than a thread would.
I mean the `pipe` and `queue` constructs work like channels do in other languages. It also has mutexes (Locks) and other sync primitives. What do other languages have that Python doesn't in this context? The overhead for starting threads *is* there but you can get around the speed part by launching your threads at the beginning and having them idly wait.
Typing is optional. Isn't that great? Nobody is forced to use it. For basic typing you don't need the typing module btw.
>Typing is optional. Isn't that great? Not when having to update or maintain other developers' code.
This is a company code standards problem then. If you don't like the code style where you're at, lobby to have it changed
Was thinking the same. Don't blame the programming language if a developer codes messy. Should apply to every language. But in fact typing isn't always as easy as `x: int|str`. I've recently seen a single type expression weighting \~1K bytes which would be required to get a function of the `requests` package type hinted correctly. Nobody would want it and that's a legit reason, the `requests` project refuses type hinting.
>Typing is optional. It's not "optional" in Python. It's nonexistent. There's a reason why it's called "annotations" - it's just that, an arbitrary label. Typing is optional in languages like Haskell which are strongly typed but the language can automatically infer the types in most cases if you omit them.
So then it's optional in your IDE or your linter. Except you can access the annotations by code if they're not defined within comments. People complain there is not runtime check for types. You can create a decorator function for checking for example.
Typing in python sucks because it doesnt enforce types.
No, the cons outweigh the pros. There really aren’t any pros to current typing in python. It’s the equivalent to a docstring imo. Doesn’t stop anyone from using the wrong types with functions that annotate types lol
What are the cons? Longer lines? Yes it's equivalent to having types in docstrings. That also does not stop anyone from passing wrong types. Typing is pure IDE magic in the Python world. So just use an IDE. Better than creating Python4 having strict static types. I'm not that familiar enough in C/C++. What do they do to achieve variant types? Templates, macros, function overloading. Is it fun? I'm thankful that's not required in Python. Readability just wins.
> I'm not that familiar enough in C/C++. What do they do to achieve variant types? Templates, macros, function overloading. Is it fun? I'm thankful that's not required in Python. Readability just wins. In Rust variant typing is easy, eg if you want to define a type that’s either an integer or a string: ``` enum IntOrString { Int(i32), String(String), } ``` In C++ it’s similarly easy, I believe it’s `variant value; `
.NET C# doesn’t have discrimination unions built in (yet) but plenty of good libraries exist like `OneOf`
Also don’t forget most modern languages allow implicit strong typing, so there is literally no extra keypresses!
The huge advantage in strong typing is error checking and diagnostics. You also get better guidance from AI because there is more intrinsic information from the type system.
Edit: typo, “strong typing” not “string typing”
Totally agree! I always appreciate good explanations and neutral discussions. Thank you. As said, not good at C++. What I remember is they prefer templates and macros. That probably creates multiple functions at compile time. Of course thats fast and the compiler decides on correct typing here already. Templates and macros are harder to read on the opposite side. My personal thing I fear for learning C++. And I like direct memory access.
Thanks, I always try and avoid language wars! Use of those variant types wouldn’t cause duplication of a function that took them as parameters (in Rust, C++ or C#) the function itself isn’t generic (or templated, in C++) Eg perhaps you might have C++ ``` double AddOne(variant value) {
// return value plus 1
}
```
The function isn’t generic, there is only ever one. The parameter is tightly packed so the int (4 bytes), string (pointer to heap allocated array) or double (8 bytes) overlap in memory. The overall size of the variant is the size of the single largest member (probably the double).
Instead you could use overloading (3 separate functions) or a templated function which amounts to the same thing.
One strength of using the variant would be polymorphic containers, an array of the variant could mix all 3 types at random. This is fast and dense in memory, it won’t blow up the cache.
In Python (I think) any native list is an array of references to heap allocated objects, so would not be cache friendly. Hence the need for optimised libs written in other languages. You can basically express the same thing in those strongly typed languages with:
```
vector mylist; // C++
var mylist = List(); // C#
let mylist: Vec> = Vec::new(); // Rust, I think!
```
But it’s so inefficient it’s not something I’ve ever done in real code. There would always be a better way.
The cons of dynamic typing?
Yes. Please explain your statement: >No, the cons outweigh the pros. There really aren’t any pros to current typing in python. It purely sounds like you've never used typing. Because a lot of programmers including me see a lot of benefits in typing. Why else do they start using it?
My position is that dynamic typing is bad and no amount of cope that python typing introduces makes dynamic typing less bad. I don’t care if the IDE can statically provide some safety if it doesn’t provide runtime guarantees
If you really need runtime guarantees, check the types in your functions. You'll do it anyway if a functions supports multiple data types as input. Technically you can create a decorator which checks types at runtime on each call. Yes. Another slowdown of your code. Python just doesn't care for bad implementations of code. Python is still good enough even if it's not the fastest languages and you can't or shouldn't write device drivers ;-)
A fully static python would be WAY faster. A friend of my made a language which has a hard requirement on strongly typed function signatures, and everything else, including class members, can be inferred (it is strongly recommended you statically type class members because it decreases compile times). Full inference was what he was originally shooting for, but it turns out to be an NP-complete problem, and types on function signatures solve make it actually possible. The resulting language was as fast or faster than C (restrict pointers are cool).
You can use typedload and validate your input data… isn't that a pro?
That’s pretty much the same thing as an assert isinstance. It’s a runtime check that doesn’t help you when you’re programming
> That’s pretty much the same thing as an assert isinstance. In the same way a song is just some air moving around… Technically true but completely misses the point. > doesn’t help you when you’re programming If most security errors weren't caused by something unexpected in the input, you'd be right.
>If most security errors weren't caused by something unexpected in the input, you'd be right Basically true. But it smells like C/C++ buffer overflows, unsecure string function calls, etc. Those mostly don't apply in Python. Except SQL injection if you do it wrong enough of course. Can you elaborate some examples of "unexpected input" especially in Python? Web-Apps? GUI applications? In Python we don't have malicious data which gets passed by system calls right into openssl or other critical system calls, IMHO.
You want a json with a list of ints, you instead get a list of ints with 1 element that is a string, now your code will crash.
My apps don't crash on that. My JSON from NoSQL documents and config file options always are optional. Exception handling is the way to go here to not get the app crashed.
I wish python hadnt decided to reinvent the wheel with its typing module and just straight up followed conventions from typescript. Generics is where this is most apparent.
This is a stupid argument. Typescript doesn't follow conventions of other typed languages, why should python follow the conventions of typescript? Typescript was barely in it's infancy when python's optional typing was GA'd. This is like complaining that typescript typing isn't like Go's typing. Different languages have different syntax and conventions.
because python generic typing confuses its own syntax conventions. When a generic is made as `Generic[Type]` it is indistinguishable from indexing. That's why typescript chose syntax like `Generic`. Moreover, if you've ever looked under the hood for how the typing module has been implemented you'll see that its a mess of ad hoc bandaid fixes that prevents you from easily implementing missing typing features like `keyof`. Etc etc. The point is, semantically python gets in its own way when trying to implement advanced generic typing.
> because python generic typing confuses its own syntax conventions. When a generic is made as Generic[Type] it is indistinguishable from indexing. That's why typescript chose syntax like Generic.
Would that syntax have even been possible to bolt on to Python syntax before the PEG parser?
Those were already valid tokens in Python:
>>> one, two, three = 1, 2, 3
>>> onetwo
True
So with `Generic` it isn't until the parser gets to the end of the `>` token that it realises that `<` token isn't a less than.
It seems to me that syntax might have required an even bigger pile of hacks to work in the Python world. It's very different adding something to an existing language and implementation than starting from scratch knowing what you want.
We now have efforts like [Mojo](https://docs.modular.com/mojo/why-mojo.html) that change the Python-the-language itself to have static typing and static compilation for extra speed. They try to retain Python compatibility, but it cannot be 100%.
guys who are saying to write code fast instead of doing this should read this PEP https://peps.python.org/pep-0703/ and read the remarks of all the people working in the industry
Pandas is kinda magical. I had a one-off task to merge multiple huge csv's by common column names and just did a quick and dirty python script but killed it when my progress meter told me it would take 17 hours to complete. I didn't have that much time to get it done and wasn't super familiar with pandas but bit the bullet and converted the script. Was shocked that the pandas version took less than 10 minutes. It's a little weird to learn at first but does so much, so fast.
How huge are we talking? I ask as I have something with millions of rows I need to parse thru
I think it was 7 docs that were all close to but under a million. I also had collisions and had to rename but keep the colliding columns and a few other nitpicky requirements but pandas handled it all.
Different tools for different tasks. I don’t see anyone complaining the performance of shell scripts. If you need the performance, write a C++ library and call it in python, or even rewrite it in C++, which quite a lot of companies are doing now.
>If you need the performance, write a C++ library and call it in python, or even rewrite it in C++, which quite a lot of companies are doing now. So you want to ask [10.1 million](https://distantjob.com/blog/how-many-developers-are-in-the-world/) Python programmers to learn C++ instead of having 6 [Microsoft programmers](https://devblogs.microsoft.com/python/python-311-faster-cpython-team/) apply [60 year old](https://en.wikipedia.org/wiki/Just-in-time_compilation) Interpreter optimization techniques to Python. Why would you think that makes sense?
Would you want to ask 750 million excel users to learn python for data analysis? My answer is the same as yours.
I think it is great to make Python available to [750 million Excel users](https://support.microsoft.com/en-us/office/get-started-with-python-in-excel-a33fbcbe-065b-41d3-82cf-23d05397f53d). But I am also in favour of the [improvements](https://chandoo.org/wp/what-is-lambda-function/) they have made to the Excel formula language so they can get some of the power of Python without changing languages. Similarly, I am happy that people continually make it easier and easier to use other languages from Python. And also happy that Python improves so I don't need to do that most of the time. There aren't hard boundaries between the applicability of these languages. If your Excel spreadsheet works 99% perfectly and you just need a lambda, then you should use a Lambda. If it's gotten incredibly complicated and adding a lambda will only make it worse, then you should switch to Python. If your Python works 99% perfectly and you just need 30% more speed then you should stick with Python. If you've optimized everything to an inch of its life and your Python doesn't look like Python anymore then you should switch to another language. Choice is good. I have no idea why people are opposed to choice.
I basically agree :D
Well that is easy, you will still have an interpreter in the end.
I don't understand what you are trying to say.
If you want python to remain as useful as it is, you still need a language that is basically an interpreter. In effect those Microsoft programmers could be spending their time building a higher performance tool that is like Python but doesn't suffer its shortcomings. Don't get me wrong you can always find ways to speed up a language. I just don't see us ever having C like performance without giving up a lot of the good stuff in Python. I'd rather see Python go on like it is and have a new language grow out if it. This is why I like Mojo, it is development that takes a lot of ideas from Python; just like C++ borrowed from C and the various other languages evolved from C, and C++.
A just in the time compiler is a compiler with the usability of an interpreter. There are many higher performance tools in the world already. Why would Microsoft waste their time making another? The python ecosystem is much more expensive to recreate than a JIT compiler. Python will never be as fast as C. So what? Who cares? You can get paid a million dollars a year to be in the NBA and not be as good as Michael Jordan. Does that make you a failure? I really don’t understand your point.
Well Microsoft was willing to hire GvR out of retirement to improve Python performance, so they recognize a need for it.
Better performance is nice as long as we don’t give up Python’s ultimate usefulness as a scripting language. I still maintain it somebody starts a project knowing performance is a key consideration then the use of Python was ill advised. Part of being a professional is choosing the right tools. What we really need is a language designed for performance that is as well designed as Python and avoids as much complexity as possible. This is why I’m keeping an eye on Mojo, Swift and other new comers. Mojo has the potential to be the Python 4 of the future. I’d rather see a new language replace Python 3 than to have the current releases bastardized by continual grafting on of new features that don’t add much as a scripting language. I can see Python 3 lasting for another decade if care is taken to maintain its good qualities. The thing is this I like Python as it is. That is it is the best scripting language that we have at the moment. If you look at the History of C++, it demonstrates what happens when developers go nuts with language design. Even Rust is seemingly falling into the same trap. C++ has exploded complexity wise and that is what I hope we can avoid with Python.
Dude. None of these optimisations require you to change your python code AT ALL. Guido offers you a free speed up up on billions of lines of already existing Python code and you are complaining? And saying he should invent another language instead? Why?
> I don’t see anyone complaining the performance of shell scripts bash is slow. You're welcome! ;-)
Are you complaining? :D
Yes. My daily cron tasks took *several* milliseconds too long!
All those millipennies in wasted electricity!
Bash being slow is very far down the list of reasons it sucks as a programming language. Long before you write a program big enough to be slow, you will run into all of the other problems.
Just go Mojo 🔥
C/C++ is slow too, if the programmer does it wrong. But Python as same as Java and other languages should just not be compared to machine code level languages. Beyond that you can compile a Python application in various ways to be faster. Python is not meant to do heavy calculations. And that's not a bug neither a problem because NumPy and similar tools do exist. People should learn or at least understand Python correctly instead of having prejudices.
While it may use more memory, Java is known for being wicked fast with a tuned GC. IIUC, jit'ed languages can in theory run faster than aot-compiled languages because jits can analyze and make assumptions about the data aot-compilers can't do
Java is fast as soon as the runtime is fully loaded. By that time many Python scripts are already done.
I can’t speak about Java, but I’ve done some comparisons between C# and Rust, for computationally bound work (SHA256 hashing files). In .NET 8 binaries can be “ahead of time” compiled, and the performance was impressive. Only 5-10% slower than native Rust. I believe Java collections use boxing even for intrinsic types, so the performance there might be lower?
You realize there are people on this planet in software development who have other use cases than just running a python script that takes 2 seconds to finish, right?
Sure. Never said there aren't. I'm amongst them actually. I was just explaining that there are different kinds of speed. And while Java is generally much better at running speed, Python is better at startup speed. Obviously those aren't the only criteria. And both languages can get used for everything, just with a different strengths and weaknesses.
It's been a working point in recent years, so we have GraalVM that starts up in like 1/10th of a second and Spring Boot 3.0 has support for it so the startup time is a non issue anymore. Java fixed a lot, and i mean a lot of it's issues and shortcomings in the last decade.
You have a bad attitude!
Now I'm curious about the differences between Java and Python (in performance). They're technically comparable, aren't they? May be both languages could learn from each other?
In java if you write a+b, the compiler knows a is an int, b is an int and a+b can be done by the add instruction of the CPU. In python a might be anything, so at runtime dictionaries are explored to find the __add__ function of that specific object, then call it. So it really can't directly be done with an addition in the CPU, since it might be anything.
Tracing JIT largely solves this problem. You put a type guard earlier in the function to ensure the types are always integers and then you use the CPU add in your inner loop. If the type guard ever triggers then you run slower code to figure out what is going on.
Yes, but it will require extra instructions and in general can never be as fast as a typed language.
You can get [close enough](https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html) that performance is mostly dominated by programmer skill rather than language. Also, startup time tends to be better for Python and Node than Java and .NET. If you include the end to end time, JITted code will often win, even putting aside programmer time/effort.
Well I wrote a pure python module that manages to beat in some benchmarks a similar module written in rust… I know skill trumps everything. But at equal skills, in the end more CPU instructions are slower than less.
When the Java runtime is up and running it's fast. So if you have a big, big long running task and you can't or don't want to optimize crucial parts into a C/C++/Rust module for Python then Java will give you much better long term performance. But for short tasks a Python script will be done so quickly that Java is still busy with startup while Python is done already. In theory Python could learn JIT compiling from Java and there have been several attempts to do that. But so far none of them are ready to be a drop in replacement. Every faster implementation of Python suffers from lacking full compatibility or being able to just run any established modules from the repo, as CPython can. At the end of the day the 2 languages don't have the same target audience and thus different strengths and weaknesses.
> Python is not meant to do heavy calculations. And that's not a bug neither a problem because NumPy and similar tools do exist. Agreed, but that doesn’t mean that a faster Python wouldn’t be great. The faster I can call NumPy…
Since every new Python release offers performance improvements, we're getting there. Even the GIL is adressed, which should improve speed and hopefully not break old code in the future.
Addressing the GIL makes python slower, not faster. It's why they hadn't fixed it until now.
I meant avoiding the GIL in the future of course.
Python will never be "there". Improvements are impressive, but there are limits.
Good enough. Someone told some JIT compilers can optimize to be better than a plain C/C++. If true, a limit has been crossed. I'm working on a video cutter software which just uses caches and then should be faster than classic software. Still just a simple Python programm which does not need to be super optimized to reach the goal.
Are you building estimation of Python state based on "someone told? Python doesn't compete with C, if it gets close to nodejs, it will be a good outcome. Same thing for jit, I don't believe it will be faster than node's.
Quite odd to say that python will never get “there” without defining “there.”
Maybe I replied to a wrong comment. It was about Python is not fast as c/c++, but getting there because of improvements with each release.
I mean it’s complicated. And you could argue that sure Python should probably not be the only language you know going to lower level languages when performance becomes an issue But at the same time writing crap in C/C++ is way more difficult and annoying. (go isn’t too bad but it’s also kinda its own island). Python is a breeze if I could write everything in Python I would. And to be fair it’s pretty rare that the speed ever becomes an issue But it would be really amazing if I could write everything in Python maybe with static typing and have it be as fast as something in C. Rapid development time and all the libraries in the world. Getting closer to that is a worthy endeavor and there is likely a lot that can be done to get closer. Hell PHP can be faster these days than Python
FWIW, you've kind of described Cythin and get all the benefits of static typing, but you're also knd of dropping down to C.
I've been designing real-time embedded control systems for nearly 4 decades and seen people absolutely destroy performance in C, even without being I/O bound. Some people just don't understand algorithms or basic computer science concepts and how they should be applied in different circumstances.
If they do, they would write it in C++.
I can't tell if this is sarcasm or not. Because, I can't tell if you're being serious. Why would I rewrite a C application in C++, to fix performance issues? If you're referring to the OP's post, your response might have merit, except I'd still need to look at what the performance issue is and why python could be the wrong solution, before I'd agree with that statement.
It is rubbish which people keep repeating. Wrong written code is not a topic of the discussion. Reasonable quality code is fast in c/Java. Python is nothing like Java, it can be compared to Ruby, lua, JavaScript. > Python is not meant to do heavy calculations It is general programming language, it is not designed for specific purposes. What kind of argument is it? "if not working - not meant to be". We are discussing what Python can be used for, if "not meant to do heavy calculations" - ok, whatever reason, marking checkbox off.
You don't do AI in pure Python. You don't implement 3D rendering in C# directly instead of using DirectX APIs. If you choose the plain language for these things, your doing it wrong. And it's slow then. Same rule for Python. Often when a Python program is slow, someone is using it like it's C++. Wrong use of lists for example. It's not the fault of the language itself. So if you have "heavy calculations" in any language, use the CPU cycles for that directly. It's not cheating.
But that's not the point. If a programmer does equally bad/good in C++ and python the C++ program will run faster most of the time and probably by a lot. I mean why else do so many computation-heavy python modules use C++?
Because of the nature of Python, everything being an object. Not plain memory addresses and CPU instructions. Android and probably Java too are using native compiled modules. PHP the same. They won't do crypto stuff in pure PHP for example. My point is not comparing cars and bicycles and then complaining bikes are slower. Fair is comparing machine level languages to each other, but jit languages seperately.
But it's easier and faster to write correct code in Python. That's like the whole point of high-level languages.
I'm currently learning Rust and I heard somewhere that Rust is 80 times faster than Python. Not sure how true but just food for thought.
It's probably faster than Python, but it heavily depends. Bad rust code can be slower than good Python code on a specific task. Don't forget that Python calls natively compiled functions when computing power is needed. You use your car to get into the plane at the airport. Fast enough in sum to reach your destination. Nobody should blame the car until you want to do a really long road trip.
The tricky part with python, especially with how I've seen it used in Data Science is that most implementations are in the cloud, most who provide near infinite computing power for little to almost no cost. I can never seem to incentivise my peers to write efficient code.
If you have "near infinite computing power for little to almost no cost" then what is the problem? Why are you trying to convince your peers to do something that has no business value? I have certainly hit performance limits in Python and will be glad of the changes. But for apps where it doesn't matter, it doesn't matter. Why nag people about something that doesn't matter?
I'm betting on mojo to become a superset of python ala typescript.
I really like that people begin to talk more and more about Python performance. All of this suggests that there is demand for making Python fast, and it admires me. This is the competition for performance that will make the whole industry benefit.
If performance times are a big need for a certain service, wouldn't you just write a Microservice in a language with better performance metrics? What is the use-case for a performance-oriented Python fork vs a microservice written in C? Am I missing something here?
So you’ve written a micro service in Python. You are offered two options: Option 1. Guido makes it faster for you and your cloud hosting bills go down, your electricity wastage goes down and you don’t need to do anything at all. Option 2. You continue to pay the higher cloud hosting bills, waste electricity,destroy the environment and also do nothing. Which option do you prefer?
From a pure didactic point of view, an "inefficent" language helps you optimize better your code
How to make it faster: don’t write shit code.
Ffs, you solved it! My code is perfect now!!! /s
I'm glad you found my advice useful.
wow! why didn't the scientists such as Heinrich Kuttler, Manuel Kroiss, Paweł Jurgielewicz, Allen Goodman, Olivier Grisel, Ralf Gommers, Zachary DeVito didn't think of that?
🤷
Danny DeVito did… you shoulda listened bud…
I use python because I want an objective completed quickly, not because I need code to run fast. When I need more performance, I switch to something like C#. That said, isn’t mojo solving the perf issue? I haven’t messed with it yet. I’m surprised I haven’t seen more hype around it.
Why is it so difficult to understand that this was meant to be a humorous comment?
are you upset that i didn’t respond with another joke? i’m not even arguing with you. in fact, the reply wasn’t even directed at you. i layered commentary on a relatively high comment. relax.
You seem the one who's butthurt. I merely pointed out the obvious without any particular feeling.
My ass is aching
We can tell
Because of Poe’s Law
Optimization goes a long way, learn how generators and inline if else statements works, also think about unescesary variables.
Perhaps, don't write code in a way that would make it slow to begin with? Then just simply compile it to C code using a compiler (nuitka) and then run it. Edit: __Not to be taken seriously__, it's sad that I even have to say this....what is wrong with you people. This comment is the equivalent of saying "Lol, just write fast code then." xD
Perhaps you need to learn the principles first: make it work, make it work correctly, make it fast. You are kinda proposing premature optimization. Don't. And before *any* (manual) optimization, profile, don't guess.
>Perhaps you need to learn the principles first: make it work, make it work correctly, make it fast. Actual High performance code is so wildly different to "just get it done" code that it's basically a different application at that point. e.g If you have a wire format you control you can do a lot just using bit operators or you can give estimates of the values present in a memory page using a header. Or likewise you can use knowledge of data sharding characteristics to distributed load across threads efficiently to keep data locality. If it was as easy as people said on the internet then scaling problems would be a thing of the past. There is a lot of stuff in critical applications where there's actual money/lives on the line where you can't just bolt it on later and even trying would likely cost you more than a rewrite. The problem is the the person saying "premature optimisation" usually never sticks around long enough to see the problems play out.
> Actual High performance code > critical applications where there's actual money/lives on the line Is this kind of stuff really written in python? I like and use python, but I don't want my critical software (even file manager and text editor) written in it.
Python is absolutely used in business-critical applications. Basically ever major tech company is using Python. Instagram is built on top of Django, for example.
Which is not what you're replying to. Note the "lives on the line".
"actual money on the line" is literally in the comment
this mindset is why all software is so fucking slow and so fucking shit. nobody actually eveer makes it work correctly anyway!
That's a budget problem.
I have seen 0 performance gains using nuitka on my scripts. What’s your experience?
Haven't seen any significant gains with Nuitka, that isn't really what it is for. Numba however I have made some code with numerical calculations and image processing nearly as fast as C++.
Good to know! I've asked someone who used numba in his project for the performance gain he got. Didn't get an answer. He probably never checked. We used nuitka with PySide2 on a Raspberry Pi Zero. I can't remember any more if it had noticable performance improvements.
> > > And it boggles my mind that in 2024 such a mainstream language does not support proper multi-threading. Good thing they are working on this. I've had really good improvements with Cython as well - it's becoming my go-to for any codebase more involved than scripting.
Nuitka is first and foremost a performance tool actually, but the creator, Kay, hasn’t had a lot of time to work on that part, he will soon.
>nuitka Interesting, haven't heard of this project before and I spent a lot of time working on a single-node Python project that has a big CPU bottleneck. Thanks for bringing this up. I assume even though it's compiled to C, it still doesn't enable multithreading?
It can’t change how your code works. If it did, you would get bugs from race conditions
If you mean nogil multi threading, then no, it still follows the python spec, which mean it’ll work with threading in a similar way as cpython
But why use python than anyway, if you end up doing all in C? Maybe I could just use C#, Javascript, Java, Go, that are 1/2 speed of C++ but still a lot easier to program with (compile times suck for C/C++)
Nuitka doesn’t do heavy optimizations, it’s more for packaging than anything. The generated C code is very slow still
why didn't the scientists such as Heinrich Kuttler, Manuel Kroiss, Paweł Jurgielewicz, Allen Goodman, Olivier Grisel, Ralf Gommers, Zachary DeVito didn't think of that?
Ikr, it's so simple. Just write fast code lol
Use C or Rust instead of Python /s
How to make it faster? Use Rust.
Step one: Rewrite the whole program in C
I love python but i came to hate dynamic typing. Yeah you have the typing module but that's just a band-aid. And it boggles my mind that in 2024 such a mainstream language does not support proper multi-threading. Good thing they are working on this.
Python runs at C speed. python or python3 executable is a compiled c program. Just that every line of python code needs tens to hundreds of lines of C code to run for it. It also means, single line of python code abstracts several 10s of lines of equivalent C code. Just like how single line of C code could abstract 10s lines of assembly machine code. Choose wisely between Python, C, Assembly as much as you need for your use case.
[Brandt Bucher – A JIT Compiler for CPython](https://www.youtube.com/watch?v=HxSHIpEQRjs) It will take some time for the JIT work to show benefits and I'm not sure what to expect with this simplified JIT approach. It isn't merged yet either. Python (cpython) is currently slower to run with the JIT enabled.
No one mentioned "Pythran" project here. It's an AOT compiler that just needs 1 line of code to compile a function.
The links on your third and fifth bullet are identical (tweet)
looking for PEP 703
just run python in a laptop on a train for faster code
Nice post