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

421–430 of 460 posts

Re: Python 3.11 vs 3.10 performance

#421

Post by galangalalgol »

sundarurfriend wrote: post #384
galangalalgol wrote: post #329

Earlier quoted context omitted.

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.

> I honestly don't understand how much slower arrays are. Its like 30x or similar. In what context, under what operation? Depending on context, the difference makes sense and is what one would expect - tuples are immutable, with fixed size known at compile time, and stack-allocated; arrays are mutable, dynamic in size, and usually heap-allocated. That's why StaticArrays.jl [1] exists, for when you need something in b…

I had been using arrays the way I'd use vectors in c++ or arrays in matlab. For DSP type tasks you typically allocate a tensor on the heap, the size can be constant and even hardcoded, which allows lots of optimization. But when I modified the nbody implementation from the benchmark game from tuples to arrays for the position and velocity vectors it went from 5.3s to 3min+. That was with specifying the type and initializing them as part of a struct all at once.... And I just realized my mistake, everytime I made a new struct it was allocating a new array with all the overhead that entails. Simply ditching the structs for a single array and allowing them to mutate would have been more idiomatic to the way I use matlab and it would have avoided all that reallocation.

Re: Python 3.11 vs 3.10 performance

#422

Post by gpderetta »

dbrueck wrote: post #292
coliveira wrote: post #281

Earlier quoted context omitted.

I don't buy this. There are many contexts in which a smart JIT compiler can detect that an expression cannot be modified. Especially since, due to the GIL, python code is mostly non-threaded. They just didn't spend enough time to do the hard work that people spent on Javascript.

> can detect that an expression cannot be modified Can you give some examples? I use Python a lot and it's absurdly dynamic. I've sometimes wondered if there'd be some way to let me as the programmer say "dynamicness of this module is only 9 instead of the default 11" but I'm skeptical of a tool's ability to reliably deduce things. Here's just one example: a = 0 for i in range(10): a += 1 log('A is', a) In most langu…

I think the way it is usually done is that the JIT assumes, for example after profiling, that an expression has a specific type, generates code according to that assumption and adds strategic guards to check that the assumptions are still valid, with a fall back path to the original unoptimized code. Thanks to the magic of branch prediction the guards have little runtime cost.

Re: Python 3.11 vs 3.10 performance

#423

Post by galangalalgol »

ChrisRackauckas wrote: post #404
jolux wrote: post #336

Earlier quoted context omitted.

That’s bizarre, are they implemented as linked lists or something? Why would arrays be that slow?

They aren't, which is why the statement doesn't make sense haha. The difference is really just that tuples of isbits types can be stack allocated (and tuples of isbits types are isbits, so they can nest, etc.), and so in some cases with sufficiently small amounts of data, creating stack allocated objects is much faster than creating heap allocated objects. But if you compare concretely typed heap allocated arrays in…

My background is over 28 years of c++ programming 20 of that as my profession. My mistake in retrospect was using small arrays as part of a struct, which being immutable got replaced at each time step with a new struct requiring new arrays to be allocated and initialized. I would not have done that in c++, but julia puts my brain in matlab mode. If I had gone full matlab and just used a matrix or tensor instead of an array of structa of arrays then I would have still taken a hit from the mutability, but not the one I did take. After successfully doing some DSP in julia I became arrogant and took on the nbody benchmark at benchmark game. I did discover that targeting skylake instead of ivybridge made no change. It doubled the speed of the c++ and rust solutions. Removing @inbounds was less than a 10% hit. And the iterative fastmath inverse sqrt was absolutely neutral on the skylake machine I used. Sqrt was just as fast. I did get a 10% bump by making the 3tuples into 4tuples for position and velocity. Alignment I'd assumed, but padding the struct instead of the tuple did nothing, so probably extra work to clear a piece of an simd load. Any insight on why avx availability didn't help would be appreciated. I did verify some avx instructions were in the asm it generated, so it knew, it just didn't use.

Re: Python 3.11 vs 3.10 performance

#424

Post by kaba0 »

IceWreck wrote: post #333
tempest_ wrote: post #306

Earlier quoted context omitted.

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.

Or maybe keep things the way they are.If you really need performance python is not the language you should be looking for. Instead of breaking decades of code, maybe use a language like Go or Rust for performance instead.

Why put Go and Rust in the same category? I never really understood that.

Either include like almost every language from JS, Java, C# to Haskell, or just list C++ and Rust. But Go is in the former category.

Re: Python 3.11 vs 3.10 performance

#425

Post by kaba0 »

fnord123 wrote: post #382
xwdv wrote: post #353

Earlier quoted context omitted.

