Read Rust - Performance

Reducing code size in librsvg by removing an unnecessary generic struct

Federico Mena Quintero — Tue, 28 Feb 2023 04:41:39 +0000

Someone mentioned cargo-bloat the other day and it reminded me that I have been wanting to measure the code size for generic functions in librsvg, and see if there are improvements to be made.

Dramatically reducing AccessKit’s memory usage

Matt Campbell — Thu, 9 Feb 2023 23:06:10 +0000

In our recent status update, we called out the use of a single large data structure for all accessible UI elements as a known potential weakness in the design. After that post, feedback from potential users of AccessKit made it clear that this design flaw was a pressing problem that blocked them from using AccessKit. One of these discussions also led us to a particularly attractive technique for solving the problem. So we decided to go ahead and do this optimization work, to unblock further adoption of AccessKit and get the inevitable incompatible API changes out of the way sooner rather than later. This post summarizes the results of this optimization, explains how we did it, and looks ahead to further potential optimizations.

Speeding up Rust semver-checking by over 2000x

Predrag Gruevski — Tue, 7 Feb 2023 23:13:25 +0000

This post describes work in progress: how cargo-semver-checks will benefit from the upcoming query optimization API in the Trustfall query engine. Read on to learn how a modern linter works under the hood, and how ideas from the world of databases can improve its performance.

The size of Rust Futures

Arpad Borsos — Sun, 29 Jan 2023 22:15:21 +0000

I have recently discovered that Rust Futures, or rather, async fn calls can lead to surprising performance problems if they are nested too deeply.

Apart from highlighting the source of the problem in great depth, I also want to propose some workarounds for this specific issue.

Testing SIMD instructions on ARM with Rust on Android

Guillaume Endignoux — Thu, 19 Jan 2023 23:23:17 +0000

This blog post is the last one of a series exploring SIMD support with Rust on Android. In the previous two posts, I introduced how to compile Rust libraries for Android and detect SIMD instructions supported by the CPU at runtime.

Today, we’ll see how to effectively use the SIMD instructions themselves, and get the most performance out of them. After an introduction on running Rust benchmarks (and unit tests) on Android devices, we’ll measure the performance in various scenarios offered by Rust, and see that the overhead of CPU feature detection can be non-trivial. I’ll then describe various ways to reduce this overhead.

Lastly, I’ll present updated benchmarks on ARM of Horcrux, my Rust implementation of Shamir’s Secret Sharing, and see how they compare to Intel.

Is coding in Rust as bad as in C++?

strager — Sat, 7 Jan 2023 04:33:31 +0000

C++ is notorious for its slow build times. “My code's compiling” is a meme in the programming world, and C++ keeps this joke alive.

I've heard the same thing about Rust: build times are a huge problem. But is it really a problem in Rust, or is this anti-Rust propaganda? How does it compare to C++'s build time problem?

How much does Rust's bounds checking actually cost?

Griffin Smith — Wed, 30 Nov 2022 23:12:51 +0000

Rust prevents out-of-bounds memory accesses and buffer overruns via runtime bounds checks - what’s the cost of those bounds checks for a real-world, production application?

Safely writing code that isn't thread-safe

Cliff L. Biffle — Fri, 25 Nov 2022 00:09:03 +0000

One of the nice things about the Rust programming language is that it makes it easier to write correct concurrent (e.g. threaded) programs – to the degree that Rust’s slogan has been, at times, “fearless concurrency.”

But I’d like to tell you about the other side of Rust, which I think is under-appreciated. Rust enables you to write programs that are not concurrent. This feature is missing from most other languages, and is a source of much complexity and bugs.

Rustdoc performance improvements

Joshua Nelson and Guillaume Gomez — Thu, 21 Jan 2021 07:03:57 +0000

Hi everyone! @GuillaumeGomez recently tweeted about the rustdoc performance improvements and suggested that we write a blog post about it:

