Okay I spent an hour trying to read this AI Slop. The prefix key idea is "cool" (see: 1). Gives you sort of "best of both words" B+ tree and B tree behavior.
It only applies to `u64`, `u128`, `[u8]`, `str` (and box/vec variants) AFAIT [2]. Their own 'agentic' pre-release checklist calls this out as work that needs to be done prior to release. But then I can be wrong because as OP says
> No human can write better code than LLMs. All of the implementation is written by LLMs, and cross-checked by LLMs from different providers.
Hi author here, first of all, thank you for taking time to read the AI slop, you probably already spend more time than I do on this repo, appreciated!
The inline key: yes, it applies to all kinds of integers and strings, and it exposes InlineKey traits that allow you to implement your own inline prefix.
The checklist items: I forget to cross them and they are all implemented, although I think the checklist item has nothing to do with bbtree. but this is definitely a flaw.
Very nice work. I'm working on stuff... adjacent to this I guess. I've been harping on the ideas that we have to be much more willing to reach for intrinsics, be laser focused on the cache lines, treat DRAM more like an async block device, but I can't believe I haven't thought to show the impact of coherence traffic! When I get some time I might try to apply some of my tricks to bbtree. DM me. I'd love to be able to reach out when I do.
I had a feeling when I read the title and then started reading the post, "this person must be young, probably a student." I think it's ironic that they're using such unscientific terminology like "fastest" given their background https://xiangpeng.systems/. So clearly, it's in the interest of marketing. Maybe some kind of job advertising/resume thing.
I can almost guarantee that someone has built a custom btree for their specific domain which is faster than this; and that they probably have some or all of the techniques used in this library that are the main contributors to performance, as well. Prefetching is probably the main one they'll claim, and I know personally of some proprietary implementations which have it.
I would like to see some more humility, but I suppose that when you've already resigned your own potential to being below an LLM, then what's the point.
It's not possible or useful for them to grow anymore. Some new frontier model next week will outdo whatever ephemerally useful project this person writes, right? That's the logic?
Okay I spent an hour trying to read this AI Slop. The prefix key idea is "cool" (see: 1). Gives you sort of "best of both words" B+ tree and B tree behavior.
It only applies to `u64`, `u128`, `[u8]`, `str` (and box/vec variants) AFAIT [2]. Their own 'agentic' pre-release checklist calls this out as work that needs to be done prior to release. But then I can be wrong because as OP says
> No human can write better code than LLMs. All of the implementation is written by LLMs, and cross-checked by LLMs from different providers.
cites:
1. https://bbtree.xiangpeng.systems/post/#apply-to-b-trees
2. https://github.com/XiangpengHao/bbtree/blob/main/bbtree/src/...
Hi author here, first of all, thank you for taking time to read the AI slop, you probably already spend more time than I do on this repo, appreciated!
The inline key: yes, it applies to all kinds of integers and strings, and it exposes InlineKey traits that allow you to implement your own inline prefix.
The checklist items: I forget to cross them and they are all implemented, although I think the checklist item has nothing to do with bbtree. but this is definitely a flaw.
writing a macro to implement most common integers would've been a time saving.
I also appreciate your paper/work on bf-tree, I started a hobbyist filesystem based on it.
Very nice work. I'm working on stuff... adjacent to this I guess. I've been harping on the ideas that we have to be much more willing to reach for intrinsics, be laser focused on the cache lines, treat DRAM more like an async block device, but I can't believe I haven't thought to show the impact of coherence traffic! When I get some time I might try to apply some of my tricks to bbtree. DM me. I'd love to be able to reach out when I do.
https://news.ycombinator.com/item?id=50218616
> Production-ready by formal verification, model checking, deterministic simulation, fuzzing, and lots of testing.
What does model checking mean here?
My guess is https://en.wikipedia.org/wiki/Model_checking . C Bounded Model Checker [0] is a relatively well-known instance in the niche.
[0]: https://www.cprover.org/cbmc/
No, he used verus, a rust tool. And shuffle and ffs. See his docs
> No human can write better code than LLMs.
Bold claim...
I had a feeling when I read the title and then started reading the post, "this person must be young, probably a student." I think it's ironic that they're using such unscientific terminology like "fastest" given their background https://xiangpeng.systems/. So clearly, it's in the interest of marketing. Maybe some kind of job advertising/resume thing.
I can almost guarantee that someone has built a custom btree for their specific domain which is faster than this; and that they probably have some or all of the techniques used in this library that are the main contributors to performance, as well. Prefetching is probably the main one they'll claim, and I know personally of some proprietary implementations which have it.
I would like to see some more humility, but I suppose that when you've already resigned your own potential to being below an LLM, then what's the point.
It's not possible or useful for them to grow anymore. Some new frontier model next week will outdo whatever ephemerally useful project this person writes, right? That's the logic?
Especially since it's trivially proved wrong by inspecting the code. It's invariably awful.
This is only a statement that could be written by someone that doesn't read the code.
looks awesome, thanks for sharing