Hacker News new | ask | show | jobs
by detrino 4006 days ago
Cache coherency is something else.

But ya, B-Trees will (sometimes significantly) outperform BSTs for small keys because they will have fewer cache misses. Also interesting is that the idea that RB-Trees are faster than AVL trees for insert/delete may be outdated as well. I've seen benchmarks of AVL trees beating std::set in both libstdc++ and libc++ for both of those operations. Again this is probably due to less cache misses.

My B-Tree story is actually a B+Tree story. B-Trees (and B+Trees) can can actually be used for more than just ordered sets/maps, I've implemented a C++ sequence container[1] that allows O(log n) random access insertion and deletion. It is _much_ faster than a similar container[2] implemented using AVL trees, but at the cost of iterator stability.

[1] https://github.com/det/segmented_tree_seq

[2] http://avl-array.sourceforge.net
1 comments
craigching 4005 days ago
> Cache coherency is something else.

Ugh, yes, sorry about that. I meant that they are more cache friendly.

Not to disagree with anything you've said and only to back up what I was trying to get at is this SO answer:

http://stackoverflow.com/questions/647537/b-tree-faster-than...

The part I'm talking about is:

  Also, unless you play nasty allocation tricks with the red-
  black trees, it seems reasonable to conjecture that B-trees
  have better caching behavior (it accesses an array, not
  pointers strewn about all over the place, and has less
  allocation overhead increasing memory locality even more),
  which might help it in the speed race.
That's not exactly the reference I was thinking of, but it says what I remember about it.

Again, not taking away from what you're saying and not disagreeing with you in any way, more backing up what I originally said ;)

link