> The performance comparison between @rustlang rustdoc now and rustdoc 4 months ago are crazy! The rustdoc cleanup going on (we're still far from done!) is having a huge positive impact! Can't wait to see how much better the results will be. Maybe I should write a blog post? pic.twitter.com/XapdmdZ1IZ — Guillaume Gomez (@imperioworld_) January 13, 2021

The tweet received a lot of comments approving the blog post idea so here we go!

Exploring PGO for the Rust compiler

Michael Woerister — Wed, 11 Nov 2020 22:03:44 +0000

For the last few months Mozilla has been using Profile-Guided Optimization (PGO) to build their own optimized version of Clang, leading to an up to 9% reduction of Firefox compile times on their build infrastructure. Would the same be possible for the Rust compiler, that is, could we apply profile-guided optimization to rustc itself in order to make it faster? This post explores exactly this question, detailing first the steps needed for generating a PGOed versions of rustc (in two flavors), and then taking a look at the resulting performance implications. But before that let's have a little reminder what PGO even is and how it works in general.

Introducing Scipio - a Thread-per-Core Crate for Rust & Linux

Glauber Costa — Wed, 4 Nov 2020 23:52:51 +0000

This article will explore the thread-per-core model with its advantages and challenges, and introduce Scipio (you can also find it on crates.io), our solution to this problem. Scipio allows Rust developers to write thread-per-core applications in an easy and manageable way.

What I Learnt from Benchmarking Http4k, Ktor (Kotlin) and Actix v2, v3 (Rust) Microservices

Matěj Laitl — Mon, 14 Sep 2020 11:04:15 +0000

Back in spring 2020 at GoOut, we were looking to replace our Spring-Tomcat duo by a more lightweight framework to power our future Kotlin microservices. We did some detailed (at times philosophical) theoretical comparisons that I much enjoyed, but these cannot substitute a hands-on experience. We decided to implement proof-of-concept microservices using the most viable frameworks, stressing them in a benchmark along the way. While Kotlin was the main language, I saw this as an opportunity to have some fun at home and test (my proficiency with) Rust, which is touted for being fast. I ended up stress-testing Kotlin’s Http4k, Ktor, and Rust’s Actix Web, read on to see how they fared.

Multiple Thread Pools in Rust

Piotr Kołaczkowski — Sat, 29 Aug 2020 10:57:38 +0000

In the previous post, I showed how processing file data in parallel can either boost or hurt performance depending on the workload and device capabilities. Therefore, in complex programs that mix tasks of different types using different physical resources, e.g. CPU, storage (e.g. HDD/SSD) or network I/O, a need may arise to configure parallelism levels differently for each task type. This is typically solved by scheduling tasks of different types on dedicated thread pools. In this post I’m showing how to implement a solution in Rust with Rayon.

Profiling Doesn't Always Have To Be Fancy

Ryan James Spencer — Mon, 24 Aug 2020 09:59:15 +0000

Not all profiling experiences are alike. Some are filled with friction around the tooling. Others are around doubt about whether or not intermediate layers are inflating or shifting numbers in unfair ways. Perhaps you work in a security or data-compliance critical environment and all you want is numbers on what is running in production without having to breach agreements by downloading live data to your work environment. Benchmarks are fantastic for tracking numbers of common or pathological cases over time, but they may still be unrealistic in comparison to the undiscovered cases in prod. When I find that I can't easily wedge in a profile, I get a bit sad and then turn to crude solutions.

As above, so below: Bare metal Rust generics 1/2

Pablo Mansanet — Mon, 24 Aug 2020 09:41:03 +0000

I've had the pleasure to work with very experienced firmware developers; the kind of people who know the size of their red zones and routinely transform coffee into linker scripts and pointer dereferences. In other words, the Mels and Zeus Hammers of the world.

When it comes to the tools of our trade, many of them are curious and experimental. Some of them—very much myself included—explore far enough to leave pragmatism behind and veer into idealism, stubbornly forcing beautiful round pegs into industrial square holes. Hey, maybe they're square for a reason, but it doesn't hurt to try.

The majority of them aren't like that. Your average battle-tested firmware developer has accrued a healthy distrust of the abstract, probably born of watching shiny platonic constructs crash and burn with painfully real and concrete error traces. It is sobering, having to chase a hardfault on a tiny MCU across enough vtables and templated code to make Herb Sutter puke angle brackets. No wonder modern approaches are met with some resistance unless the LOADs and the STOREs are in clear view.

I felt this way too when someone suggested to me, back in 2014, that an up-and-coming language called Rust showed promise in the embedded field. Surely not, I thought, too high level. Even though I had been playing with it already, my profoundly ingrained bit-twiddling instincts told me not to trust a language that supported functional programming, or one that dared to have an opinion on how I managed my memory. Bah! That's how you get philosophers to run out of forks, and your forks to turn into SIGSEGVs.

I was wrong.

The Rust compiler isn't slow; we are

Jay Oster — Thu, 13 Aug 2020 09:52:14 +0000

This might be a bit of an unpopular opinion, so the clickbait title should be appropriate!

I've been learning and using Rust for nearly four and a half years, since version 1.6. That's a good amount of time to become familiar with some of the troubles of the language, the tooling, and the ecosystem. But this is a slightly different story, this is a dissent to a common criticism that the compiler is slow. In this discussion, I will argue that these claims are misleading at best.

How Rust Lets Us Monitor 30k API calls/min

Cédric Fabianski — Thu, 13 Aug 2020 09:48:03 +0000

At Bearer, we are a polyglot engineering team. Both in spoken languages and programming languages. Our stack is made up of services written in Node.js, Ruby, Elixir, and a handful of others in addition to all the languages our agent library supports. Like most teams, we balance using the right tool for the job with using the right tool for the time. Recently, we reached a limitation in one of our services that led us to transition that service from Node.js to Rust. This post goes into some of the details that caused the need to change languages, as well as some of the decisions we made along the way.

sled theoretical performance guide

Tyler Neely — Tue, 11 Aug 2020 10:36:56 +0000

This guide covers timeless ideas that are helpful to keep in mind while working with systems where performance matters. Many of these ideas are fairly “durable” and will apply regardless of what hardware, programming language, operating system, or decade you are working in.

Stay tuned for follow-up articles that will drill into hardware and more Rust-specific techniques.

What Is The Minimal Set Of Optimizations Needed For Zero-Cost Abstraction?

Robert O'Callahan — Mon, 10 Aug 2020 10:33:50 +0000

A compelling feature of Rust and C++ is "zero-cost abstractions". You can write "high level" code, e.g. using iterators, that compiles down to the same machine code as the low-level code that you'd write by hand. You can add layers of abstraction, e.g. wrapping a primitive value in a struct and providing a specialized API for it, without adding run-time overhead. However, "zero-cost" only applies if you enable an adequate set of compiler optimizations. Unfortunately, enabling those optimizations slows down compilation and, with current compilers, trashes a lot of debug information, making it very difficult to debug with those binaries. Since the Rust standard library (and increasingly the C++ standard library) makes heavy use of "zero-cost" abstractions, using non-optimized builds for the sake of better debugging and build times creates binaries that are many times slower than release builds, often untenably slow. So the question is: how can we get fast builds and quality debuginfo while keeping zero-cost abstractions?

Parallel stream processing with Rayon

Hrvoje — Thu, 6 Aug 2020 10:11:26 +0000

Most Rust programmers have heard of Rayon, a crate that makes it almost magically easy to introduce parallelism to a program. In this article we’ll examine how to apply Rayon to basic stream processing.

How to speed up the Rust compiler some more in 2020

Nicholas Nethercote — Wed, 5 Aug 2020 03:48:41 +0000

I last wrote in April about my work on speeding up the Rust compiler. Time for another update.
Weekly performance triage

First up is a process change: I have started doing weekly performance triage. Each Tuesday I have been looking at the performance results of all the PRs merged in the past week. For each PR that has regressed or improved performance by a non-negligible amount, I add a comment to the PR with a link to the measurements. I also gather these results into a weekly report, which is mentioned in This Week in Rust, and also looked at in the weekly compiler team meeting.

The goal of this is to ensure that regressions are caught quickly and appropriate action is taken, and to raise awareness of performance issues in general.

Performance Comparison: Rust vs PyO3 vs Python

Marshal SHI — Mon, 27 Jul 2020 09:33:15 +0000

Rust can be used to speed up Python code, but how fast can it be? This article highlights the comparison between the performance of: Rust, PyO3, and Python3, and an easy way to setup PyO3.

An introduction to Data Oriented Design with Rust

James McMurray — Mon, 27 Jul 2020 09:29:16 +0000

Data-oriented design is an approach to optimising programs by carefully considering the memory layout of data structures, and their implications for auto-vectorisation and use of the CPU cache. I highly recommend watching Mike Acton’s “Data-Oriented Design and C++” talk if you haven’t seen it already.

In this post we will cover 4 cases, using criterion for benchmarking.

Rewriting FORTRAN Software In Rust

Ferdia McKeogh — Thu, 16 Jul 2020 02:06:11 +0000

As part of an Undergraduate Research Assistant Scheme in my first year of university I was tasked with parallelising a piece of shallow water simulation software written in FORTRAN by Dr David Dritschel of the Vortex Dynamics Research Group, under supervision of Dr. Alexander Konovalov, at the University of St Andrews. There were secondary goals such as improving the testing infrastructure, setting up CI/CD, estimating progress and allowing the computation to be paused and resumed.

Forewarning: I have essentially zero domain knowledge in this project (and fluid dynamics simulation isn’t exactly the kind of topic you can catch up to research level on over a weekend) so I approached this project from a purely software engineering perspective. As for my Rust experience, I’ve been using it for personal projects since ~2016 and I worked as a Rust software engineer at a startup in Berlin for a year after leaving high school.

Building and debugging a high-throughput daemon in Rust

R. Tyler Croy — Wed, 15 Jul 2020 22:51:16 +0000

The async/await keywords in modern Rust make building high-throughput daemons pretty straightforward, but as I learned that doesn’t necessarily mean “easy.” Last month on the Scribd tech blog wrote about a daemon named hotdog which we deployed into production: Ingesting production logs with Rust. In this post, I would like to write about some of the technical challenges I encountered getting the performance tuned for this async-std based Rust application.

nnnoiseless: porting audio code from C to rust

Joe Neeman — Mon, 13 Jul 2020 13:06:42 +0000

I ported a C library to rust last week, and it went pretty smoothly. The library in question is RNNoise, a library for removing noise from audio. It works well, it runs fast, and best of all it has no knobs that you need to tune. There’s even a rust
binding.

Faster Integer Parsing

Ivan Tham — Sun, 12 Jul 2020 23:54:57 +0000

If you had to parse a microsecond-resolution epoch timestamp as quickly as possible, how would you do it? We’ll take a look at using compiler intrinsics to do it in log(n) time.

Target Feature vs Target CPU for Rust

Nick Wilcox — Sat, 11 Jul 2020 22:57:30 +0000

In the previous article on auto-vectorization we looked at the different SIMD instruction set families on X86-64. We saw how he target-feature compiler flag and #[target_feature()] attribute gave us more control over the instructions used in the generated assembly.

There is a related compiler flag target-cpu we didn’t touch on, so it’s worth taking a look at how it affects the generated code.

Simd By Cheating

Michal Vaner — Thu, 9 Jul 2020 07:45:05 +0000

Since the last post about SIMD library plans, I’ve been experimenting. Needless to say, it turned out a bit different than originally planned, but I’ve something I’d like to share. Maybe it’ll be useful for someone or maybe it’ll at least spark some more progress in the area.

If you don’t care about the chatter and just want to use it, it’s called slipstream and is available on crates.io. It’s an early release and will need some more work, but it can be experimented with (it has documentation and probably won’t eat any kittens when used). If you want to help out, scroll down to see what needs help (or decide on your own what part needs improving 😇).

Faster Rust development on AWS EC2 with VSCode

Max — Sat, 27 Jun 2020 10:28:13 +0000

I dread running cargo build --release.

It's not that I dread build failures or compiler warnings - I dread the wait.

My current Rust project takes about a minute to build on my laptop. It's not long enough to do something meaningful, like read HackerNews, but is long enough to make it feel agonizingly boring. If I don't have the money for a faster laptop, maybe I could build a really fast Rust development server on AWS?

Tips for Faster Rust Compile Times

Matthias Endler — Tue, 23 Jun 2020 21:58:46 +0000

When it comes to runtime performance, Rust is one of the fastest guns in the west. It is on par with the likes of C and C++ and sometimes even surpasses them. Compile times, however? That's a different story.

Efficiently escaping strings using Cow in Rust

Sam Rowe — Fri, 12 Jun 2020 01:51:00 +0000

This is a handy pattern to use for efficiently escaping text, and it's also a good demonstration of Rust's Cow 🐄 type.

Rust Disassambly: part 1

Marco Giordano — Sun, 31 May 2020 00:58:14 +0000

What do some Rust features compile to? I have been starting to have a look at Rust lately, mostly because WASM is growing on me and Rust has the best tool in class for it, or so I am told. I am eager to find out by myself. Rust comes with several new idioms and structures in the language I am not used to, and being a performance enthusiast, I always get interested in what such constructs translate to.

Auto-Vectorization for Newer Instruction Sets in Rust

Nick Wilcox — Sun, 31 May 2020 00:19:01 +0000

In the previous article on auto-vectorization we treated instructions as either SIMD (Single Instruction Multiple Data) or non-SIMD. We also assumed that SIMD meant four values at a time.

That was true for way we wrote and compiled our code in that article, but we're going to expand beyond that. There is a progression of SIMD instruction families, with new releases of CPU's from Intel and AMD supporting new instructions we can use to increase the performance of our code.

If our goal is to get the best performance we need to take advantage of all the possible SIMD instructions on our hardware.

In this article we're going to:

* Look at the compiler output when targeting the different SIMD instruction set families.
* Benchmark the different instruction sets.
* Look at how we can structure our Rust code to support compiling for multiple instruction sets and then selecting at runtime the one to use.

Taking Advantage of Auto-Vectorization in Rust

Nick Wilcox — Thu, 21 May 2020 22:14:46 +0000

Recently on a project I wrote some audio processing code in Rust. In the past I've used C++ to write audio processing code for situations where performance was critical. I wanted to take that C++ optimisation experience and see what is possible using Rust.
We're going to take one small piece of audio processing code and take a look at how we can optimize it in Rust. Along the way we're going to learn about optimisation using Single Instruction Multiple Data CPU instructions, how to quickly check the assembler output of the compiler, and simple changes we can make to our Rust code to produce faster programs.

Rust: Dropping heavy things in another thread can make your code 10000 times faster

Aaron Abramov — Thu, 21 May 2020 22:07:02 +0000

When working on Rust applications or CLIs that need to show something to the end user as fast as possible I often find that a significant chunk of the time is usually spent not in doing any computations, but in dropping large data structures at the end of the function.

Reducing the size of a Rust GStreamer plugin

Guillaume Desmottes — Fri, 1 May 2020 01:54:43 +0000

A common complaint heard about Rust is the size of the binary it produces. They are various reasons explaining why Rust binaries are generally bigger that ones produced with lower level languages such as C. The main one is Cargo, Rust's package manager and building tool, producing static binaries by default. While larger binaries are generally not much of an issue for desktop or server applications, it may become more of a problem on embedded systems where storage and/or memory may be very limited.

GStreamer is used extensively at Collabora to help our clients to build embedded multimedia solutions. With Rust gaining traction among the GStreamer community as an alternative to C to write GStreamer applications and plugins, we began wondering if the size of such Rust plugins would be a problem for embedded systems, and what could be done to reduce sizes as much as possible.

Inspired by this Tiny Rocket analysis and the Minimizing Rust Binary Size repository, here are the different strategies we tried to reduce the size of a minimal Rust GStreamer plugin.

How to speed up the Rust compiler in 2020

Nicholas Nethercote — Mon, 27 Apr 2020 10:59:22 +0000

I last wrote in December 2019 about my work on speeding up the Rust compiler. Time for another update.

Better stack fixing for Firefox

Nicholas Nethercote — Wed, 15 Apr 2020 22:13:17 +0000

I recently undertook a project to improve the stack fixing tools used for Firefox. This has resulted in some large performance wins (e.g. 10x-100x) and a significant improvement in code quality. The story involves Rust, Python, executable and debug info formats, Taskcluster, and many unexpected complications.

Measuring build timings with mathbench

Cameron Hart — Mon, 13 Apr 2020 22:17:06 +0000

Fast iteration times are something that many game developers consider to be of utmost importance. Keeping build times short is a major component of quick iteration for a programmer. Aside from the actual time spent compiling, any time you have to wait long enough that you start to lose focus on the activity you are working on, or you start to get distracted or lose track of what you were doing which costs you more time.

Thus one of my goals when writing glam was to ensure it was fast to compile. Rust compile times are known to be a bit slow compared to many other languages, and I didn’t want to pour fuel on to that particular fire.

As part of writing glam I also wrote mathbench so I could compare performance with similar libraries. I also always wanted to include build time comparisons as part of mathbench and I’ve finally got around to doing that with a new tool called buildbench.

SIMD Array-of-Structures-of-Arrays in nalgebra and comparison with ultraviolet

Sébastien Crozet — Wed, 1 Apr 2020 06:51:14 +0000

In this post I'd like to introduce the next major change that will be released in nalgebra at the end of this month (March 2020). This change is about adding the support for SIMD AoSoA to nalgebra. I'll explain what I mean by SIMD AoSoA (Array-of-Structures-of-Arrays with explicit SIMD) and how it relates to SoA (Structure-of-Arrays) and AoS (Array-of-Structures). To give you an idea, SIMD AoSoA is actually what the recent ultraviolet crate has been using to achieve its amazing performances.

Reducing memory consumption in librsvg, part 4: compact representation for Bézier paths

Federico Mena Quintero — Mon, 30 Mar 2020 23:46:49 +0000

Let's continue with the enormous SVG from the last time, a map extracted from OpenStreetMap. According to Massif, peak memory consumption for that file occurs at the following point during the execution of rsvg-convert.

pa'i Benchmarks

Christine Dodrill — Fri, 27 Mar 2020 01:43:01 +0000

In my last post I mentioned that pa’i was faster than Olin’s cwa binary written in go without giving any benchmarks. I’ve been working on new ways to gather and visualize these benchmarks, and here they are.

Benchmarking WebAssembly implementations is slightly hard. A lot of existing benchmark tools simply do not run in WebAssembly as is, not to mention inside the Olin ABI. However, I have created a few tasks that I feel represent common tasks that pa’i (and later wasmcloud).

Quickly Find Rust Program Bottlenecks Online Using a Go Tool

Ke'ao Yang — Thu, 26 Mar 2020 06:31:13 +0000

To collect profiling statistics for Rust programs like TiKV, we developed pprof-rs, which samples, analyzes, and visualizes performance data in one step. We integrated pprof-rs in TiKV's status_server, which outputs monitoring information.

Because pprof-rs uses the same data format as the Go tool pprof, we can use pprof, to visualize TiKV's profiling data. This makes it easier for developers and online users to find TiKV's performance bottlenecks.

Reducing memory consumption in librsvg, part 3: slack space in Bézier paths

Federico Mena Quintero — Wed, 25 Mar 2020 12:08:36 +0000

We got a bug with a gigantic SVG of a map extracted from OpenStreetMap, and it has about 600,000 elements. Most of them are , that is, specifications for Bézier paths.

Reducing memory consumption in librsvg, part 2: SpecifiedValues

Federico Mena Quintero — Fri, 20 Mar 2020 22:00:00 +0000

To continue with last time's topic, let's see how to make librsvg's DOM nodes smaller in memory. Since that time, there have been some changes to the code; that is why in this post some of the type names are different from last time's.

Building Mender-Rust in Yocto, and minimizing the binary size

Ole — Tue, 17 Mar 2020 10:34:59 +0000

In this post we are going to explore how to try and create an embedded version of the Mender-Rust binary which we created in the project from the previous post in this series. The original goal is to get it below 1 MB, but this sounds a bit ambitious to me. Let us see how we fare in the world of binary minimization.

Optimizations That Aren't, Or Are They?

Ori Ben-Shir — Sun, 15 Mar 2020 10:49:37 +0000

A few years back, I read a quite unique blog about C++. It was actually one of the first times I was exposed to the concept of technical blogs. And with it the whole concept of learning software development outside the education system (e.g., the good old courses, exercises and sitting in a class being taught by a teacher). It is, to the date, one of my favorite blog posts and a cornerstone in my desire to write my own blog.

The blog was written by Herb Sutter, more than 20 years ago, and you can find it here. Before discussing the blog and why it is still relevant, more than 20 years later, we need some background. It describes an optimization known as Copy-On-Write, abbreviated as COW. I’m going to cover this optimization both in Rust and C++.

Reducing memory consumption in librsvg, part 1: text nodes

Federico Mena Quintero — Fri, 13 Mar 2020 22:56:32 +0000

Librsvg's memory consumption has not been a problem so far for GNOME's use cases, which is basically rendering icons. But for SVG files with thousands of elements, it could do a lot better.

Cheap tricks for high-performance Rust

Pascal Hertleif — Thu, 5 Mar 2020 22:04:09 +0000

So you’re writing Rust but it’s not fast enough? Even though you’re using cargo build --release? Here’s some small things you can do to increase the runtime speed of a Rust project – practically without changing any code!

Please remember that the following suggestions do not replace actual profiling and optimizations! I also think it goes without saying that the only way to detect if any of this helps is having benchmarks that represent how your application behaves under real usage.

The Cost of Indirection

Josh Mcguigan — Wed, 4 Mar 2020 07:02:16 +0000

Providing zero cost abstractions is a goal of the Rust programming language. In this post we’ll explore the performance costs of various methods of indirection.

Multithreaded Rust on Threadripper

Heinz N. Gies — Wed, 4 Mar 2020 06:46:25 +0000

I recently ran some benchmarks on a Threadripper 3960X system and the results were surprising me quite a bit. Simplified, the throughput the benchmark recorded went down, from 341 MB/s on a MBP to 136 MB/s on a Threadripper desktop. Prior I had read Daniel Lemire's notes on the sub optimal performance for simdjson on Zen 2, which is heavily used in the benchmark, but the suggested drop were a few percent not half.

ExpressJS vs Actix-Web. It is exactly what you think

Maxim Vorobjov — Wed, 4 Mar 2020 06:45:01 +0000

The goal of this analysis is to try to understand what kind of gains a programmer should expect by using Rust and actix-web rather than Node and Express under typical use, without custom optimizations.

Why is swc fast?

DongYoon Kang — Fri, 28 Feb 2020 23:09:18 +0000

swc is fast. Very fast. It's 18x faster than babel on a single-core benchmark, and on a parallel benchmark, it's 68x faster than babel on a 4 core (8 HT) machine. Why? Just because it's written in rust? No. Its fundamental design differs from any other tool.

Low-overhead Parallelisation in Games Part 2, Allowing Side Effects

Anders Musikka — Wed, 26 Feb 2020 21:34:06 +0000

In Part 1 we looked at quickly doing operations on all items in a vector, using many CPU cores.

In this part we're looking at making it possible to update data in some other vector while traversing the first vector.

This is harder than it looks, since we can't just allow the parallel threads to update the auxiliary vectors. If we do, there will be races, unless we somehow know that different threads won't ever update the same item.

Low-overhead Parallelisation in Games

Anders Musikka — Mon, 17 Feb 2020 10:19:53 +0000

This blog post and git describes my search for a way to parallelize simulation of cars, intersections and roads in a computer game project. I won't be talking anything about the domain, but the problem is something like this:

There are three types of objects: Intersections, Roads, Cars.

Intersections have red lights, and alternately admit cars from different roads into the intersection. When a car arrives at its destination, the car object is updated changing its state from 'on road' to 'idle'.

The gist of it is that calculations are done for each intersection, and for each intersection the calculation may yield an update to a road or a car. There are hundreds of thousands of intersections, about the same number of roads, and a million cars. Calculations need to be quick, so we should run as parallel as possible.

Steps I take when optimizing the Rust compiler

Nicholas Nethercote — Thu, 13 Feb 2020 08:57:53 +0000

I wrote down some details on the steps I take when optimizing the Rust compiler, using an improvement I just made to LEB128 reading/writing as an example.

Zero-cost abstractions in Rust

Antonin Carette — Mon, 10 Feb 2020 09:38:34 +0000

Last week, Ibrahim Dursun published an article about zero-cost abstractions in Rust.
Unfortunately, except for a subpart of the article, this article did not reflect, in my own opinion, correctly what are zero-cost abstractions.

Indeed, zero-cost abstractions, or “zero-overhead”, can be difficult to understand and to separate from other compiler optimizations, and can be easily misunderstood.

In this blog article, I discuss about this specific feature, and give you an example of how Rust is using it to deliver optimized code of your abstracted projects.

Rust zero cost abstractions in action

Ibrahim Dursun — Mon, 10 Feb 2020 09:25:27 +0000

One of my colleagues was experimenting with Rust. He started by writing a sudoku solver which he has already written in C before. Once he was completed writing it in Rust, he was very disappointed because Rust version was twice as fast than the C version which was hand-optimised by pulling off all the tricks he knew to make it perform well. He eventually managed to make the C version as fast as the Rust version by removing the intrinsics.

This piqued my interest in looking into what kind of assembly code is being generated in the final binary.

Rust memory optimization

Amit Patel — Mon, 10 Feb 2020 09:24:32 +0000

One of my goals this year is to learn new things that take more than a few weeks to learn. I've been learning Rust. One of the claims I saw is that Rust's borrow mechanics allow it to optimize better than C++ does. I wanted to see this in action so I ran some simple examples through godbolt.

How I sped up my Rust program: From 30+ minutes to a few seconds

Niklas Büchner — Wed, 5 Feb 2020 08:59:17 +0000

Ever since 2017 I have been writing my hobby projects in Rust. It’s not only the language which I fell in love with but also its speed. ❤️ Rust is known for its amazing speed. But, just because the language is fast does not mean all you apps will be as well. Here is my journey of how I sped up a program from running for over half an hour to only a few seconds.

Export Rust functions to Java using JNI (WebAssembly comparison)

Vegapit — Wed, 5 Feb 2020 08:45:26 +0000

In a previous post, we saw how Rust WebAssembly can be integrated into a JavaFX project using the Asmble tool. Here we look at an integration of the same functionality using the Java Native Interface (JNI). Finally, we compare the two approaches in terms of convenience and performance.

500K pps with tokio

Marco Amann — Wed, 5 Feb 2020 08:32:03 +0000

After reading the Cloudflare blog post on how to receive 1M packets per second, I wondered: How fast can we go with Rust and Tokio?

Why Discord is switching from Go to Rust

Jesse Howarth — Tue, 4 Feb 2020 21:11:02 +0000

Rust is becoming a first class language in a variety of domains. At Discord, we’ve seen success with Rust on the client side and server side. For example, we use it on the client side for our video encoding pipeline for Go Live and on the server side for Elixir NIFs. Most recently, we drastically improved the performance of a service by switching its implementation from Go to Rust. This post explains why it made sense for us to reimplement the service, how it was done, and the resulting performance improvements.

Optimizing loop heavy Rust code

Ilia Schelokov — Tue, 28 Jan 2020 08:59:22 +0000

Some time ago I had a fuzzy string matching problem to solve. I started looking for a performant Damerau-Levenshtein crate, and ended up writing my own collection of optimized edit distance algorithms, Eddie. In this post, using the lessons I've learned along the way and the Levenshtein algorithm as an example, I'll build upon a basic implementation step by step, and measure the results.

How To Write Fast Rust Code

Christopher Sebastian — Sun, 19 Jan 2020 07:32:55 +0000

I did a line-for-line port of my eval library from Go to Rust, and right away it was 5x faster; I was pretty happy. But when I tried to further improve performance using techniques from other languages, it got slower... and the harder I tried, the slower it got! Rust performance was not intuitive to me.

Finally, after learning why my code was slow, I was able to boost performance 12000x, and my library was worthy of a new name: fasteval.

Blocking Permit

David Kellum — Fri, 17 Jan 2020 08:29:42 +0000

No one ever gets in trouble for posting micro benchmarks and making broad assumptions about the cause of observed results! This post will focus on a couple of such benchmarks pertaining to blocking operations on otherwise asynchronous runtimes. Along the way I’ll give only sparse background on these projects I’ve been working on, but plenty of links if you are interested in reading further. This blog post is sort of a followup to an URLO post: Futures 0.3, async♯await experience snapshot, and I’ll cross-post this one to URLO as well.

Profiling and Benchmarking

Luca Barbato — Wed, 8 Jan 2020 10:33:27 +0000

For the 0.2.0 release I was focusing on making rav1e faster. Luca Bruno asked me to give more context, this is the belated start of a set of blogposts about optimizing rust code.

Let The Compiler Do The Work

Cliff L. Biffle — Mon, 6 Jan 2020 10:31:33 +0000

In this series so far, we've taken a C program and converted it into a faster, smaller, and reasonably robust Rust program. The Rust program is a recognizable descendant of the C program, and that was deliberate: my goal was to compare and contrast the two languages for optimized code.

In this bonus section, I'll walk through how we'd write the program from scratch in Rust. In particular, I'm going to rely on compiler auto-vectorization to produce a program that is shorter, simpler, portable, and significantly faster... and without any unsafe.

Can it be?

Mutexes Are Faster Than Spinlocks

Aleksey Kladov — Sun, 5 Jan 2020 00:31:12 +0000

(at least on commodity desktop Linux with stock settings)

This is a followup to the previous post about spinlocks. The gist of the previous post was that spinlocks has some pretty bad worst-case behaviors, and, for that reason, one shouldn’t blindly use a spinlock if using a real mutex or avoiding blocking altogether is cumbersome.

In the comments, I was pointed to this interesting article, which made me realize that there’s another misconception, "For short critical sections, spinlocks perform better".

Until today, I haven’t benchmarked any mutexes, so I don’t know for sure. However, what I know in theory about mutexes and spinlocks makes me doubt this claim, so let’s find out.

Spinlocks Considered Harmful

Aleksey Kladov — Thu, 2 Jan 2020 07:05:33 +0000

In this post, I will be expressing strong opinions about a topic I have relatively little practical experience with, so feel free to roast and educate me in comments (link at the end of the post) :-)

