I’ll take the faster c version anyday over the rust. How are those conditional if statements working for you all?
Faster on a single query, returning a single result, on a single computer. That's not how database performance should be measured or compared.
In any case, the programming language should have little to no impact on the database performance, since the majority of the time is spent waiting on io anyway
It is to highlight that we already reached a good level of performance this early in the project.
Your claim about the programming language having no impact is just false, though. It's exactly what people said back in 2015 when we released Scylla. It was already false then, it is even more false now.
The main reason is that storage is so incredibly fast today, the CPU architecture (of which the language is a part) does make a lot of difference.
This is the right thing to do. It's a pity so many projects don't keep an eye on performance from the very first day. Getting high performing product is a process, not a single task you apply at the end. Especially in a performance critical system like a database, if you don't pay attention to performance and instead you delay optimizing till the end, at the end of the day you'll need to do a major rewrite.
I don't even care about being faster than sqlite, just not being slower, this early, is already the win I'm looking for.
That was true maybe 30 years ago with spinning disks and 100 mbit ethernet. Currently, with storage easily approaching speeds of 10 GB/s and networks at 25+ Gbit/s it is quite hard to saturate local I/O in a database system. Like, you need not just a fast language (C, C++, Rust) but also be very smart about how you write code.
may be! However, Rust makes some things easier. It is also easy to maintain and reiterate
C libraries aren't automatically the fastest option, there's a lot of C code which has stagnated on the performance front but is still widely used because it's battle tested and known to be robust by C standards.
That's kind of my point, writing a faster PNG decoder in C may be easier for you but convincing anyone to actually use it instead of the slower but proven safe-ish libpng would be an uphill battle. Trust in C code is extremely hard-won compared to Rust which uses little if any unsafe. The 'png' crate that Chrome is considering to replace libpng has no unsafe whatsoever and is still faster.
While fast code requires thoughtfulness regardless of the language, I think rust lets you focus on the fast aspect more because rustc ensures _some_ safety and correctness.
I can write fast and very unsafe C code fast, but I write code that just as fast , but safer in rust faster than in C.
Here's a more concrete, albeit irrelevant in practice example from writing most things in both languages:
https://news.ycombinator.com/item?id=42342382#42352053
Implemented in Rust over generic T, you need Wrapping<T> or the equivalent num_traits traits. The implementations for these take borrowed references. Rustc is pretty good at ensuring this becomes pass by value under the hood, but it's imperfect. I found instances of it failing in the test disassembly, even though an implementation for this never has to touch anything but registers. That's performance work that wouldn't have existed in C/C++ for these particular types.
But C lacks many modern data structures, which are critical for performance on modern hardware and bigger input data.
The reason is obvious, of course: it has less features, and doing nothing is always faster than doing something.
Once it's feature complete, then meaningful comparisons can be made. For now, it's puffery.
The goal with that was just to demonstrate that there's nothing really there that is fundamentally slower, and the perf is already on par in the areas where we spent cycles on.