You may read my other posts about efficient generic programming in C. For generic C libraries, GDSL/Glib uses void*, which may have efficiency issue. Sglib and Sean’s Tool Box use macros, although sglib does not use the best algorithm at least for rb-tree. For generic RB-tree, Niels Provos’ tree library is recommended due to its performance and stability. For generic hash table libraries in C, I recommend my own implementation.

STL is the work of several phenomenal programmers who have considerable influence over the C++ programming. It is difficult for a common/unknown programmer to write something widely accepted by the C community. In addition, good C programmers, like me, love to reinvent the wheel. They do not rely too much on existing libraries as much as C++ programmers do.

You can put the key and value in one struct:

typedef struct { int key, val; } cell_t;

and

#define cell_cmp(a, b) (((a).key > (b).key) – ((a).key < (b).key)

thus the B-tree is only built for cell_t::key and you can save other information in val.

In fact, STL hash_map is also implemented in a similar way.

Although I have not tried, I tend to believe it may have a better performance than my B-tree implementatin. You can have a look at this page, where a Judy hash table is compared with a traditional hash table. It seems to me that conclusion is on random input, Judy is comparable to hash table. Sean’s hash table has similar speed to my khash.h and in my hash table benchmark, khash.h is times faster than kbtree.h with slightly larger memory footprint. Putting all these together, I think Judy is probably faster than my kbtree.h.

I will try to do an experiment.

I could vaguely see what cache-oblivious algorithms are and the advantages of them, but I do not how to implement one really. I a bit doubt B-tree is not cache-oblivious, though.

Cache-oblivioius algorithms are pretty limited to the academic world. And my understanding of this world is people here care more about theoretical performance rather than practical. They try to reduce the number of theoretical cache misses at cost of adding more operations. The resultant program might not be faster in practice. I was also trying to find actual code on cache-oblivious search tree and the only code I can find claims that their cache-oblivious red-black tree is far slower than SGI STL’s implementation. I think I will stop here unless someone could give me source code and so I can benchmark it. It is really a pain to implement one by myself while getting a worse result.

The benchmark is here, showed with hash table comparisons. I will separate them out when I have time.

@josh

People have done a lot of comparisons between AVL tree and red-black tree. My impression is they have quite similar practical performance. And AVL is a binary tree. It has to use two pointers at least. So my argument largely stands for AVL tree, too. I will also pick up some good AVL tree implementations in my benchmark in future.

@Sebastain

I admit that the the code itself looks terrible at the first sight, but to the best of my knowledge, this might be the best way to achieve generic programming in C while maintaining the best performance. If you have better ideas, I am more than happy to learn. In addition, when I am used to such macros, I do not feel too much difficulty in reading, writing, debugging or maintaining them.

@Reid

I know the standard splay tree only use two pointers, but in practice it is not as fast as the standard red-black tree. I have a library with splay tree and RB tree, written by the same programmer. RB tree is obviously faster for random input. As for red-black tree, I was saying we need parent pointer for “the standard red-black tree”. I am aware that some variants (such as left-leaning red-black tree) do not need a parent pointer, but the red-black tree in the majority of textbooks requires one additional pointer. I call them standard. Furthermore, from what I learn these days, no red-black tree using two pointers is as fast as the red-black tree implemented in STL which use three pointers.

I also believe B-tree tends to be more cache efficient. Another possible reason that B-tree is efficient is that you do not need to re-balance a B-tree so frequently as other binary trees, as is stated in wiki.

@Stuart

I used to write such things (a hash table for example) in C++ and I think I am not bad at that. However, I found the only piece of C++ code in my C project is always related to C++ template headers, which makes me feel uneasy.

What’s more important, C++ programmers have STL. but most C programmers have to achieve generic programming at the cost of efficiency. I want to change this. Although the .h source code is hard to read, the API does not look so bad. What do you think? Do you have better ideas? I am still exploring the methods.