I would have thought convincing people they’ll just have to use Go or Rust or Elixir would have been an easy sell around here. Turns out they just want a better Python.

>Turns out they just want a better Python. That's Go. It gives actual types[1] and structs (so you dont have to wonder about dict, class, class with slots, dataclasses, pydantic, attrs, cattrs, marshmallow, etc). It removes exceptions and monkeypatching. It's async-first (a bit like gevent). It's inherently multicore. And you can package and distribute it without marking a pentagram on the ground and sacrificing an i…

Going to the very unexpressive Go from the expressivity of python is a goddamn huge jump though.

Going to JS or even TS for performance would be saner, and it has a same-ish object model even.

Re: Python 3.11 vs 3.10 performance

#426

Post by andrewaylett »

int_19h wrote: post #266
ChadNauseam wrote: post #223

Earlier quoted context omitted.

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 yo…

Yours is nice and readable. Parents' one is not, but it feels like the indentation is deliberately confusing. I'd lay it out like so: tags = list(set([ nel for subli in [ mel for subl in [ [[jel.split('/')[2:] for jel in el] for el in classified ] for mel in subl ] for nel in subli if nel ])) Still not very readable, tho. But that's largely due to Python's outputs-first sequence comprehension syntax being a mess that…

Since it's all generator expressions internally anyway, an intermediate doesn't actually add appreciable (any?) runtime overhead but does make the code more readable:

    ys = (x.ComputeSomething() for x in xs)
    result = [y for y in ys if y.isFoo and y.isBar]

Re: Python 3.11 vs 3.10 performance

#427

Post by winstonewert »

smcl wrote: post #387
winstonewert wrote: post #169

Earlier quoted context omitted.

The thing is, when I see people using this quote, I don't see them generally using it to mean you should never optimize. I think people don't ignore the premature bit in general. Now, throwing this quote out there generally doesn't contribute to the conversation. But then, I think, neither does telling people to read the context when the context doesn't change the meaning of the quote.

Right but if they post just that part, they're probably heavily implying that now is not the time to optimize. I've seen way more people using it to argue that you shouldn't be focussing on performance at this time, than saying "sometimes you gotta focus on that 3% mentioned in the part of the quote that I deliberately omitted"

No, they don't deliberately omit the part of the quote. They are either unaware of that part of the quote or don't think it matters to the point they are making.

Yes, if you quote Knuth here (whether the short quote or a longer version) you are probably responding to someone whom you believe is engaged in premature optimization.

It remains that the person quoting Knuth isn't claiming that there isn't such a thing as justified optimization. As such, pointing to the context doesn't really add to the conversation. (Nor does a thoughtless quote of Knuth either)

Re: Python 3.11 vs 3.10 performance

#428

Post by michaelcampbell »

smcl wrote: post #412
michaelcampbell wrote: post #410

This use of "faster" in the text; I think they mean "as fast". "1x faster" to me says twice the speed of the original, but I believe they use it to mean "the same speed".

That's not actually a bad observation even though you were downvoted. I think in the end it's technically ambiguous but most people would be able to see what is meant especially given the previous performance is present (i.e. for benchmark "deltablue" we have columns "12.4 ms" and "6.35 ms (1.96x faster)". But you're right, I think "1.96x as fast" sounds more correct. edit: but now that I think about it "X as fast" o…

It's an OCD pet peeve of mine. Worse yet is "2x slower!" To me, 1x slower is "stopped". I know they MEAN "1/2 the speed", but it still bugs me.

Re: Python 3.11 vs 3.10 performance

#429

Post by chaps »

IceWreck wrote: post #333
tempest_ wrote: post #306

Earlier quoted context omitted.

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.

Or maybe keep things the way they are.If you really need performance python is not the language you should be looking for. Instead of breaking decades of code, maybe use a language like Go or Rust for performance instead.

Python has basically already done exactly that with 2.7 to 3 and we came out of that relatively fine.

I say bring it.

Re: Python 3.11 vs 3.10 performance

#430

Post by fnord123 »

kaba0 wrote: post #425
fnord123 wrote: post #382

Earlier quoted context omitted.

>Turns out they just want a better Python. That's Go. It gives actual types[1] and structs (so you dont have to wonder about dict, class, class with slots, dataclasses, pydantic, attrs, cattrs, marshmallow, etc). It removes exceptions and monkeypatching. It's async-first (a bit like gevent). It's inherently multicore. And you can package and distribute it without marking a pentagram on the ground and sacrificing an i…

Going to the very unexpressive Go from the expressivity of python is a goddamn huge jump though. Going to JS or even TS for performance would be saner, and it has a same-ish object model even.

The expressivity in Python is a problem that needs to be solved though. Moving to JS goes the wrong way.
Post reply on HN