During all that time I am engaged with programming, I hear that C and C++ are the speed standards. Fastest of the fastest, compiled straight to ass...
For further actions, you may consider blocking this person and/or reporting abuse
Excuse me, but this is utter bullshit. The issue with such benchmarks is that they compare suboptimal and often even unoptimized code. To really assess the performance of languages (and thus quality of compilers), you have to compare the best programs with one another. There are projects with hundreds of participants, all trying to put out the fastest solutions in their favorite languages, like PlummersSoftwareLLC/Primes, which provide some actually useful information. In the mentioned project, currently the fasted faithful Java solution has
16466passes (in 5 seconds), compared to372283passes for the fastest faithful C solution. That is a performance increase by more than 2160% (and there are compiled Java solutions included). Potential hardware differences do not account for differences anywhere near. Some languages even have features that when optimizing based on a little more knowledge (than considered "faithful" in this case), performance can be pushed much further, e.g. with591836324passes in thisconstexpr-heavy C++ solution. That's another improvement of over 158874% over a solution that was already over 2160% faster than the best known Java solution.The relevant question w.r.t. optimized performance is how much a language and its compilers (on best optimization settings) support creating really performant machine code.
Slow crappy code can be written in every language, and C code that is only a few percentages faster than Java code is likely garbage. There are good reasons why there are usually only three languages considered acceptable for high-performance computing: Fortran (outdated), C, and C++. One of them is that managed languages tend to both multiply required memory and computing time when it comes to well-written programs.
If so, you are welcome to provide faster C code for this test.
If there is no better code for C test, it means we already have best one.
I do not waste my time on such trivial matters, but since you suggested it and are into these things, you yourself could provide faster Java code for PlummersSoftwareLLC/Primes.
Regardless, you seem to have entirely missed the point that your benchmark doesn't show anything significant. The code is too trivial. You even ruled out compiler optimizations which produce constant-time algorithms. It's worthless on so many levels, and if you carefully follow what I wrote in my last comment, you might even understand why.
Come on, why are you talking about programming and performance when not even able to form basic logical thoughts? All you did is "perform exactly the same high level algorithm without decent optimization and measure the time difference".
Real world problems are far too complex for nonsense like that. Good algorithms for the same problem adjust based on the language they're written in. A problem like yours can easily be solved via
constexpr, i.e. virtually no runtime, in C++, for example. And in greater programs where runtime matters, it would. Java doesn't even support that for non-primitive types, therefore it is far inferior. Programming languages are about design principles, features and compiler quality. Your test is merely asking whether hardware suddenly performs miracles when executing almost the same instructions due to originating from a different language, which of course it does not. The only plausible offset there is virtual machine overhead.By the way, already in the beginning of your article, your
demonstrated that you are a complete amateur to coding. Not only do C and C++ not compile to assembly but to machine code, but also are there many amateurs trying to challenge such things early on, but it keeps being an obvious fact that languages like Java are terrible when it comes to performance, while languages like C and C++ are decent. Just like most amateurs putting out such beliefs, you did not even understand where and how software performance matters, possibly not even what it is, and definitely not how it is accomplished.
After the garbage collector moves or disposes of objects, there may be "holes" in the allocated memory unless it performs "defragmentation" afterward. So, newly created objects do not necessarily mean simply "moving the pointer to the right."
Additionally, the garbage collector is notoriously known for causing the entire system to wait while it completes its tasks. It runs unexpectedly and can take significant amount of time in large projects, so you literally cannot build "real-time" systems on GC languages
the garbage collector is notoriously known for causing the entire system to wait while it complete...You know about which amount of times we are talking? micro seconds? Also depending on which GC you are using...
Well, it depends on the allocated memory size and sometimes it takes dozens of milliseconds which can be noticeable in smooth animation or gaming. I also came across articles about experimental operating systems built on managed code, which tend to operate too slowly.
Benchmarks demonstrate opposite.
In Java or Go GC allocates memory just moving the pointer after filling by zeros. As I said in the article, GC moves all alive objects to the end of the last generation heap peak. So, there are no gaps between objects.
Go has a non-moving GC.
Thank you very much for the information
According to the methods used in this article, Clojure should be close to Java:
github.com/Taqmuraz/speed-table/is...
On my machine Clojure test takes 373ms. If I do benchmarking wrong, let me know