0.8 seconds for C and 2.3 seconds for C++? That discrepancy is a huge red flag in this analysis, given that the code is so naive and simple that the program should effectively be the same between C and C++, so I would expect them to have nearly identical timings.
We can't know how naive and simple the code is. As far as I can see, the timings have nothing to do with the code snippet in the blog post. Instead they are from some totally separate program, with the source code not available in any language.
If I read the OP correctly the benchmark used an implementation of the Longest Common Subsequence algorithm, expected to run in O(n³) time and O(n²) space. It's a dynamic programming algorithm and so not quite trivial, but, hey, it's an algorithm. The coding is never the biggest complication with those.
As a benchmark it's probably OK, but language benchmarks in general are never very useful. Like, the op essentially makes the claim "you can't code this any faster in X language". Well, maybe you can't, but someone else can. Unless you have a way to run exactly the same code in n languages, or somehow produce exactly the same binary from n languages, then there's no real comparison, sadly.
But- we're programmers and that sort of thing is our favourite sport, innit.
Something else that struck me as wrong: the op counts the time the JVM needs to startup in the time it takes for the program to complete. That should be completely wrong, right? Otherwise we should count the time the physical machine took to boot up -and then the OS to load- in the time each benchmarked implementation took to complete. The JVM is a virtual computer, so why treat it any different than the physical one?
No. The JVM should be included too as it is part of what the language needs to run. If you wanna compare including the boot of the real machine, then go for it as to run the JVM you still need a real machine to boot, but then you're adding noise as the machine is the same for the two programs and can, due external out of control reasons, have different timings. But still, JVM IS part of the language and the program unless you compile to native.
To add to this: The same goes for C's process startup (at least the OS won't call main with those arguments; the C stdlib performs some tasks before your code runs), or interpreter startup. Unless you're writing in assembler and call the OS directly, almost every programming language will have some overhead when starting. Granted, managed languages like Java are much worse than many others.
But that's the point, isn't it? You can't ever compare two programs written in different languages claiming to test "the same program" written in different languages. Because in the end either they're not the same program, so there's no comparison, or they're the same program, so what are you really comparing?
I think the reason of comparing two programs in two different languages is exactly to have an idea of how expressive one language can be to generate a performing program given its inputs and outputs are the same, the way on which the code is written is the second factor being evaluated. The benchmark game is the perfect exemple of this, anyone can write a better version of a program and improve the language "score" until no one will be able to improve it. At this moment we can see how the language design impacts the resulting program. This should be the only way to compare languages.
I maintain a programming language that can be built as C or C++. There is no significant difference the overall execution time of "make tests" when compiled either way, and the executable sizes are close. (No options are used to disable any C++ features; just the compiler command is switched.)
If you halfways know what you are doing C++ code has at maximum a few percent overhead. I hope that C/C++ will find a better successor but this kind of naive benchmark doesn't help.
If you halfway know what you're doing, C++ code ought to be at least as fast, as you have the advantage of a reacher type system to help the compiler – no taking void pointers everywhere.