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

Python 3.11 vs 3.10 performance

github.com

Post reply on HN
Print view View original

231–240 of 460 posts

Re: Python 3.11 vs 3.10 performance

#231

Post by cercatrova »

lanstin wrote: post #215
zitterbewegung wrote: post #136

Earlier quoted context omitted.

Back when Python was started there was really C or C++ for optimized programs and scripting languages like Python and Perl. But since Python had the ability for C Extensions it allowed it to bypass those problems. Since Python was easy to learn both web developers and scientists to learn. Then financial organizations started to get interested and that’s really how Python cemented itself. What exactly do you do with P…

I worked on Python almost exclusively for maybe five years. Then I tried go. Each time I wrote a go program, I am giddy with excitement at how fast my first attempt is, scaling so smoothly with the number of cores. I also wrote a lot of fairly performant C in the 90s, so I know what computers can do in a second. I still use Python for cases when dev time is more important than execution time (which is rarer now that…

You should try Nim, it's Python like but compiled so it's as far as C. These days if I want to script something (and don't need Python specific libraries like pandas) I use Nim.

Re: Python 3.11 vs 3.10 performance

#233

Post by gus_massa »

atwood22 wrote: post #151
soperj wrote: 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.

You usually need more tricks for fast code. Bubble sort is easy to program (it' my default when I have to sort manually, and the data is has only like 10 items)

There are a few much better options like mergesort or quicksort, but they have their tricks.

But to sort real data really fast, you should use something like timsort, that detects if the data is just the union of two (or a few) sorted parts, so it's faster in many cases where the usual sorting methods don't detect the sorted initial parts. https://en.wikipedia.org/wiki/Timsort

Are you sorting integers? Strings? Ascii-only strings? Perhaps the code should detect some of them and run an specialized version.

Re: Python 3.11 vs 3.10 performance

#235

Post by timoteostewart »

8organicbits wrote: post #212
timoteostewart wrote: post #194

Earlier quoted context omitted.

I believe that quote about debugging being twice as hard as coding is by Brian Kernighan. https://en.m.wikiquote.org/wiki/Brian_Kernighan

Maybe, I grabbed the first matching quote I found. I can't attribute it on my own.

No sweat. I’m a quote nerd so it jumped out at me

Re: Python 3.11 vs 3.10 performance

#236

Post by tnvaught »

dekhn wrote: post #37
KptMarchewa wrote: post #17

Earlier quoted context omitted.

Answer is very simple. Amount of people who got paid to make python fast was rounded to 0.

Not really. There were a couple engineers working at Google on a project called unladen swallow which was extremely promising but it eventually got canceled. The developer who worked at Microsoft to make iron python I think that was his full-time project as well and it was definitely faster than cpython at the time

"The developer who worked at Microsoft to make iron python" - Jim Hugunin [1] (say his name!) to whom much is owed by the python community and humanity, generally.

[1] https://en.wikipedia.org/wiki/Jim_Hugunin

Re: Python 3.11 vs 3.10 performance

#237

Post by metadat »

BerislavLopac wrote: post #229
antman wrote: 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.

> the vast majority of Python software is written as single-threaded.

This is a self-fulfilling prophecy, as the GIL makes Python's (and Ruby's) concurrency story pretty rough compared to nearly all other widely used languages: C, C++, Java, Go, Rust, and even Javascript (as of late).

Re: Python 3.11 vs 3.10 performance

#239

Post by samatman »

AlexTWithBeard wrote: post #133
gpderetta wrote: post #84

Earlier quoted context omitted.

There are a lot of dynamically typed languages that are significantly faster than python. Late binding issues can be effectively worked around.

Do you have an example of a dynamically typed language where, say, addition of two lists of doubles would be significantly faster than in Python?

I would expect this microbenchpark in particular to be as fast in LuaJIT as it would be in C, without the risk of undefined behavior if the array boundaries are improperly calculated.
Post reply on HN