The article is weirdly framed in favour of Biden's administration, who delayed heavy weapons by a year, and didn't fully utilize the allocated budget. Now we have a stupidly long conflict.
-march=native + mimalloc (or jemalloc) should be sufficient without causing significant undefined behavior like -O3 or most extra optimization related compiler arguments.
Nope, I'm not sure about it. I remember when I was using Gentoo about 10 years ago, this was the common reason given for using -O2 instead of -O3 in your build flags, and I'm just speaking from that memory.
The undefined behaviour is already in the C standard.
But you are right that enabling -O3 is generally going to make your compiler more aggressive about exploiting the undefined behaviour in the pursuit of speed.
In general, if you want to avoid being the guy to run into new and exciting bugs, you want to run with options that are as close as possible to what everyone else is using.
From what I looked at in the past, they seem better on paper by comparing themselves to a very old version of Redis in a rigged scenario (no clustering or multithreading applied despite Drangonfly getting multithreading enabled), and they are a lot worse in terms of code updates. Maybe that's different today, but I'm more keen on using Valkey.
Does Redis support multithreading? Doesn't it use a single-threaded event loop, while DragonflyDB basic version is with multithreading enabled and shared-nothing architecture.
Also I found this latest comparison between Valkey and DragonflyDB : https://www.dragonflydb.io/blog/dragonfly-vs-valkey-benchmar...
Valkey/Redis support offloading of io processing to special I/O threads.
Their goal is to unload the "main" thread from performing i/o related tasks like socket reading and parsing, so it could only spend its precious time on datastore operations. This creates an asymmetrical architecture with I/O threads scaling to any number of CPUs, but the main thread is the only one that touches the hashtable and its entries. It helps a lot in cases where datastore operations are relatively lightweight, like SET/GET with short string values, but its impact will be insignificant for CPU heavy operations like lua EVALs, sorted sets, lists, MGET/MSET etc.
IO multithreading is still not fully there, there were significant improvements within the first couple of iterations, hopefully, it will improve further. I see that Dragonfly uses iouring, which is not recommended by Google due to security vulnerabilities.
Dragonfly supports both epoll and iouring, and polling engine choice is quite orthogonal to its shared nothing architecture. I do not think that Valkey or Redis will become fully multi-threaded any time soon - as such change will require building something like Dragonfly (or use locks that historically were a big NO for Redis).
Yes, per [1] Google did restrict their use of io_uring on “production servers“, and in Android, ChromeOS etc.
However, within that same post, and what is often missed when that post is quoted, is that Google wrote that they did in fact “consider [io_uring] safe” for use by trusted components:
> For these reasons, we currently consider it safe only for use by trusted components.
A database like TigerBeetle is typically deployed in a trusted environment, and is such a trusted component.
They made too many decisions on their own to be a 1:1 replacement. I think there needs to be a new fork, which would just remove all of the spyware bits.
Like I need to watch DRM for my job, and it doesn't work at all. I also already ported most of their configs that I actually researched each and every line of myself + Waterfox + Arkenfox's configs into my generic Mozilla Firefox, and it works great.