Specifically, I’ll talk about:

- spinlocks,
- spinlocks in Rust with #[no_std],
- priority inversion,
- CPU interrupts,
- and a couple of neat/horrible systemsy Rust hacks.

Writing a seqlock in Rust

Paul Dicker — Sat, 28 Dec 2019 00:47:09 +0000

A seqlock — or “sequence lock” — is an optimized implementation of a reader-writer lock. In a seqlock “the data can be ‘protected’ by a sequence number. The sequence number starts at zero, and is incremented before and after writing the object. Each reader checks the sequence number before and after reading. If both values are the same and even, then there cannot have been any concurrent increments, and the reader must have seen consistent data.”

Let’s start with a skeleton of the implementation. This version has multiple problems and room for improvements, which we are going to explore next.

rav1e 0.2.0

Luca Barbato — Thu, 26 Dec 2019 07:37:54 +0000

The second official release of rav1e was focused mainly on speed. Later I'll write down what we used and what, in my opinion, are the best practices when you have to optimize a codebase like this one.

Client-side Observations about Web Service Technologies: Using Apache Bench

Venkatesh-Prasad Ranganath — Mon, 23 Dec 2019 22:33:26 +0000

This is the third post in a series of posts exploring web services related technologies.

With the web service implementations in place, I evaluated them using an off-the-shelf benchmarking tool. This post documents the client-side observations from this evaluation.

