Anyone else think this code is ugly as hell?
[deleted]
Recent adventures in performance optimization with Rust
51–60 of 75 posts
Re: Recent adventures in performance optimization with Rust
#52Earlier quoted context omitted.
I like Python too but let's face it, it is not performant. Why do we have to pretend otherwise?
The industry agreed to standardize on Python for the task of describing compute-graphs that get executed by compute engines implemented in something other than Python. Python is not meant to be used for the computation itself.
And then other people came along, using other languages, and realised we could do the same compute, with a fraction of the hardware, in about the same time, in the languages they’re already using, which really diminishes the appeal of Python, which boils down to:
“Setup some infra, and get someone who knows how to operate it, and then write new code in python, and babysit it as it ossifies into a core piece of infrastructure”
_or_ optimise it in a language you’re already using, or is semi-common in your stack already, and then move on with things.
Re: Recent adventures in performance optimization with Rust
#53Earlier quoted context omitted.
Intentional or not, it does come off as kind of “disruptive” in the negative sense of the word, ie “you’re all doing it wrong in field X. Let me show you how to work faster”. But in a real scenario there are often so many other constraints that “optimized code” is far from the top. Salaries are also expensive, so if you factor in the lifetime cost of writing and maintaining a bit of exotic Rust for an exotic problem,…
i agree that in typical business situations often the main constraints to solve for aren't squeezing the most compute out of a CPU, it's rarely the bottleneck (although of course some people can no doubt chime in from contexts where compute is frequently the bottleneck and what they spend most of their time fretting about). good engineering should figure out what the main constraints are, and solve for those, while d…
> but, this article isn't a "how to make good whole-system engineering tradeoffs for the long-term benefit or your employer / client" article, it's an article showing how to write fast rust code.
As you can probably tell from my sentiment above, it doesn’t help the author’s cause by basing the premise on a strawman. If the intention was to push Rust for Python users, this article shoots far, really far, but completely misses the mark. Nobody was telling themselves that Python was the fastest language out there.
Re: Recent adventures in performance optimization with Rust
#54Comparing 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 k…
I very much disagree with your assessment. I will agree that the title is extremely clickbaity, but the author goes into how the move from Python to Rust only accounts for a .8 increase, which is impressive but we all know Python isn’t performant so. Aside from the clickbait title I think the article is extremely interesting and rather relevant, as it takes you through the craze or optimising Rust code.
I guess you could make a point out of how the author didn’t need to bring Python into the article, but on the flip side, they clearly state that they typically prototype in Python. So it would also be an incomplete article if they left out the initial implementation for the problem they are solving.
Re: Recent adventures in performance optimization with Rust
#55Basically "Analyzing Data 180,000x Faster with AOT strongly typed compiled language" versus using a dynamically typed interpreted one.
"interpreted language" and "compiled language" are category errors.
True, but since the same example can't be done with a Rust based bytecode interpreter, or a Python AOT compiler, due to lack of implementations to use for benchmarking purposes, the remark remains valid.
Re: Recent adventures in performance optimization with Rust
#56I like it how he demonstrates the thought process. It seems quite a mechanical recipe that can be applied to a lot of similar problems:
Step 1:. A slow but easy implementation. It allows to make sure the algorithm is correct, and later allows validating the faster variants.
Step 2: Algorithm and datastructure optimization, guided by profiling.
Step 3: Micro optimization, again guided by profiling. A standard bag of tricks is applied. I didn't see cache friendlyness/tiling in here, which surprised me.
Step 4: Parallelism, first by SIMD then by threads.
I am very much not downing the author: This is a great teaching of the process, it's a lot of hard brainy work, and we didn't see everything he tried but which failed. So thank you, author.
My point is: it is not magic. It is engineering. It is a skill that can be aquired, thought, even planned and measured.
Re: Recent adventures in performance optimization with Rust
#57Moore's law is dead, that means developers who will not waste CPU cycles will be in demand for the next generation of compute intensive development. Big Data needs big compute so obviously these kinds of articles are not only pertinent but is the way ahead. I would not be surprised if we do rewrites of all the past 20 year code in to Rust or Go or any other performant language. Lets agree on this, you are smart and t…
I’m not sure why you’re being downvoted, even if you’re aren’t correct about the law we’re seeing rising costs of cloud computing. We’ve cut our Azure cloud spending almost in half by being more efficient and rewriting core computing elements in performant languages. We’ve gone with C++ because that’s also what we use for our embedded solar plant programming but we did make a few proof of concepts using Rust and liked what we learned. I think we’ll eventually begin to move more or our C/C++ into Rust as Rust matures, but we’re also not in a rush to do so.
But to get back to what you’re talking about here, we recently spoke with Lunar about their transition from a Node backend to a Java backend and then finally to a Go backend and how they can’t imagine building anything without Go going forward. Very interesting considering that the JVM is quite performant itself. I’m not sure we’re going to follow them down the Go rabbit hole, I think we’ll remain on a Node backend for non-performant stuff since it lets us use one language for most things. But I do think your predictions are right.
Re: Recent adventures in performance optimization with Rust
#58It'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.
Much speed up was from using the right data structure for the task, e.g. Vec rather than HashMap and BitSet rather than HashSet.
Re: Recent adventures in performance optimization with Rust
#59Basically "Analyzing Data 180,000x Faster with AOT strongly typed compiled language" versus using a dynamically typed interpreted one.
The difference between baseline Python and baseline Rust is only 8x here, because most of the heavy lifting in the Python version is done by native code.
Re: Recent adventures in performance optimization with Rust
#60Moore's law is dead, that means developers who will not waste CPU cycles will be in demand for the next generation of compute intensive development. Big Data needs big compute so obviously these kinds of articles are not only pertinent but is the way ahead. I would not be surprised if we do rewrites of all the past 20 year code in to Rust or Go or any other performant language. Lets agree on this, you are smart and t…
I’m not sure why you’re being downvoted, even if you’re aren’t correct about the law we’re seeing rising costs of cloud computing. We’ve cut our Azure cloud spending almost in half by being more efficient and rewriting core computing elements in performant languages. We’ve gone with C++ because that’s also what we use for our embedded solar plant programming but we did make a few proof of concepts using Rust and like…
Thanks for your kind words.