These benchmarks are a joke. It's not the language's fault. It's the programmer and the libraries in use.
Take a look at all of the optimization opportunities:
http://benchmarksgame.alioth.debian.org/u64q/program.php?test=knucleotide&lang=gcc&id=1The
element
struct has 32-bits of padding, and it's not CPU cache friendly. You should use two orthogonal arrays instead of a struct.
qsort
is slow as fug. Do a fucking parallel bitonic sort with OMP or a radix sort.
It uses
khash
. Who the fuck uses
khash
?
https://github.com/attractivechaos/klib/blob/master/khash.hThis uses quadratic probing which is proven to be slow on modern CPUs with deep cache architectures, unless the hash table keys are suitably large in size. It also looks unoptimized as hell. You could do a better job with less code if you just hand-rolled the insert and lookup functions for a linearly addressed hash map.
fgets
? If you're using non-standard shit like khash, why not use POSIX libraries like
read
and read in huge blocks from the file, instead of 4K at once. Way faster for large files.
The OMP calls just run the different searches in parallel. It doesn't actually partition the searches optimally.
I bet we could get the C version running in half the time of Rust.