Using the unsafe keyword... somehow makes me wonder where else unsafe is used...
Only to remove a bounds check that's guaranteed to be unneeded (well, that's what the author says, but it's not unbelievable).
Recent adventures in performance optimization with Rust
21–30 of 75 posts
Re: Recent adventures in performance optimization with Rust
#22Earlier quoted context omitted.
I like Python too but let's face it, it is not performant. Why do we have to pretend otherwise?
I think everybody agrees and is not pretending otherwise. But my thing is, I think the problem could be solved in a different way in Python where we can use performant libraries to get an answer in a reasonable time. The author says the naive Python implementation with a for-loop takes 36 milliseconds per iteration, and the problem requires 2.5 billion iterations (= 2.9 years, which is unreasonable) while optimized R…
8 minutes.
Re: Recent adventures in performance optimization with Rust
#23It's crazy to me how the author spends most of his time finding out what hides in his abstractions, and then changing that. Especially those macros, and a few random crates used, make this code quite hard to reason about.
Re: Recent adventures in performance optimization with Rust
#24Comparing highly optimized code (including total algorithm rewrite and relying on unsafe and SIMD operations) without doing the same on the other side is a pointless exercise. It's like showing how much faster you can get your handcrafted assembly code to run vs a bash script.
articles like this aren't pointless, i don't think it is meant to be framed as a fair comparison of "rust-the-language is 5 orders of magnitude faster than python-the-language". this article does offer examples of how to use a profiler and some ideas of what kind of things can be bottlenecks and how to eliminate them, and also helps people who only ever work with very slow programming tech stacks to understand what kind of speedups can be attainable in practice when using a tech stack that can use a machine's resources efficiently. it's a good write up and can be educational in a variety of ways for some segments of readers. if you only ever do pure python programming, and that informs your beliefs of what "fast" and "slow" programs feel like, seeing what performance cheap modern CPUs are actually capable of when used effectively is a bit like being exposed to alien technology.
Re: Recent adventures in performance optimization with Rust
#25Comparing highly optimized code (including total algorithm rewrite and relying on unsafe and SIMD operations) without doing the same on the other side is a pointless exercise. It's like showing how much faster you can get your handcrafted assembly code to run vs a bash script.
The author was clear what he was setting out to demonstrate in the piece
This format is likely very useful for anyone working on such large sets using Jupyter/Python and waiting days for scripts to complete -- there is nothing wrong with those final tricky optimisations when applied to single-use scripts
I found it a useful reminder that there is often more to be squeezed out on inner loops with a few mins more thought
Re: Recent adventures in performance optimization with Rust
#26Obviously not the point of the post, but this doesn't seem like a very reasonable thing to calculate, statistically speaking.
Also, I wonder if there is some way to use branch-and-bound to look at fewer combinations.
Re: Recent adventures in performance optimization with Rust
#27The Mojo PR team on their way to hire OP to publish these sort of articles at Modular.
I keep wondering if Mojo will take over the world or somehow become Betamax.
Clearly Betamax. It certainly has it's uses and it's development is led by the right people but there's no magic.
It's just another LLVM frontend.
Also I'm slightly annoyed by the fact that they kept talking about great GPU performance in their marketing material and all you can find in the docs is: "it's coming. probably. only to Nvidia hardware btw."
Re: Recent adventures in performance optimization with Rust
#28want to write fast rust? write your code in C or C++
you're getting downvoted because you said it in a weird way, but fundamentally I have to agree. Both C and C++, if written idiomatically, have less syntactic sugar and macros are less accepted, so that their code ends up hiding a lot less complexity than rust code.
Fairly complex code like what the author showed turns out to use a bunch of different random things nobody expected.
Re: Recent adventures in performance optimization with Rust
#29> the point of this post isn’t to compare highly-optimized Python to highly-optimized Rust. The point is to compare “standard-Jupyter-notebook” Python to highly-optimized Rust. I guess the title gets clicks, but I'm curious how good python gets. I'm under the impression pandas is pretty fast despite it being python
Pandas can be pretty fast, but DuckDB and Polars are both faster than Pandas. DuckDB supports vectorized and parallelized operations on Pandas dataframes, while Polars is written in Rust. I feel though the killer is that inner loop where dataframe operations are being performed across a large number of iterations, and there's significant overhead there. For-loops are usually not the most performant solution in Python…
Numba is another excellent Python option for speedier python solutions
Re: Recent adventures in performance optimization with Rust
#30Using the unsafe keyword... somehow makes me wonder where else unsafe is used...
Nothing wrong with using unsafe if performance is essential and it’s wrapped up with good testing and kept safely tucked away in a library.