Bisecting Rust Compiler Regressions with cargo-bisect-rustc

Santiago Pastorino — Wed, 18 Dec 2019 20:55:16 +0000

Let's say that you've just updated the Rust compiler version and have tried to compile your application and see a failure that wasn't there before. That's likely due to a regression in the compiler. We've just released cargo-bisect-rustc, a tool that makes it super easy to find exactly when the regression happened.

Another reason to have a look at Rust

Aleksei Lunacharskii — Wed, 18 Dec 2019 09:16:27 +0000

This article presents a comparison of HTTP client apps in Node JS and Rust and looks at different aspects of those projects such as CPU and memory metrics, build time and distribution package size.

Make Vim Python plugin 10x faster using Rust

Liu-Cheng Xu — Sat, 14 Dec 2019 07:16:07 +0000

Thanks to PyO3, now writting a Python dynamic module in Rust is trivial and elegant. What you need to learn is the exmple on the README of PyO3 and rewritting the related function in Python to Rust. As a matter of fact, I firstly used rust-cpython, but I ran into some issues on macOS, hence I switched to PyO3 and it works smoothly.

Thanks to stewart/rff, the fzy Rust implementation is already good to go.

What I have to do is to wrap the Rust version fzy and replace the pure Python fzy in vim-clap with the generated Python dynamic module.

