5 ms·
High-performance header-only container library for C++23 on x86-64
From the readme:
The B+tree implementation provides significant performance improvements over industry standards for large trees. For some workloads with large trees, we've observed:
- vs Abseil B+tree: 2-5× faster across insert/find/erase operations
- vs std::map: 2-5× faster across insert/find/erase operations
- deleted 9mo ago[deleted]
- ognarb 9mo ago> History/Motivations This project started as an exploration of using AI agents for software development. Based on experience tuning systems using Abseil's B+tree, I was curious if performance could be improved through SIMD instructions, a customized allocator, and tunable node sizes. Claude proved surprisingly adept at helping implement this quickly, and the resulting B+tree showed compelling performance improvements, so I'm making it available here. It seems the code was written with AI, I hope the author knows what he is doing. Last time I tried to use AI to optimize CPU-heavy C++ code (StackBlur) with SIMD, this failed :/
- LoganDark 9mo agoOh hey, I wrote a Stackblur implementation in Rust. The trick I used is to SIMD across multiple rows/columns of the image rather than trying to SIMD the algorithm itself. https://github.com/logandark/stackblur-iter https://github.com/logandark/stackblur-iter
- klaussilveira 9mo agoBoth Codex/Claude Code are terrible with C++. Not sure why that is, but they just spit out nonsense that creates more work than it helps me. Have you tried to do any OpenGL or Vulkan work with it? Very frustrating. React and HTML, though, pretty awesome.
- seg_fault 9mo agoI had the same experience. C++ doesn't even compile or I have to tell it all the time "use C++23 features". I tried to learn OpenGL with it. This worked out a bit, since I had to spot the errors :D
- TingPing 9mo agoSame here. C++ changes fast and can be written in many styles so not a ton of training data I assume.
- DrBazza 9mo agoIn what scenarios are they terrible? I hope not every scenario. I've found Codex adequate for refactoring and unit tests. I've not used it in anger to write any significant new code. I suppose part of the problem is that training a model on publicly available C++ isn't going to be great because syntactically broken code gets posted to the web all the time, along with suboptimal solutions. I recall a talk saying that functional languages are better for agents because the code published publicly is formally correct.
- simonw 9mo agoWhich models? It's possible Opus 4.5 and GPT-5.2 are significantly less terrible with C++ than previous models. Those only came out within the past 2 months. They also have significantly more recent knowledge cut-off dates.
- klaussilveira 9mo agoI'll be specific: I've been recently working with Opus 4.5 and GPT-5.2. Both have been unable to migrate a project from using ARB shaders to 3.3 and GLSL. And I don't mean migrating the shaders themselves, just changing all the boring glue code that tells the application to use GLSL and manage those instead of feeding the ARB shaders directly. They have also failed spectacularly at implementing this paper: https://www.cse.chalmers.se/~uffe/soft_gfxhw2003.pdf https://www.cse.chalmers.se/~uffe/soft_gfxhw2003.pdf No matter how I sliced it, I could not get a simple cube to have the shadows as described in the paper. I've also recently tried to get Opus 4.5 to move the Job system from Doom 3 BFG to the original codebase. Clean clone of dhewm3, pointed Opus to the BFG Job system codebase, and explained how it works. I have also fed it the Fabien Sanglard code review of the job system: https://fabiensanglard.net/doom3_bfg/threading.php https://fabiensanglard.net/doom3_bfg/threading.php As well as the official notes that explain the engine differences: https://fabiensanglard.net/doom3_documentation/DOOM-3-BFG-Technical-Note.pdf https://fabiensanglard.net/doom3_documentation/DOOM-3-BFG-Te... I did that because, well, I had ported this job system before and knew it was something pretty "pluggable" and could be implemented by an LLM. Both have failed. I'm yet to find a model that does this.
- shihab 9mo agoI'd love to see a breakdown of what exactly worked here, or better yet, PR to upstream Abseil that implements those ideas. AI is always good at going from 0 to 80%, it's the last 20% it struggles with. It'd be interesting to see a claude-written code making its way to a well-established library.
- leopoldj 9mo agoI apologize if this is common knowledge. Modern C++ coding agents need to have a deep semantic understanding of the external libraries and header files. A simple RAG on the code base is not enough. For example, GitHub Copilot for VS Code and Visual Studio uses IDE language services like IntelliSense. To that extent, using a proper C++ IDE rather than a plain editor will improve the quality of suggested code. For example, if you're using VS Code, make sure the C/C++ Extension Pack is installed.
- the_arun 9mo agoThere is also new Adaptive Radix Tree implementation - https://www.db.in.tum.de/~leis/papers/ART.pdf https://www.db.in.tum.de/~leis/papers/ART.pdf which is supposed to be faster than B-Tree
- unit149 9mo ago[dead]
- plorkyeran 9mo ago2-5x faster than both abseil's b+tree and std::map means that abseil's b+tree had to be the same performance as std::map for the tested workload. This is... very unusual. I have only ever seen it be much faster or moderately slower.
- sedatk 9mo agoNot necessarily. Insert could be 5x faster in one, and 2x faster in another, and there would still be orders of magnitude difference between both. 2x-5x is a long range.
- deleted 9mo ago[deleted]
- dicroce 9mo agoOk, maybe someone here can clear this up for me. My understanding of B+tree's is that they are good for implementing indexes on disk because the fanout reduces disk seeks... what I don't understand is in memory b+trees... which most of the implementations I find are. What are the advantages of an in memory b+tree?
- wffurr 9mo agohttps://github.com/abseil/abseil-cpp/blob/master/absl/container/btree_map.h https://github.com/abseil/abseil-cpp/blob/master/absl/contai... mentions that b-tree maps hold multiple values per node, which makes them more cache-friendly than the red-black trees used in std::map. You use either container when you want a sorted associative map type, which I have not found many uses cases for in my work. I might have a handful of them versus many instances of vectors and unsorted associative maps, i.e. absl::flat_hash_map.
- dataflow 9mo agoMemory also has a seek penalty. It's called a cache miss penalty. It might be easier to think of them in general as penalties for nonlocality.
- barishnamazov 9mo agoAlso want to share B- tree implementation from the Algorithmica HPC book: https://en.algorithmica.org/hpc/data-structures/b-tree/ https://en.algorithmica.org/hpc/data-structures/b-tree/