Today I’ve released Criterion 0.3.4 and Iai 0.1.0. I’m particularly excited by Iai, so read on to find out what I’ve been up to.
Criterion Updates The main new feature in this release is that Criterion.rs now has built-in support for benchmarking async functions.
This feature requires the async feature to be enabled. In addition to this, four other features - async-std, async-tokio, async-smol, and async-futures can be enabled to add support for benchmarking with the respective futures executors.
Welcome back to my series of posts on the recipe-management software I’m building. If you haven’t been following along, you’ll probably want to start at the first post. This isn’t so much a tutorial series like my posts on raytracing, just me writing about whatever’s on my mind as I build out my vision of what a recipe manager should be.
Progress In the last post I finished building the ingredient editor, meaning that I could move on to the recipe editor - probably the most important view in the whole application.
Welcome back to my series of posts on the recipe-management software I’m building. If you haven’t been following along, you’ll probably want to start at the first post. This isn’t so much a tutorial series like my posts on raytracing, just me writing about whatever’s on my mind as I build out my vision of what a recipe manager should be.
Progress In the last post I finished building the ingredient editor itself (at least for now).
Hello! This post will likely be a bit shorter than the last. Today’s topic is a few thoughts about how complex it can be to parse human input, and how that interacts with Druid’s data model.
Progress I think I’m nearly finished tweaking the ingredient editor. I’ve spent the better part of a month on just this one view and that might seem like overkill, but for software like this the user experience is the whole point so it’s important to get it right.
It’s been a couple of weeks since the last post, and as promised I’m back with some progress on the ingredient editor. The last post talked about my goals for this project, technical design decisions based on those goals, and my philosophy on starting challenging projects. This post is more of an experience report from my first few weeks of working with Druid.
Before we dig into Druid though, the progress in the last two weeks.
Something you might not know about me is that I’m an avid home cook. As such, I like to experiment in the kitchen, improvise new recipes, and modify existing ones. I also track my calorie and macronutrient intake. I have software tools for this, but I don’t like them and eventually I got fed up and decided to write my own.
I also thought it would be interesting to try working with the garage door up and writing more publicly about what I’m working on, so this is part one of an ongoing series where I do just that.
A while ago, I complained on Reddit about the Travis-CI build times for my Rust crates. Aleksey Kladov, better known in the Rust community as “matklad”, responded to mention that Travis-CI’s caching behavior is… suboptimal for Rust crates and gave me a way to fix it.
I figure there are probably other Rust developers out there who aren’t aware of this, so I’m writing a short post to explain it.
I’m pleased to announce the release of Criterion.rs v0.3, available today. Version 0.3 provides a number of new features including preliminary support for plugging in custom measurements (eg. hardware timers or POSIX CPU time), hooks to start/stop profilers, a new BenchmarkGroup struct that provides more flexibility than the older Benchmark and ParameterizedBenchmark structs, and an implementation of a #[criterion] custom-test-framework macro for those on Nightly.
What is Criterion.rs? Criterion.rs is a statistics-driven benchmarking library for Rust.
In my post on GPGPU in Rust, I declared that I intended to work on improving the state of CUDA support in Rust. Since then, I’ve been mostly radio-silent. I’m pleased to announce that I have actually been working on something, and I’ve finally published that something.
RustaCUDA RustaCUDA is a new wrapper crate for the CUDA driver API. It allows the programmer to allocate and free GPU memory, copy data to and from the GPU, load CUDA modules and launch kernels, all with a mostly-safe, programmer-friendly, Rust-y interface.
A bunch of stuff has happened since I published my post on The State of GPGPU in Rust. Most importantly, Denys Zariaiev (@denzp) released his work on a custom linker for Rust CUDA kernels, and a build.rs helper crate to make it easier to use.
These two crates eliminate many of the problems I referred to in my previous post. The linker solves most of the “invalid PTX file” problems, while the ptx-builder crate does all of the magic that Accel was doing behind the scenes.