the subjection of assumptions to mechanical onslaught. sled.rs tylerneely.com Meidner Plan resurrectionist

Berlin, Germany
Joined July 2011
Every once in a while something comes along that changes the way a profession is viewed by its practitioners. Hillel's work is a significant counterpoint to software engineer exceptionalism - we are not as different as is often claimed, and we have a lot to learn from each other.
In 2019 I started the Crossover Project, where I studied how software and "real" engineering relate by interviewing people who've worked in both. 17 interviews, 12 hours of recordings, and untold hours editing later, I'm finally ready to share my findings! hillelwayne.com/post/crossov…
Show this thread
0
2
14
electrified filth ⧖ retweeted
Self tuning makes adaptive radix tries competitive with learned indexes: db.in.tum.de/~fent/papers/Se…
0
2
20
electrified filth ⧖ retweeted
Replying to @sadisticsystems
Storing only the parameters of a function that maps keys to indexes instead of the keys themselves is also the technique behind learned index structures -- it's harder to build a trie for arbitrary data, but the results on [u64] are pretty amazing: rm.cab/blis
0
2
3
Was feeling jealous of entropy coded tries, so I added this trick to sled.rs: if all keys on a tree node are a fixed stride distance apart, we can completely skip storing *any* key data, as they are losslessy determinable by (index * stride) + node low key :)
4
0
33
This also means that to retrieve a value on a node, we don't need to do any binary searching. It's just a branch-free calculation + lookup at a fixed offset!
1
0
7
(We still store the low key on each node to make this possible)
1
0
2
I did not expect to miss hackathons, but seeing people able to have one makes me pretty jealous.
😉Time for some refreshment! 🧃🍰🥯🍫🍕☕️ #TiDBHackathon
1
0
14
Why has it taken me so long to find this? I'm excited to try out fuzzcheck on the new sled.rs inline Node binary format. It combines fuzzing with property testing in a way that may avoid the performance issues I've hit with using quickcheck+libfuzzer in the past.
I've published an update to fuzzcheck-rs! What's new: 1. It is much faster 2. Mutators are efficiently composable (e.g. given a Vec mutator, it's trivial to create one for Vec<Vec<_>>) 3. New inputs are generated from existing ones by mutating them in-place, with zero allocation
Show this thread
1
1
8
But anyway, function calls involve shipping memory around that tends not to be mutable, which is much friendlier for the hardware compared to shipping occasionally modified memory around. I wonder if there's some SPECTRE-like implications of this LOCK-bypass 🤔
1
0
3
Show this thread