Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Rust is now faster than C

Name: Anonymous 2017-02-21 18:14

http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=knucleotide

How can this be? Since C is as fast as assembly, does this mean Rust does some microcode optimilzation under the hood?

Name: suigin 2017-02-22 3:54

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=1

The 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.h

This 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.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List