Live data from Hacker News

Python 3.11 vs 3.10 performance

github.com

221–230 of 460 posts

Re: Python 3.11 vs 3.10 performance

#221
post #51

Earlier quoted context omitted.

This is probably the wrong comparison to make: Python is two orders of magnitude slower than compiled GC languages, but it's in the same order of magnitude as most other interpreted GC languages. (It actually changes a whole lot, because there's a whole lot of code already out there written in Python. 25% faster is still 25% faster, even if the code would have been 100x faster to begin with in another language.)

I thought Python was slower than many other interpreted languages but looking at some benchmark it turns out I was wrong. It's about on par with Ruby, only Lua and JIT compiled runtimes beat it (for very understandable reasons).

Javascript spanks other scripting languages.

Re: Python 3.11 vs 3.10 performance

#222
post #85

Earlier quoted context omitted.

When you only have so many hours to go around, you concentrate on the main goals.

My point is that you can write fast code just as easily as you can write slow code. So engineers should write fast code when possible. Obviously you can spend a lot of time making things faster, but that doesn't mean you can't be fast by default.

Not true. Premature optimization is the root of all evil. You first write clean code, and then you profile and optimize. I refer you to the underlyings of dicts through the years (https://www.youtube.com/watch?v=npw4s1QTmPg) as an example of that optimization taking years of incremental changes. Once you see the current version it's easy to claim that you would have get to the current and best version in the first place, as obvious as it looks in hindsight.

Re: Python 3.11 vs 3.10 performance

#223

Earlier quoted context omitted.

In a way it's a nice incentive not to nest too much (I have that tendency too)

Hold my beer! https://i.redd.it/8waggyjyyle51.png

Hold mine :D https://github.com/anchpop/genomics_viz/blob/master/genomics...

That's one expression because it used to be part of a giant comprehension, but I moved it into a function for a bit more readability. I'm considering moving it back just for kicks though.

My philosophy is: if you're only barely smart enough to code it, you aren't smart enough to debug it. Therefore, you should code at your limit, to force yourself to get smarter while debugging

Re: Python 3.11 vs 3.10 performance

#224

One of the biggest features I'm looking forward to is the more specific error messages. I can't tell you how much time I've wasted with cryptic errors that just point to a line that has a list comprehension or similar.

This is the first time I ever heard someone complain about Python's error messages in the 10+ years I've been using it. Even people who just learned it, pick up reading tracebacks after about a day of practice. The only problem I ever see is if a library swallows too much, and gives a generic error, but that's not something the language can fix. I really hope they don't change things too much.

Re: Python 3.11 vs 3.10 performance

#225
post #208

There was always a denial of removing the Global Interpreter Lock because it would decrease single threaded Python speed for which most people din’t care. So I remember a guy recently came up with a patch that both removed GIL and also to make it easier for the core team to accept it he added also an equivalent number of optimizations. I hope this release was is not we got the optimizations but ignored the GIL part.…

I use a beautiful hack in the Cosmopolitan Libc codebase (x86 only) where we rewrite NOPs into function calls at runtime for all locking operations as soon as clone() is called. https://github.com/jart/cosmopolitan/blob/5df3e4e7a898d223ce... The big ugly macro that makes it work is here https://github.com/jart/cosmopolitan/blob/master/libc/intrin... An example of how it's used is here. https://github.com/jart/cosmopolitan/blob/5df3e4e7a898d223ce... What it means is that things like stdio goes 3x faster if you're not actually using threads. The tradeoff is it's architecture specific and requires self-modifying code. Maybe something like this could help Python?

Re: Python 3.11 vs 3.10 performance

#226
post #14

I wish there was something like llvm for scripting languages. Imagine if python, php, javascript, dart or ruby would not interpret the code themself, but compile to an interpretable common language, where you could just plug in the fastest interpreter there is for the job.

The issue is that Python is sort of necessarily slow. Most code translates 1:1 to straightforward C but of course it is possible to create some monstrosity where, after the 3rd time an exception is thrown, all integer arithmetics change and string addition turns into 'eval'.

All approaches to "make Python fast again" tend to lock down some of the flexibility so aren't realy general purpose.

Re: Python 3.11 vs 3.10 performance

#227
post #208

There was always a denial of removing the Global Interpreter Lock because it would decrease single threaded Python speed for which most people din’t care. So I remember a guy recently came up with a patch that both removed GIL and also to make it easier for the core team to accept it he added also an equivalent number of optimizations. I hope this release was is not we got the optimizations but ignored the GIL part.…

I think you mean the work by Sam Gross:

https://github.com/colesbury/nogil/

Interesting article about it here:

https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0...

Re: Python 3.11 vs 3.10 performance

#228

One of the biggest features I'm looking forward to is the more specific error messages. I can't tell you how much time I've wasted with cryptic errors that just point to a line that has a list comprehension or similar.

I've been learning Rust recently. There are a number of things about the language that I dislike, but its error messages are an absolute joy. They clearly put an incredible amount of effort into them, and it really shows.

Re: Python 3.11 vs 3.10 performance

#229
post #208

There was always a denial of removing the Global Interpreter Lock because it would decrease single threaded Python speed for which most people din’t care. So I remember a guy recently came up with a patch that both removed GIL and also to make it easier for the core team to accept it he added also an equivalent number of optimizations. I hope this release was is not we got the optimizations but ignored the GIL part.…

The GIL removal by that guy reverted some of the improvement done by other optimisations, so the overall improvement was much smaller.

And most people do care for single-threaded speed, because the vast majority of Python software is written as single-threaded.

Re: Python 3.11 vs 3.10 performance

#230
post #208

There was always a denial of removing the Global Interpreter Lock because it would decrease single threaded Python speed for which most people din’t care. So I remember a guy recently came up with a patch that both removed GIL and also to make it easier for the core team to accept it he added also an equivalent number of optimizations. I hope this release was is not we got the optimizations but ignored the GIL part.…

[deleted]
Post reply on HN