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 assembly code, nothing may compete in speed with C or C++. And, nobody seem to challenge that common belief.
Computing performance
Arithmetic operations with numbers, obviously, must work significantly faster in C than in any other language. But do they?
Some time ago I decided to write a set of simple benchmarks for many different languages to see, how large difference in speed really is.
Idea was simple : to find the sum of the one billion integer numbers, starting from zero, using straight-forward computing. Some compilers (rustc, for example) replace such simple cycles with formula expression, which, of course, will be evaluated in the constant time. To avoid that with such compilers. I used similar in costs operations with numbers, such as bitwise or.
After I got results, I was surprised very much. My world view turned upside down, and I had to reconsider everything I knew about speed of programming languages.
You may see my results in the table below :
Linux 64bit, 1.1 GHz CPU, 4GB RAM
| Language | compiler/version/args | time |
|---|---|---|
| Rust (bitwise or instead of +) | rustc 1.75.0 with -O3 | 167 ms |
| C | gcc 11.4.0 with -O3 | 335 ms |
| NASM | 2.15.05 | 339 ms |
| Go | 1.18.1 | 340 ms |
| Java | 17.0.13 | 345 ms |
| Common Lisp | SBCL 2.4.11.26 | 363 ms |
| Clojure | 1.10.2 | 373 ms |
| Python 3 | pypy 3.8.13 | 1.6 sec |
| Python 3 | cpython 3.10.12 | 26 sec |
| Ruby | 3.0.2p107 | 38 sec |
All tests sources you may find here :
https://github.com/Taqmuraz/speed-table
So, as we may see, C is not very much faster than Java, difference is about 3%. Also, we see that other compiled languages are very close in arithmetic operations performance to C (Rust is even faster). Dynamic languages, compiled with JIT compiler, show worse results -- mostly because arithmetic operations are wrapped into dynamically dispatched functions there.
Interpreted dynamic languages with no JIT compiler show worst performance, not a surprise.
Memory allocation performance
After that crushing defeat, C fans would say that memory allocation in C is very much faster, because you are allocating it straight from the system, not asking GC.
Now and after I will use GC term both as garbage collector and as managed heap, depending on the context.
So, why people think, that GC is so slow? In fact, GC has pre-allocated memory, and allocation is simply moving pointer to the right. Mostly GC fills allocated memory by zeros using system call, similar to memset from C, so it takes constant time. While memory allocation in C takes undefined time, because it depends on the system and already allocated memory.
But, even considering this knowledge, I could not expect so good results from Java, which you may see in following tables :
| 1.1 GHz 2 cores, 4 GB RAM |
| Running tests on single thread. |
| Result format : "Xms-Yms ~Z ms" means tests took from X to Y milliseconds, and Z milliseconds in average |
Allocating integer arrays
| integers array size | times | Java 17.0.13 new[] | C gcc 11.4.0 malloc | Common Lisp SBCL 2.1.11 make-array |
|---|---|---|---|---|
| 16 | 10000 | 0-1ms, ~0.9ms | 1-2ms, ~1.2ms | 0-4ms, ~0.73ms |
| 32 | 10000 | 1-3ms, ~1.7ms | 1-3ms, ~1.7ms | 0-8ms, ~2.ms |
| 1024 | 10000 | 6-26ms, ~12ms | 21-46ms, ~26ms | 12-40ms, ~7ms |
| 2048 | 10000 | 9-53ms, ~22ms | 24-52ms, ~28ms | 12-40ms, ~19ms |
| 16 | 100000 | 0-9ms, ~2ms | 6-23ms, ~9ms | 4-24ms, ~7ms |
| 32 | 100000 | 0-14ms, ~3ms | 10-15ms, ~11ms | 3-8ms, ~7ms |
| 1024 | 100000 | 0-113ms, ~16ms | 234-1156ms, ~654ms | 147-183ms, ~155ms |
| 2048 | 100000 | 0-223ms, ~26ms | 216-1376ms, ~568ms | 299-339ms, ~307ms |
Allocating instance of the class Person with one integer field.
| how many instances | Java 17.0.3 new Person(n) | C++ g++ 11.4.0 new Person(n) |
|---|---|---|
| 100000 | 0-6ms, ~1.3ms | 4-8ms, ~5ms |
| 1 million | 0-11ms, ~2ms | 43-69ms, ~47ms |
| 1 billion | 22-50ms, ~28ms | process terminated |
All tests sources you may find here :
https://github.com/Taqmuraz/alloc-table
There I tested four languages in total : C, C++, Java and Lisp. And, languages with GC always show better results, though I tested them much stricter, than C and C++. For example, in Java I am allocating memory through the virtual function call, so it may not be statically optimized, and in Lisp I am checking first element of the allocated array, so compiler won't skip allocation call.
Releasing memory
C fans are still motivated to protect their beliefs, so, they say "Yes, you do allocate memory faster, but you have to release it after!".
True. And, suddenly, GC releases memory faster, than C. But how? Imagine, we made 1 million allocations from GC, but later we have only 1000 objects referenced in our program. And, let's say, those objects are distributed through all of that long span of memory. GC does stack tracing, finding those 1000 "alive" objects, moves them to the previous generation heap peak and puts heap peak pointer after the last of them. That's all.
So, no matter, how many objects you allocate, GC's work time is decided by how many of them you keep after.
And, in opposite with that, in C you have to release all allocated memory manually, so, if you allocated memory 1 million times, you have to make 1 million release calls as well (or you are going to have memory leaks). That means, O(1)-O(n) of GC against O(n) or worse of C, where n is the number of allocations happened before.
Summary
So, I want to consolidate the victory of garbage collected languages over C and C++. Here is the summary table :
| demands | languages with GC | C/C++ |
|---|---|---|
| arithmetic | fast with JIT | fast |
| allocating memory | fast O(1) | slow |
| releasing memory | fast O(1) best case, O(n) worst case | O(n) or slower |
| memory safe | yes | no |
Now we may see -- garbage collection is not a necessary evil, but the best thing we could only wish to have. It gives us safety and performance both.
Tribute to C
While C does show worse results on my tests, it is still an important language and it has own application field. My article does not aim for C rejection or obliteration. C is not bad, it is just not that superior as people think. Many good projects collapsed only because some people decided to use C instead of Java, for example, because they have been told that C is very much faster, and Java is incredibly slow because of garbage collection. C is good, when we write very small and simple programs. But, I would never recommend writing complex programs or games with C.
C++ is different
C++ is not simple, is not flexible, has overloaded syntax and too much complicated specification. Programming with C++ you will not implement own ideas but fight with compiler and memory errors 90% of the time.
This article does aim for rejection of C++, because speed and performance are only excuses people give for using this language in software development. Using C++, you are paying with your time, your program performance and your mental health. So, when you have choice between C++ and any other language, I hope you choose the last one.
Top comments (26)
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.
Whether compilers internally take such an intermediate step is both compiler-specific and irrelevant, since the object files contain already machine code, and the machine code is also what is executed and determines performance.
You are projecting.
False. You just seem unable to read properly, and apparently you are emotionally overwhelmed by sincere criticism since you feel like I'd attack your personality rather than your stupid claims, which is false. So far I kept expecting more from you before you requested me to dumb down things for you multiple times.
However, since you asked again, I'll just lay it out as if you were mentally retarded — you are clearly acting as such:
You asked me to
I answered, among other things:
I was just trying to help you and other people new to programming. You might be resistant to learning thus a waste of time, but others might not. What is definitely a waste of time is reading your article...
Nah, I'm sincere. But you are so insincere and wrong about everything, it is disgusting.
You have nothing like that, as I have already provided valid arguments for.
Yes, I just happen to be disgusted by such levels of stupidity and willful ignorance, it's a personality trait.
Ah, feel free to check out my project: github.com/xamidi/pmGenerator
Originally, I just came here today for this comment where I mentioned it. Unfortunately, I got baited by your bullshit article and thought I'd do a good deed today and debunk it.
All that I wrote about that actually useful benchmark project and how things work, insane that you ignore it all. It strongly suggests that you are trolling, but seeing that you put out that article and repo, clearly being at least trying, you just must be super delusional.
I guess your self-description as an "in a healthy way arrogant person" is deeply twisted. More like full of narcissistic delusion, with a Dunning-Kruger of doom.
Edit: Deletes embarrassing comments, proceeds with baseless crap hereafter.
Can't even make this shit up, lol.
:D said guy who also said "I don't waste time on trivial matters".
Really you know a lot about narcissism.
You are a joke.
Also, if you start using dirty tricks - I checked your github, it is a shame.
That's what I call an amateur.
Seems you really don't know C++, because your code is a disaster.
I don't know how to take you seriously after that.
Incase you didnt get the notification, I made a version of class_alloc that also uses std::allocator for comparison as you requested.
dev.to/plotarmouredtitan/comment/2...
I wasn't online, sorry, thanks for your code. I answered in that thread
@plotarmouredtitan FYI, one of the deleted comments of Taqmuraz was
(apart from calling C++ code on expert level "a disaster"),
so it's clearly pointless trying to teach them C++ since they're just trying to hate on it.
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
Some comments may only be visible to logged-in visitors. Sign in to view all comments.