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

321–330 of 460 posts

Re: Python 3.11 vs 3.10 performance

#321

Post by bbkane »

cercatrova wrote: post #231
lanstin wrote: post #215

Earlier quoted context omitted.

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.

He's already using Go. Does Nim provide any "killer features" that Go doesn't?

Re: Python 3.11 vs 3.10 performance

#322

Post by cercatrova »

bbkane wrote: post #321
cercatrova wrote: post #231

Earlier quoted context omitted.

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.

He's already using Go. Does Nim provide any "killer features" that Go doesn't?

Well, good generics and sane error handling, for two examples.

Re: Python 3.11 vs 3.10 performance

#323

Post by moffkalast »

cercatrova wrote: post #297
int_19h wrote: post #268

Earlier quoted context omitted.

The problem with any new language is libraries and tooling.

I use it for scripting mainly when I don't need Python specific libraries like pandas. The tooling is pretty good as well.

Seems like just going with bash would be more straightforward?

Re: Python 3.11 vs 3.10 performance

#324

Post by kzrdude »

e-master wrote: post #311
dec0dedab0de wrote: post #224

Earlier quoted context omitted.

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.

I only rarely delve into the python world, but as a .net developer I always found it odd and confusing that the error message comes after the stack trace in python. I don’t see people complaining about it, so maybe it’s just a matter of habit?

I guess it's just a habit even if I think it's mildly confusing too.

But: it's kind of a virtue that the most important error message comes last. Far too many (ahead of time) compilers output too many errors. The most likely error to matter is the first one, but it is often scrolled way off screen; the following errors might even just be side effects that mislead or confuse the new users.

Re: Python 3.11 vs 3.10 performance

#325

Post by kzrdude »

yantrams wrote: post #199
agumonkey wrote: post #175

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

It's “not even” using for nesting in list comprehensions. This kind of thing:

   [x for stop in range(5) for x in range(stop)]

Re: Python 3.11 vs 3.10 performance

#326

Post by cercatrova »

moffkalast wrote: post #323
cercatrova wrote: post #297

Earlier quoted context omitted.

I use it for scripting mainly when I don't need Python specific libraries like pandas. The tooling is pretty good as well.

Seems like just going with bash would be more straightforward?

Why would I want to subject myself to writing in a language like bash? Bash has many disadvantages compared to Python, Nim, Go, nearly anything that isn't brainfuck.

Re: Python 3.11 vs 3.10 performance

#327

Post by dragonwriter »

winstonewert wrote: post #174
bshipp wrote: post #168

Earlier quoted context omitted.

You certainly can accept that slowdown if the total program run-time remains within acceptable limits and the use of a rapid prototyping language reduces development time. There are times when doing computationally heavy, long-running processes where speed is important, but if the 1000x speedup is not noticeable to the user than is it really a good use of development time to convert that to a more optimized language?…

I would note that the choice of programming language is a bit different. Projects are pretty much locked into that choice. You've got to decide upfront whether the trade off in a rapid prototyping language is good or not, not wait until you've written the project and then profile it.

> Projects are pretty much locked into that choice.

But, they aren't.

I mean, profile, identify critical components, and rewrite in C (or some other low-level language) for performance is a normal thing for most scripting languages.

> You've got to decide upfront whether the trade off in a rapid prototyping language is good or not, not wait until you've written the project and then profile it.

No, you absolutely don't.

Re: Python 3.11 vs 3.10 performance

#328

Post by aunty_helen »

bergenty wrote: post #310
StevePerkins wrote: post #280

Earlier quoted context omitted.

If you just learned this today, then HN has severely lost respect for you! lol

Yes it’s deserved but I’ve been in management for a while.

From your perspective then, python is 100x faster than c

Re: Python 3.11 vs 3.10 performance

#329

Post by galangalalgol »

ModernMech wrote: post #263
superjan wrote: post #198

Yesterday, I watched Emery Berger’s “Python performance matters” Which is you should not bother to write fast Python, just delegate all heavy lifting to optimized C/c++ and the likes. His group has a Python profiler whose main goal is to point out which parts should be delegated. Of course optimized is better but the numeric microbenchmarks in this post are mostly examples of code that is better delegated to low over…

> you should not bother to write fast Python, just delegate all heavy lifting to optimized C/c++ and the likes Certainly that's something you can do, but unfortunately for Python it opens the door for languages like Julia, which are trying to say that you can have your cake and eat it too.

I like Julia but its easy to write slow julia unless you keep the performance tips in mind. Arrays are horribly slow, tuples are much faster, but having tuples be a multiple of 128 bytes adds 10% or more to speed. I honestly don't understand how much slower arrays are. Its like 30x or similar.

Re: Python 3.11 vs 3.10 performance

#330

Post by oofbey »

tempest_ wrote: post #306
tyingq wrote: post #250

Earlier quoted context omitted.

Getting rid of the GIL will also immediately expose all the not-thread-safe stuff that currently exists, so there's a couple of waves you would need before it would be broadly usable.

Cool, they should start now. As a python dev, pythons multiprocess/multithreading story is one the largest pain points in the language. Single threaded performance is not that useful while processors have been growing sideways for 10 years. I often look at elixir with jealousy.

On the flip side, if your workload can be parallelized across thousands of cores, python has about the best CUDA support anywhere.
Post reply on HN