I did some tests laster, and found that the optimization result is very satisfying.

From pytest, Rust is 30x faster:

How to speed up the Rust compiler one last time in 2019

Nicholas Nethercote — Wed, 11 Dec 2019 11:28:56 +0000

I last wrote in October about my work on speeding up the Rust compiler. With the year’s end approaching, it’s time for an update.

Tiny Windows executable in Rust

Jani Peltonen — Sat, 7 Dec 2019 22:19:50 +0000

I have recently spent a lot of time writing pixel shaders and given that I have already written a pure Rust mod player I have started to think about trying my hand at writing a 64K intro in Rust.

One of the main challenges in writing a 64K intro is to squeeze all the code and assets into 64K of memory. There are several tiny frameworks written in C++ that set up a Windows app with a modern OpenGL context. I could not find anything similar for Rust so I decided to create the smallest possible bare bones app that does just that.

Taking ML to production with Rust: a 25x speedup

Luca Palmieri — Tue, 3 Dec 2019 10:28:41 +0000

Today the language of choice for Machine Learning is Python (unless your working environment has some unusual constraints). I will take you on a journey. Hopefully, at the end of it, using Rust as a training backend and deployment platform will not look as crazy or confusing as it sounds. (Title aside, there is much more than speed to it)

rav1e and gains on ARM Devices

