Thread: So, I'm trying out Google's C++ test library...

Originally Posted by Epy

The Computer Language Benchmarks Game has always been my standard.

Let's look at the first "benchmark" in this (regex-dna) and briefly compare the C and C++ versions:

The C version uses stdio for reading the input file and printing the results. It uses Tcl libraries for string handling/storage and to implement its "regcount" function. It uses GLib for its "regsub" function (using GLib's regex handling). It uses pthreads to do parallel processing by hand using worker callback functions. It relies on Linux-specific features (the /proc filesystem) to determine the number of cores and thus will probably not achieve good performance if run on Windows using the same hardware.

The C++ version uses stdio for reading the input file, iostreams for writing the output, a C++ library called RE2 for regex handling and OpenMP for parallel processing.

The C++ version is seemingly written with a "just get the job done" attitude (and is much shorter), whereas the C version's author seems to have thought very carefully about performance and use of resources. For example:

1. The C++ version reads the entire file once into a huge buffer (large enough for the entire file) and then immediately copies that huge buffer to another area of memory, likely wasting some time. The C version is careful to read the file a block at a time using a small buffer in memory. I suspect the block-based approach makes better use of the hardware for a large data file.

2. The C++ version does not really seem to attempt to parallelize on the data itself (5 million records, apparently), but only on the fixed string patterns (9-11 items). The C version tries to parallelize not only on the patterns, but has been written carefully to deliberately split the input data off into separate worker tasks in its process_variant_worker function.

The C version currently benchmarks faster but is likely not optimal, either. For example, it uses a mutex to share an integer between worker threads where an atomic int could probably be used instead. Also, neither version attempts to parallelize the file I/O with the computation itself. I.e. both versions must wait for the entire input file to be read from the disk before any processing begins, which is probably not optimal usage of the hardware.

Originally Posted by Mario F.

Let me help you Elysia:

- "Because C can be faster", said Epy
- "Tests have shown that C++ can be faster than C too, so that argument holds no weight.", retorted Elysia

He says can be, you say can be not. Which is implied when one says "can be". But other than giving you a medal for stating the obvious, what exactly did you want to say with that? That the makers of CUDA (an highly performant and optimized library) decided on purpose to program it in a slower C language? Or that maybe C++ wasn't the best option performance-wise for a low-level API?

- Epy said, "Can be, but C ends up being faster more than 50% of the time. The Computer Language Benchmarks Game has always been my standard."
- Elysia replied, "That's a load of nonsense. It all depends on how you write your code, your compiler and your CPU."

He says half of the time it is faster, you says it all depends. So, here is your second medal for mastering the obvious. But again, what do you mean? You mean to say that if the CUDA developers had used C++ correctly with the correct compiler and the correct CPU they would have created an API that would be faster than developed in C under the same conditions (correct use of the language, correct compiler and correct CPU)?

(And how the heck a correct CPU and correct compiler fits in a cross-platform library? But, whatever)

All I am trying to say is that C and C++ are roughly equal in performance. Sometimes, C edges ahead a little bit, sometimes C++ edges ahead a little bit, and this depends mostly on the compiler and the standard library implementation. Sometimes a CPU can perfer the codegen generated by one compiler over the other, but that's details. There's no clear "winning bullet" that you get by choosing C. You don't automagically gain more performance 50% of the time. It all comes down to how optimized your code is, how optimized your compiler is and how optimized your standard library is.

I don't mean to make any assumptions that any API would have been faster if it was developed using C++, but at least it wouldn't be any slower. That is, unless they know something I don't, and then I wonder why Microsoft chose C++ over C for their GPU language.

And since we're handing out medals, I'm going to give one to c99tutorial for pointing out that this benchmark can't be trusted. It's difficult to compare a program written in C++ and the same in C most of the time due to bias. Often the author prefers one over the other, or in some cases, we get people submitting sub-optimal solutions for one or the other language, as seems to be the case here according to c99tutorial. We can't draw ANY conclusion from this benchmark if such is the case. Disclaimer: I did not go over the code myself.

Originally Posted by Epy

Well duh. The gap on that link would close a bit if Clang were used, or the Intel compiler perhaps.

I know what you're getting at (speed should have nothing to do with the language involved, only the implementation for that language), but I still say that on average (for most compilers/platforms/situations), C is going to be faster.

And I am still going to disagree. Unless you are going to put a lot of effort into finding optimized libraries, your handwritten code is probably going to be beaten by a good C++ standard library implementation.

C can absolutely be faster. I'm not going to disagree on that. But writing correct, efficient C code is still harder than writing correct, efficient C++ code (again, knowing that you actually know the language you're programming for) most of the time.

Originally Posted by MutantJohn

Going off-topic again (I know, I'm the worst :P) but to me, all statically-compiled languages are logically equivalent. By this I mean, they all have the capability of producing the same instruction set so saying that one language is faster than the other really just comes down to implementation details which change with the breeze, really.

Maybe, if all compiled languages shared a common translation to assembly. But they can't exactly because they don't share common semantics and syntax. Programming languages are like spoken languages. If a word does not exist in a foreign language, whatever replacement is used will not represent a 1 on 1 translation. If it did, the language that implemented the original word did a lousy job.

Originally Posted by MutantJohn

Even if we did assume that link to be valid, C isn't fast enough that it'd be worth eschewing what C++ offers in terms of maintainability and expressive power.

C++ and C share a maintainability score alright. A low one among programming languages. And if by expressiveness you mean the names of things, you can also name your C variables, functions and types. If however you mean OOP, then you just threw any chance at expressiveness out of the window.
I can think of at least a couple of reasons to prefer C++ over C. But never maintainability or expressiveness.

Originally Posted by Epy

@John: just when you became comfortable with the command prompt on Windows: Microsoft Replaces Command Prompt with PowerShell in Latest Windows 10 Build

And then there's Ubuntu Bash in WSL.

Originally Posted by Elkvis

And then there's Ubuntu Bash in WSL.

Such a laugh. Microsoft basically admitting how much Windows sucks. If you're going to do something like that that, might as well install Cygwin instead. Get tons more and greater stability. WSL is beta.

Reminds me of the whole Apple PPC vs. PC x86 war back before Apple caved and went x86....what was that about PPC being superior? Lol.

Originally Posted by Epy

Such a laugh. Microsoft basically admitting how much Windows sucks. If you're going to do something like that that, might as well install Cygwin instead. Get tons more and greater stability. WSL is beta.

And Cygwin is terrible. Cygwin emulates (badly) a Unix environment. WSL is a linux environment. You can do (almost) anything with WSL, that you can do with a standalone Ubuntu installation. It includes the aptitude package manager, and can install any package available to Ubuntu 14.04.