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

Making Python faster with Rust

ohadravid.github.io

Post reply on HN
Print view View original

201–210 of 223 posts

Re: Making Python faster with Rust

#201

Post by alex_sf »

INTPenis wrote: post #187
alex_sf wrote: post #30

Earlier quoted context omitted.

Python is a rough language to be productive in. It's a great scratchpad, but dynamic typing, exceptions/poor error handling, and a horrifying deployment and dependency system make me reach for something like Go in any case where I need something to be even vaguely reliable. The more ML I do, the more disappointed I get.

That's just habitual. Anyone coming from Python could say the same things about another language. The typing never bothered me because you learn to work with it. But there is of course type hinting now, which I barely use.

I don't think so. I was a Python dev for years, and plenty of other languages don't have the issues Python does. It was a great learning language when I started, but I think most folks that have only used Python just don't realize what they are missing.

Re: Making Python faster with Rust

#202

Post by jmalicki »

Yoric wrote: post #179
snicker7 wrote: post #177

Earlier quoted context omitted.

Languages and with some sort of decent metaprogramming support can alleviate this sort of issue (see Zig, Julia, Jai, etc.)

Do you have examples? I cannot think of a good way to do that.

For python, you can use pandas. It even has arrow support now.

Re: Making Python faster with Rust

#203

Post by INTPenis »

alex_sf wrote: post #201
INTPenis wrote: post #187

Earlier quoted context omitted.

That's just habitual. Anyone coming from Python could say the same things about another language. The typing never bothered me because you learn to work with it. But there is of course type hinting now, which I barely use.

I don't think so. I was a Python dev for years, and plenty of other languages don't have the issues Python does. It was a great learning language when I started, but I think most folks that have only used Python just don't realize what they are missing.

Can you give me an example from your recent memory?

I've been coding since the 90s, ASP, PHP, JS, C, Perl, I transitioned from Perl to Python back in 2012-2013. Dabbled in Go when it first came out because I was a Plan9 fanatic and recognized some of the source files, but never went further than tutorials.

Honestly I find very little wrong with the Python ecosystem, except the general insecurity of using package managers. But that applies to most package management, it's a social/infosec issue that Fedora has mitigated fairly well, if you want role models.

The languages that I found most annoying, as a user and developer, were C, Javascript, Typescript and Ruby.

Re: Making Python faster with Rust

#204

Post by rpep »

prirun wrote: post #196
lights0123 wrote: post #192

Earlier quoted context omitted.

It appears that you didn't enable optimizations. That's needed for SIMD, which can only be taken advantage of with contiguously packed data.

Results with -O are below. x1 (AoS) vs x2 (SoA): no performance difference x3 (arrays not in structure, both arrays in loop): slower x4 (arrays not in structure, one array in loop): faster My advice is still not to assume that SoA is always faster than AoS without benchmarking. + cc -O -o x1 x1.c + ./x1 s=1808348672 real 0m11.775s user 0m3.540s sys 0m6.592s + ./x1 s=1808348672 real 0m5.427s user 0m2.727s sys 0m2.682s…

You need to add “-march=native” to turn on SIMD at the highest level your processor will support, otherwise it will just use SSE4.1 by default on most compilers (the lowest common denominator, as all x86-64 processors have it).

Re: Making Python faster with Rust

#205

Post by rpep »

josephg wrote: post #45
INTPenis wrote: post #11

Earlier quoted context omitted.

Yeah what's wrong with that? I think this sounds amazing. It gives you all the fast prototyping and simplicity of Python, but once you hit that bottleneck all you have to do is bring in a ringer to replace key components with a faster language. No need to use Golang or Rust from the start, no need for those resources until you absolutely need the speed improvement. Sounds like a dream to a lot of people who find it m…

