
Sorting in C++: 3 times faster than C - radiospiel
http://radiospiel.org/sorting-in-c-3-times-faster-than-c
======
tikhonj
Couldn't you replicate most of C++'s optimizations by hand in C? Because
that's what I always took to be the real reason C is fast--not because pretty
code is fast, but because you can make the code as ugly as you want (hello
instrinsics!) to optimize it.

For example, couldn't you just inline the relevant code manually in C? Sure it
would be ugly, but it would be fast. Besides, in an absolute sense pretty much
any C or C++ code is going to be ugly; if you want pretty code and a compiler
that valiantly tries to optimize it, use something like Haskell :P.

~~~
veyron
This example highlights the reasons to avoid function pointers when possible.

An apples to apples comparison would use a handwritten sort routine for C
instead of using a library function: STD::sort is closer to writing your own
sort and putting in the function calls than calling an external function.

~~~
crusso
I don't agree with how you define "apples".

I would define an apples to apples comparison as "How would a typical C
developer write this test? How would a typical C++ developer write this test?"

A typical C developer would use a library function. A typical C++ developer
would use the stl.

This was a great article for me because I am actually about to write some very
performance intensive data manipulation code that will use sorting and other
similar algorithms. I was thinking about doing it in C because I always
mentally associate C with performance.

This article is a reminder to me that although I could eventually laboriously
hand-tweak the C to be performant, there are things in C++ that will perform
better than C without my even having to do much optimization, if any.

~~~
veyron
FTA:

    
    
         By inlining C++ is able to run just the raw algorithm. On the opposite the C code has a number of indirections
    

The typical C developer is aware of the deficiencies and would write a custom
macro to do the sort (I have a whole macro library for many small functions)

I agree that the language provides convenience, but the statement that sorting
as a concept is faster in C++ than in C seems to be a stretch.

------
udp
Or rather, _"Sorting with std::sort: 3 times faster than qsort"_.

~~~
osolo
Exactly. std::sort does NOT use quick sort. So all he's doing is comparing two
different algorithms. It has nothing to do with C vs C++.

~~~
archangel_one
std::sort isn't guaranteed to use any particular algorithm, but IIRC quicksort
fits the requirements and hence has been used in the past, even if introsort
might be more common now.

~~~
steve-howard
I believe said requirements were written to allow qsort.

------
cygx
To level the playing field, I took the glibc quicksort implementation from
[http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=stdlib...](http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=stdlib/qsort.c;hb=HEAD)
(which is actually a hybrid algorithm), modified it to use a comparison
function with signature _Bool(const void* , const void* ) as we're only
interested in whether an element is less than another, and included the source
code verbatim (which is essentially what including <algorithm> does).

The C++ code still outperformed the C code, but the ratio dropped from ~2.8 to
~1.4.

40% performance gain is nothing to sneeze at, but it's far less impressive
than the sensational 3x from the headline.

The remaining difference is probably due to the choice of algorithm: the GNU
STL algorithm is introsort. While it's also a hybrid algorithm based on
quicksort, it adds heapsort to the mix, which is known to outperform quicksort
on random data.

------
lzm
How can one "limit branching", and "optimize for the second level memory
cache"?

~~~
hanbam
I split the code in two binaries: "code" (qsort) and "code2" (std::sort()) and
then I ran both under a profiler (based on intel's performance counters).

It seams that qsort simply executes an order of magnitude more instructions
for the same result than std::sort. On the other hand std::sort() code, even
if it's faster, it has more branch miss-predictions.

Here [1] are the results if you want to have a look.

[1] <https://gist.github.com/b97a6395c9a20c3d4cea>

~~~
radiospiel
Thanks, that is quite interesting.

------
chj
every once in a while some one would come out with this kind of stupid study.
please do not post these results any more, it is just a waste of time.

~~~
radiospiel
Well, every once in a while someone comes out with "C++ is slow because of
vtables". Which is false. If those guys would stop posting this I would stop
writing what is true (but probably not too relevant for most screnarios, yes.)

------
livebeef
This was also explained in the book "Programming Pearls".

------
VMG
Shouldn't he be using _getrusage()_ instead of _gettimeofday()_ in his timer
code (<https://gist.github.com/2057981>)?

~~~
psyren
When writing profiling code (<https://github.com/vstefan/Instrum/>), I use
clock_gettime(CLOCK_MONOTONIC) as it measures elapsed time from an arbitrary
reference point.

~~~
VMG
...which is still measuring real time, not the time spent by the current
process, or am I wrong? (maybe the downvoter can explain)

------
KonradKlause
Reading your blog's "About me" section makes me sad.

"I am working as a freelance software architect, IT consultant, ..."

~~~
radiospiel
And what exactly makes you sad in this?

~~~
KonradKlause
An IT consultant/software architect who thinks he can compare C and C++ by
calling a random sort function makes me sad...

~~~
radiospiel
People that cannot even parse headlines make me more sad: I compare sorting in
C++ and C.

~~~
KonradKlause
OMG, you really don't get it, right?

~~~
dkersten
I don't get it either - whats the problem?

~~~
cygx
The headline implies that C++ as a language is superior to C as far as
performance is concerned, whereas all that was shown is that the STL is
superior to the libc from a batteries-included point of view.

