C and C are really so fast?

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 (

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.1.11	1 sec
Python 3	pypy 3.8.13	1.6 sec
Clojure	1.10.2	9 sec
Python 3	cpython 3.10.12	26 sec
Ruby	3.0.2p107	38 sec

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.1.11

1 sec

Python 3

pypy 3.8.13

1.6 sec

Clojure

1.10.2

9 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

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

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

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.

The above is the detailed content of C and C are really so fast?. For more information, please follow other related articles on the PHP Chinese website!