It sounds amazing, but bear in mind there are a lot of code which can’t be sped up like this because: - Some code doesn’t have obvious optimization hotspots, and is instead just generally slow everywhere. - Most FFI boundaries incur their own performance cost. I’m not sure about Python, but I wouldn’t be surprised if FFI to rust in a hot loop is often slower than just writing the same code in Python directly. And it’…

> Most FFI boundaries incur their own performance cost. I’m not sure about Python, but I wouldn’t be surprised if FFI to rust in a hot loop is often slower than just writing the same code in Python directly. And it’s not always easy to refactor to avoid this.

They definitely do, but I’d usually suggest that if you find this an issue then perhaps the function you’re exposing from the compiled language should be higher level, with more work done in the compiled code to avoid the overhead of returning control back to the interpreted language.

Re: Making Python faster with Rust

#206

Post by Yoric »

jmalicki wrote: post #202
Yoric wrote: post #179

Earlier quoted context omitted.

Do you have examples? I cannot think of a good way to do that.

For python, you can use pandas. It even has arrow support now.

Yeah, I need to try it.

But the parent was suggesting that metaprogramming could make readability issues go away and I can't wrap my head around how it would do that.

Re: Making Python faster with Rust

#207

Post by pjmlp »

dunefox wrote: post #93
karussell wrote: post #79

I wonder why GraalVM is not more often used for these speed critical cases: https://www.graalvm.org/python/ (Same for ruby https://www.graalvm.org/ruby/ ) Is the problem the Oracle involvement? Or is it not that fast as advertised or problems with the ecosystem (C libraries)?

I would not use anything made by oracle if I have the choice. My team sees it similarly.

Better clean up the Linux kernel from Oracle contributions then, in case you are using it.

https://lwn.net/Articles/915435/

Re: Making Python faster with Rust

#208

Post by ohr »

appeldorian wrote: post #96

I think a big mistake in the article, in a context where performance is the main objective, is that the author uses an array of structs (AoS), rather than a struct of arrays (SoA). An SoA makes it so that the data is ordered contiguously, which is easy to read for the CPU, while an AoS structure interleaves different data (namely the x and y in this case), which is very annoying for the CPU. A CPU likes to read chunk…

Author here: I agree, that's a great perf advice (esp. when you can restructure your code).

I couldn't get into a this in the article (would be too long), but this is a great point and the original library does this in a lot of places.

One problem in our use case is that the actual structs members are pretty big & that we need to group/regroup them a lot.

The fastest approach for us was to do something like in the article for the initial filtering, then build a hashmap of SoAs with the needed data, and do the heavier math on that.

Re: Making Python faster with Rust

#209

Post by dunefox »

pjmlp wrote: post #207
dunefox wrote: post #93

Earlier quoted context omitted.

I would not use anything made by oracle if I have the choice. My team sees it similarly.

Better clean up the Linux kernel from Oracle contributions then, in case you are using it. https://lwn.net/Articles/915435/

So the Linux kernel is an Oracle licensed product? Better uninstall Ubuntu then.

Re: Making Python faster with Rust

#210

Post by ohr »

akasakahakada wrote: post #145
hn92726819 wrote: post #138

Earlier quoted context omitted.

It might have been added later, but the author mentions vectorization in the beginning: > It’s worth noting that converting parts of / everything to vectorized numpy might be possible for this toy library, but will be nearly impossible for the real library while making the code much less readable and modifiable, and the gains are going to be limited (here’s a partially vertorized version, which is faster but far from…

Semi Vectorized code: https://github.com/ohadravid/poly-match/blob/main/poly_match... Expecting Python engineers unable to read defacto standard numpy code but meanwhile expect everyone can read Rust..... Not to mention that the semi-vectorized code is still suboptimal. Too many for loops despite the author clearly know they can all be vectorized. For example instead the author can just write something like: np.argmi…

Author here:

For the original library we did all the numpy tricks we could think of, but we really needed to do this type of exhaustive search for some of the data.

If someone wants to open a PR with a "fully optimized" numpy code, that would be very cool just for comparison :)

Post reply on HN