> Executing cargo bench on Limbo’s main directory, we can compare SQLite running SELECT * FROM users LIMIT 1 (620ns on my Macbook Air M2), with Limbo executing the same query (506ns), which is 20% faster.
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
The goal here is not to claim that it is faster, though (it isn't, in a lot of other things it is slower and if you run cargo bench you will see)
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.
Yo glommer, I am ... very surprised to see any benchmark beat the micro-tuned sqlite so early, congrats. Where do you think rust is picking up the extra 100ns or so from a full table scan?
> It is to highlight that we already reached a good level of performance this early in the project.
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.
thanks. I am sad, but not that surprised, that a lot of people here are interpreting this as we claiming that we're already faster than sqlite all over.
I don't even care about being faster than sqlite, just not being slower, this early, is already the win I'm looking for.
> 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
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.
> 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
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.
There's still an element of truth in the idea that C is going to be faster by default. There's simply a much lower bar to writing fast (and unsafe) C. Fast Rust demands considerably more thoughtfulness from the programmer (at least for me).
> There's simply a much lower bar to writing fast (and unsafe) C.
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.
> Fast Rust demands considerably more thoughtfulness from the programmer (at least for me).
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.
It's entirely likely that you could write faster Rust in the same (nigh-infinite) time it'd take to write equally safe C. I intentionally avoided that comparison though. If you take a normal 10min function in C, it's going to compile into something reasonable and run fast. If you take the same 10min rust function, the language surface area is so much larger that there's a much higher chance that it won't.
Here's a more concrete, albeit irrelevant in practice example from writing most things in both languages:
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.
be careful with that, though. In a lot of ways it is still slower.
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.
Why did they get so diluted? Or does that mean they were just 1-2% of Homo Sapiens total population by assimilation time, so the original proportion was just kept instead?
If anyone is saying they won't use GPT-4 for translations over Google or Deepl because of hallucinations then it's a clear sign they haven't actually used all and compared.
"I'll use Google because GPT hallucinates" is a hilarious thing to say when Google still regularly devolves to half gibberish on distant language pairs.
Unless your using database specific features. One of the biggest advantages for Postgres is how incredible the ecosystem is. It doesn't work for everything, but I have an OEM, multiple kinds of text search (vector, inverted indexes, trigrams), recursive and graph-like queries (though that's admittedly less of an issue if n+1 isn't a problem), row-level acls, locks, etc.
It's really nice to have all of that power available in one piece of infrastructure.
You're missing the point. Most software doesn't need to scale or solve hard data storage problems, and if it ends up having to, you can always upgrade to Postgres with minimal effort. That makes SQLite an attractive option if you won't immediately benefit from Postgres' rich features.
We're just going to be speaking past each other, I think. GP clearly stated they lean heavily on Postgres technologies (by calling out specifics like pgvector). Stating that the applications that don't need those technologies, indeed don't need them, is tautological!