mindfreeze — Mon, 2 Dec 2019 06:58:00 +0000

It's been a while I have written a blog about the work I am doing lately. So yeah, I have been working on rav1e, the AV1 Encoder written in rust as part of Project Iris. Currently, if we see, there are other Open-Source Encoders available like libaom from Google, SVT-AV1 from Intel and Netflix. Rav1e’s memory footprint makes it a good starting point for new-cases like Software Encoding in ARM devices, Real-time streaming, while libaom and SVT-AV1 are either too slow or resource-intensive. So it would be much easier to make rav1e fast and power-efficient due to the low-complexity functions.

In the end, we are getting around ~12-20% Improvement in Encoding Time and FPS which is the first step making adoption of AV1 to Mobile devices. It is also very important to note that we’ve been using what SIMD code we have rather than proceeding in the order of lowest-hanging fruit. The relative gains would be more impressive if the outstanding functions were optimized first. Our priority was proving the infrastructure for merging, testing and benching on ARM Devices feasible and now it's more realistic.

Tutorial: Profiling Rust applications in Docker with perf

Guillaume Endignoux — Sat, 9 Nov 2019 00:00:00 +0000

With Moore’s law coming to an end, optimizing code to avoid performance pitfalls is becoming more and more useful. To this end, programming languages like Rust are designed to produce fast and memory-efficient programs out-of-the-box. When that is not sufficient, profilers like perf are useful to measure where the code is slow and therefore which algorithms and data structures should be optimized.

