Key is 2600 bytes for mldsa 87. Your fav icon is 10x bigger than that. Verify time and encapsulation is a few hundred microseconds for one verify and encaps. Your scary proportions are minuscule in practice. Even cortex m class can handle it. Not sure you have an argument when you put it up against a typical browser session. Plus 50% of all web traffic already uses pqc ciphersuites sooooo….
I was thinking about transaction processing, eg visa/blockchain. And here storing and sending almost full packet for signature instead of 32 bytes matters. For sessions this shouldn't matter
Oh good point. Thanks. I don’t think about cryptocurrency at all. But yes the sigs are now 4.6k. Thats a huge block. Yeah that sure throws a wrench into blockchain. But the alternative is that blockchains based on ecdsa go away. Seems like a win to me. But I despise cryptocurrency.
Try g.ai. It's stupid fast and uses google indexes. Kagi? sometimes doesn't correctly parse intent, in Google thing you can just ask function doing this and gives you it, with examples, grounding and extremely fast. I'm paying for kagi since the begging and I guess id cancel it because it gives not so much added value
Bftree solves one non-obvious pain point - caching when your data set is random (the key is a hash) and the data is smaller than the page size. LSM reads are based on block size; same with caching. So if your record is 8 bytes, you end up caching the remaining ~4 KB, and the hit rate will be pretty low.
I think a fair comparison would be against a whitepaper? Clearly this is an exploratory venture and not production grade software.
You managed to clone the repo an run your test by yourself, whatever the outcome is this is a plus against the standard model for scientific research.
Also, a breath of fresh air among every other show HN thread using hundreds of adjectives to describe the "behavior" of a fully vibed system. I think this is a good model for presenting engineering projects.
> You managed to clone the repo an run your test by yourself, whatever the outcome is this is a plus against the standard model for scientific research.
That's so true, which is kinda funny since one of the cornerstone of scientific thinking is reproducibility.
That would mean it improved somewhat. We always got better write performance from mysql vs postgres, however that is a while ago; we then tried tidb to go further but it was basically rather slow. Again, a while ago.
When did you get your results, might be time to re-evaluate.
It was 1 year ago. Around 15 tikv serves, 32 cpu, 128 ram each, 4 tb nvme. In this case latency matters a lot. When i had load server in different region with ping of 3ms I got 70k inserts, when moved to the same region with sub ms ping it went to thousands
The crazy part about this is that (auto) vectorization in Rust looks something like this: iter.chunks(32).map(vectorized)
Where the vectorized function checks if the chunk has length 32, if yes run the algorithm, else run the algorithm.
The compiler knows that the chunk has a fixed size at compile time in the first block, which means it can now attempt to vectorize the algorithm with a SIMD size of 32. The else block handles the scalar case, where the chunk is smaller than 32.
reply