Unfortunately the domain name appears to have been hijacked but you can still read the article in the Internet Archive

http://web.archive.org/web/20071223232457/www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html

One thing I noticed with your khash.h/kbtree.h API is that it requires that the objects be allocated with calloc(). Another key for high performance in C is to minimize the amount of memory allocations that occur. Right now your khash interface requires a specific calloc() be called for it. The list types in Linux were designed to constructed in a parent structure such that you do not need to do a separate allocation for the list itself. They also provide a macro called INIT_LIST_HEAD() that will let the compiler build a binary that has the list pre-initialized.

http://lxr.linux.no/linux+v2.6.27.10/include/linux/list.h#L19

Sorry that I did not state it clearly. For the libavl example, we are looking at libavl_avl and libavl_avl_cpp in the table. The latter is implmented in C++ template. We can see that libavl_avl_cpp is 56% (=(1/6.73-1/10.51)/(1/10.51)) faster than libavl_avl on MacIntel with integer as keys. On Linux-Intel the difference is less (31% faster on integer keys or 15% on char* keys), but still significant. As for memory, libavl_avl_cpp does not save resident memory on Mac probably because memory alignment. On a 64-bit Linux, it saves 39% (=(48.41-29.41)/48.41) of resident memory.

The comparison of libc’s qsort and STL’s sort are showed in another post. My implementation of introsort (essentially quicksort) is 110% (=(1/7.887-1/16.579)/(1/16.579)) faster than libc’s qsort on MacIntel, or 298% faster on LinuxAMD. The speedup comes at two points: saving a function call on comparisons and avoiding memcpy(). On Mac, it seems that most of the speedup comes from the first point, but on Linux most comes from the second point.

@Facepalm

I have showed the link to the table, as well as the design of the experiment. The table is too large to fit here and so I posted on another website. Sorry that that table is not very clear. Please see my reply to Kevin for more information.

Template provides more flexibility. We can always put void* in template when necessary, but we have to live with the inefficiency of some C libraries even if we do not mean to. In many practical applications, we know the type of data in a container. We do not need the runtime flexibility in common cases, I think.

I have also tried to put void* in SGI’s std::set. On integer keys (MacIntel), std::set finishes in 12.738 sec (vs. 5.99 in my benchmark), using 29.80 MB memory (vs. 19.87). This is another evidence that using void* can be very inefficient.

Additionally, OF COURSE templates are going to be faster in this instance. The C compiler cannot make assumptions at compile time about the content of void pointers. The types are being bound at compile time in C++ templates so what you’re really doing is reducing the runtime flexibility of the code.

-K