Battle of the Serverless — Part 2: AWS Lambda Cold Start Times

Mark Fowler — Thu, 7 Nov 2019 03:15:40 +0000

This experiment continues the work done in our pretend suite of microservices exposed via API Gateway to form an API with a code name of Slipspace in a mock company called STG. Slipspace drives are how the ships in the Halo universe travel so quickly to different sectors of the galaxy through something called Slipstream Space, so thought it was cool for a name requiring awesome warp API speeds.

Comparing parallel Rust and C++

Matias Lindgren — Thu, 7 Nov 2019 00:00:00 +0000

In this tutorial, we will implement a Rust program that attempts to utilize 100% of the theoretical capacity of three relatively modern, mid-range CPUs. We'll use an existing, highly efficient C++ implementation as a reference point to compare how our Rust program is doing. We start with a simple baseline solution of 3 nested for-loops, and keep improving on the baseline solution incrementally, implementing 8 versions in total, until the program is going so fast it can hardly go faster. We'll approach the problem from the point of view of a C++ programmer who already knows how the reference implementation solves the problem, but is interested in an approach using the Rust language.

Always Bump Downwards

Nick Fitzgerald — Fri, 1 Nov 2019 07:00:00 +0000

When writing a bump allocator, always bump downwards. That is, allocate from high addresses, down towards lower addresses by decrementing the bump pointer. Although it is perhaps less natural to think about, it is more efficient than incrementing the bump pointer and allocating from lower addresses up to higher ones.

“Beating C” with 120 Lines of Rust: wc

Martin Mroz — Wed, 30 Oct 2019 07:07:06 +0000

It’s something of a meme lately to see whether your programming language of choice can take on the venerable wc, and what that might look like. The format seems to be: first do it simply, then idiomatically, and finally much faster. Of course, we’re not really “beating C” but rather “tackling a fun interview question in our favorite programming language.” My go-to these days is Rust, and since I’ve fielded the question of whether Rust is “my Haskell,” this all was too much to pass up. Let’s get started.

FastSpark: A New Fast Native Implementation of Spark from Scratch

Raja Sekar — Wed, 23 Oct 2019 02:26:17 +0000

I got a project idea to test the feasibility of implementing Spark in a native language and if feasible, explore how efficient it can be in terms of performance and resource management. I know that Spark is heavily optimized over the years. I didn’t hope for any drastic difference in performance and if some difference is there, it most likely will be in RAM usage. Also, I want it to very general-purpose just like Spark. I decided to use Rust for the implementation.

Where rustc spends its time

Simon Heath — Tue, 22 Oct 2019 13:00:00 +0000

So a couple weeks ago I was a little stung by the quote from This Week In Rust: “Rust compilation is so slow that I can fix the bugs while it still compiles the crates”. On the one hand, I have unfond memories of waiting for a Typescript project to compile, pack (aka link), minify (aka optimize), and so on, over and over, on every change. At least if it had been Rust I’d have been able to fix the bugs while it was doing this. On the other hand, it’s also mostly true: compiling Rust is heckin’ slow. So I’ve decided to dust off a backburner project for a while, and figure out just where rustc spends most of its time.

Rust Big Data Benchmarks

Andy Grove — Sun, 20 Oct 2019 00:00:00 +0000

I have been running benchmarks of aggregate queries against the NYC taxi data set, using Apache Spark (JVM-based) as the baseline, since it is currently a popular tool for distributed compute, and a tool I am familiar with.

Rust and C++ on Floating-point Intensive Code

Reid Atcheson — Sat, 19 Oct 2019 23:59:59 +0000

Since I do a lot of heavy numeric computation in C++ it was tempting for me to see how Rust compares in a shootout. I chose a floating point benchmark to implement in both languages in order to see the performance difference. I give commentary on why the performance is that way, and some potential fixes Rust could implement to close the gap.

Making the Tokio scheduler 10x faster

Carl Lerche — Sun, 13 Oct 2019 00:00:00 +0000

We’ve been hard at work on the next major revision of Tokio, Rust’s asynchronous runtime. Today, a complete rewrite of the scheduler has been submitted as a pull request. The result is huge performance and latency improvements. Some benchmarks saw a 10x speed up! It is always unclear how much these kinds of improvements impact “full stack” use cases, so we’ve also tested how these scheduler improvements impacted use cases like Hyper and Tonic (spoiler: it’s really good).

How to speed up the Rust compiler some more in 2019

Nicholas Nethercote — Thu, 10 Oct 2019 23:01:52 +0000

In July I wrote about my efforts to speed up the Rust compiler in 2019. I also described how the Rust compiler has gotten faster in 2019, with compile time reductions of 20-50% on most benchmarks. Now that Q3 is finished it’s a good time to see how things have changed since then.

Speeding Up Rust Builds: Code-Gen Edition

Ed Page — Thu, 10 Oct 2019 03:30:17 +0000

Lately, there has been talk talk about improving build times, with a focus on reducing bloat like regex breaking out logic into features that can be disabled, cargo-bloat going on a diet, new cargo features to identify slow-to-build dependencies. The area that has been impacting me lately is build.rs. I've been code-generating compile-time hash tables (phf) which has added several dependencies to my build and takes a while.

Visualizing Rust compilation

Nicholas Nethercote — Wed, 9 Oct 2019 23:34:50 +0000

Speeding up the Rust compiler isn’t the only way to make a Rust project build faster. Changing the crate structure of a project can also make a big difference. The good news here is that Eric Huss has implemented an amazing tool for visualizing Rust compilation, which can be used to identify inefficient crate structures in Rust projects.

Dev Time Optimization -- Part 1 (1.9x speedup, 65% less disk usage)

Azriel Hoh — Tue, 8 Oct 2019 00:10:38 +0000

Summary In a 45k LOC / 102-crate workspace, moving tests from member crates into a single workspace_tests crate achieved the following improvements:

Build and test duration in release mode reduced from 23 minutes to 13 minutes . Debug artifact disk usage reduced from 20 G to 7 G (65% reduction, fresh build), or 230 G to 50 G (78% reduction, ongoing development) Background The rate of software development is affected by many limits.

Binary Format Shootout

Bradlee Speice — Sat, 28 Sep 2019 00:00:00 +0000

Cap'n Proto vs. Flatbuffers vs. Simple Binary Encoding

Causal Profiling Rust Code

Llogiq — Wed, 25 Sep 2019 00:00:00 +0000

There’s a new hotness in performance measurements, and it’s called causal profiling. The idea behind it is that you want to measure how a speed up of a certain function would impact the runtime as a whole, which can be very counterintuitive in today’s multi-threaded world.

Of bitpacking, with or without SSE3

Paul Masurel — Fri, 20 Sep 2019 00:00:00 +0000

This blog post might interest three type of readers: people interested in tantivy: You’ll learn how tantivy uses SIMD instructions to decode posting lists, and what happens on platform where the relevant instruction set is not available. rustaceans who would like to hear a good SIMD in rust story. lucene core devs (yeah it is a very select club) who might be interested in a possible (unconfirmed) optimization opportunity.

Closing the gap: cross-language LTO between Rust and C/C++

Michael — Thu, 19 Sep 2019 00:00:00 +0000

Link time optimization (LTO) is LLVM's way of implementing whole-program optimization. Cross-language LTO is a new feature in the Rust compiler that enables LLVM's link time optimization to be performed across a mixed C/C++/Rust codebase.

An unexpected performance regression

David Peter — Mon, 16 Sep 2019 19:16:58 +0000

A short story on how compiler updates can cause unexpected performance regressions.