Why does C/C++ rule the compiled languages?

[GWestphal]

What is it about C/C++ that has left it the dominant language for the past umpteen years?

Why hasn't it been usurped by anything else? What makes it so good? What could be added to make it better?

 

[IHateMyJob2004]

Every major software product out there supports C/C++ libraries. Consider that the moat. The thing that will keep C/C++ as the primary force. The only other thing so widely entrenched is Java. it's more than core functionality. It is the functionality that company after company has laid over the top of C/C++.

I guess I should invert. What other languages out there could overtake C/C++ and Java?

When there is a next big language, it is really going to take coding time down from where Java stands right now. What can be done in Java in 1 line would take 3+ in C/C++. The same improvement needs to be made in any potential language down the road.

PS: Joe Rossi, I am drinking some heavy stuff right now.

 

[masteryoda34]

Performance - The way C works is very close to the way that actual hardware typically works. This makes it efficient. It is also a compiled language which executes natively, whereas Java and many others run inside a virtual machine or are interpreted.

 

[degibson]

Oh dear god, not this again.

 

[Kirby]

Oh dear god, not this again.

We haven't had a good language flamefest in a while.

 

[IHateMyJob2004]

Performance - The way C works is very close to the way that actual hardware typically works. This makes it efficient. It is also a compiled language which executes natively, whereas Java and many others run inside a virtual machine or are interpreted.

Java compiles at runtime. Because of this it can actually run faster than C/C++ code since it converts the binary at runtime into native code. Java is interpreted once. After the first pass through any class it can actually run faster than C/C++.

Oh dear god, not this again.

Ummm ya ..... I'll stop now.

 

[Merad]

What is it about C/C++ that has left it the dominant language for the past umpteen years?

Momentum. A competitor would have to offer significant advantages to convince enough people to switch over. There are thousands of libraries out there for C and C++. Most of your middleware (3d engines, game engines etc) is written in one of the two, not to mention basically all of your APIs for interacting with the major operating systems.

 

[EagleKeeper]

Performance - The way C works is very close to the way that actual hardware typically works. This makes it efficient. It is also a compiled language which executes natively, whereas Java and many others run inside a virtual machine or are interpreted.

Java compiles at runtime. Because of this it can actually run faster than C/C++ code since it converts the binary at runtime into native code. Java is interpreted once. After the first pass through any class it can actually run faster than C/C++.

Oh dear god, not this again.

Ummm ya ..... I'll stop now.

Please explain how doing the compilation during runtime will improve the speed over having the code already precompiled.

The cost of a compiler is not cheap. For a small program it may be insignificant, but a large program can not stand the hit.

Compilers are supposed to convert the source code into native binary targeted for the processor. so what is the miracle that Java is doing vs any other compiler package?

 

[Markbnj]

Who says C++ is still the dominant language, and how is that measured? I'd be surprised if more work isn't being done, by more developers, in scripting languages like javascript and php.

 

[Leros]

Java compiles at runtime. Because of this it can actually run faster than C/C++ code since it converts the binary at runtime into native code. Java is interpreted once. After the first pass through any class it can actually run faster than C/C++.



Ummm ya ..... I'll stop now.

Sometimes true, not always true.

Java performance is getting pretty good, but my experience seems to show that C/C++ is still much faster than Java.

 

[SunnyD]

What other languages are human readable, compile down to near machine-size code, allow portability, and allow inline ASM?

 

[PhatoseAlpha]

Er, I he asked why C/C++ rule the compiled languages. At least, that's what the thread title says. C++ vs Java, entertaining as it always is, isn't really what he's asking if I understand right.

Why C++, not Pascal or Fortran or Haskell or D or even LISP?

That said, I imagine the answer is probably simple inertia, as already stated. It's hard to displace a language as widely used as the C derivatives. No matter how much nicer the language might be to work with, without the libraries why bother?

 

[Markbnj]

Er, I he asked why C/C++ rule the compiled languages. At least, that's what the thread title says. C++ vs Java, entertaining as it always is, isn't really what he's asking if I understand right.

Actually, he did, so that makes my comment irrelevant as well.

I would argue that one of the reasons it hasn't been replaced is that it's good enough. There hasn't been a need to replace it. It's very well known. It's standardized. It's flexible enough to adapt to nearly any platform. Perhaps most importantly, the overall demand for compiled code is probably going down, so there wouldn't be tons of pressure to create a new language.

 

[Cogman]

Actually, he did, so that makes my comment irrelevant as well.

I would argue that one of the reasons it hasn't been replaced is that it's good enough. There hasn't been a need to replace it. It's very well known. It's standardized. It's flexible enough to adapt to nearly any platform. Perhaps most importantly, the overall demand for compiled code is probably going down, so there wouldn't be tons of pressure to create a new language.

A lot of work has gone into making C/C++ one of the fastest languages out there. Couple that with the fact that it has been around forever and you quickly see why it is one of the more popular languages.

Other languages of the era simply weren't all that great. Pascal, for example, feels extremely verbose and, quite frankly, looks ugly compared to C/C++. Fortran, while fast, was (if you can imagine it) a step down in abstraction from C/C++. COBOL has its problems as well.

For the time, C/C++ were some of the best choices around.

Tradition is the main reason. But it is also nice to have a lot of control over what goes into a project. By using a .NET language, for example, you get the huge runtime along with your small hello world program. C/C++ are just about the only options to escape such issues. (Ok, there is still a C/C++ runtime, however, you don't even have to use that if you don't want to.)

D is a language that tries to do right what C/C++ got wrong. Since C/C++ so widely deployed they can't easily go back and fix nuisances. IMO, D is never going to overtake C/C++. It came to the game way too late and thus probably isn't going to see main stream acceptance. Some of the stuff it tries to do make it more closely related to Java than to C/C++.

In short, C/C++ are so popular because they were the best option for their time and are now traditionally the language to use.

 

[Train]

Please explain how doing the compilation during runtime will improve the speed over having the code already precompiled.

I've seen benchmarks done that show Intermediate langs like MSIL and Java Byte code do indeed outperform native code because CPU's have outpaced bandwidth so fast that it can load something small, compile, and run faster than native code can load something large, and run. Granted, these can be special cases, but it's been proven. And the further the push into multi-theading/multi-cored architectures, the more likely intermediade code will be to outperform native code.

The cost of a compiler is not cheap. For a small program it may be insignificant, but a large program can not stand the hit.

both Java and .Net runtimes compile "just in time", and the size of the overall program is irrelevant. It only compiles methods as needed, and only the first time each is called.

Compilers are supposed to convert the source code into native binary targeted for the processor. so what is the miracle that Java is doing vs any other compiler package?

They can target x64, x86, or ARM, or even AMD vs Intel optimizations on the fly that wouldn't be available to a more generic codebase. They can also make decisions based on how much memory is available, how many cores, etc.

 

[Sureshot324]

I've seen benchmarks done that show Intermediate langs like MSIL and Java Byte code do indeed outperform native code because CPU's have outpaced bandwidth so fast that it can load something small, compile, and run faster than native code can load something large, and run. Granted, these can be special cases, but it's been proven. And the further the push into multi-theading/multi-cored architectures, the more likely intermediade code will be to outperform native code.

both Java and .Net runtimes compile "just in time", and the size of the overall program is irrelevant. It only compiles methods as needed, and only the first time each is called.

They can target x64, x86, or ARM, or even AMD vs Intel optimizations on the fly that wouldn't be available to a more generic codebase. They can also make decisions based on how much memory is available, how many cores, etc.

The java client VM precompiles "hot spots" (parts of the program that will run a lot, such as loops) into native machine code when the program is launched. The rest of the program runs through a translative virtual machine, meaning every statement is compiled to native as it runs.

The java server VM precompiles the entire program into native code when it is launched, but even then, it is generally somewhat slower than C++.

There are some rare cases where Java has been shown to be faster than C++. This is because the Java VM can do some optimizations at runtime that wouldn't generally be done on a generic C++ executable but could be done if the programmer really wanted to. These are very specific cases though and in the real world Java is always going to be slower than a well coded C++ app.

Debian has an interesting site that does a speed comparison of all the major programming languages running on Debian. They do various CPU intensive benchmarks keeping the source code as close to the same as possible. C#/.NET is at an obvious disadvantage here since it's running on Mono.

http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php

 

[Sureshot324]

I'm assuming the OP means compiled into native code, since Java and C# are also compiled, but into byte code. IMO this is because C++ is actually quite close to being the perfect programming language for native code. Java and C#, the 2 most popular programming languages today (not including web stuff), are very similar to C++.

Some of the aspects of it that are now considered non desirable can be ignored. For example, operator overloading is now generally considered a bad idea, even by the creator of C++ himself. No modern programming language has it, but if you are using C++ you can just write normal functions instead.

More modern programming languages generally have garbage collectors and lack pointers, but if you're programming for speed (and if you're using C++ today you probably are) then you WANT pointers and you'll want to handle garbage collection yourself.

Overall I think the reason Java and C# have become so popular is not because the languages themselves are easier to use, but because if the huge standard libraries they have. In C++ the standard library is quite small, and for a lot of things you'll have to look for 3rd party libraries, which may be hard to find, and are going to be written in a different style, may be hard to learn how to use, etc..

.NET and Java have HUGE standard libraries and pretty much anything you would want to do is in there.

C++ still rules the compiled to native languages because programming languages really haven't changed much over the years, so there isn't much reason to replace it. The only other contender I can see is Objective-C, but it has only really gained traction in the Mac world.

 

[eLiu]

The java client VM precompiles "hot spots" (parts of the program that will run a lot, such as loops) into native machine code when the program is launched. The rest of the program runs through a translative virtual machine, meaning every statement is compiled to native as it runs.

The java server VM precompiles the entire program into native code when it is launched, but even then, it is generally somewhat slower than C++.

There are some rare cases where Java has been shown to be faster than C++. This is because the Java VM can do some optimizations at runtime that wouldn't generally be done on a generic C++ executable but could be done if the programmer really wanted to. These are very specific cases though and in the real world Java is always going to be slower than a well coded C++ app.

Debian has an interesting site that does a speed comparison of all the major programming languages running on Debian. They do various CPU intensive benchmarks keeping the source code as close to the same as possible. C#/.NET is at an obvious disadvantage here since it's running on Mono.

http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php

Some of those results are misleading. Like this:
http://shootout.alioth.debian.org/u64q/performance.php?test=spectralnorm
First, no one uses the power method to compute eigenvalues; it's incredibly unstable & ill-conditioned.

Second, the matrix size is very relevant here and it isn't stated.

Third, the core of the power method is a matrix-vector multiply, A*x. Optimized BLAS libraries (GOTO2, MKL) exist that will beat like all of the implementations I looked at in that site for problem sizes >15-20 or so.

Fourth, there shouldn't be much of a difference between fortran and C here if you use the restrict keyword (in C) and pass the right compiler options.

That said, if they were comparing the "naive" matrix-vector multiply across Java and C
for i<m
for j<n
y += A[i*n +j]*x[j]

I would've expected Java and C to be quite close; the difference would only be in the compiler. Java's JIT should compile that A*x operation and it will go smoothly from there. The JIT really shines when you're executing a small core piece of linear code repeatedly.

When there's a lot more branching, like here:
http://shootout.alioth.debian.org/u64/performance.php?test=regexdna
or
http://shootout.alioth.debian.org/u64/performance.php?test=meteor
The JIT may become a lot less effective.

And it's worth noting that Java's memory usage is like at least 4-5x that of C in all the tests, if not more like 10x greater.

But yeah "managed code" can beat compiled code in some places. There was recently a splash in the scientific computing community when Java or C# (i forget...) executed FFT faster than the well-known FFTW library in like one or two instances. Managed code does throw the compiler some extra advantages in some places. For example, if it realizes that a certain code path is way more likely, it can just compile that central path and run it effectively branch-free. It will be very slow when that chosen path isn't executed, but if that happens super rarely/never, then no worries. I don't think this type of functionality exists outside of research JITs yet but it could be coming. So don't be so fast to bash managed code--it has its place and I'm certainly interested to see how/if it will impact the high-performance computing community.


That all said, C FOR LIFE BABY OH YEAH! haha

 

[igouy]

Some of those results are misleading. Like this:
http://shootout.alioth.debian.org/u64q/performance.php?test=spectralnorm
First, no one uses the power method to compute eigenvalues; it's incredibly unstable & ill-conditioned.

And why would that make those measured program times misleading?

Second, the matrix size is very relevant here and it isn't stated.

N=5,500

Third, the core of the power method is a matrix-vector multiply, A*x. Optimized BLAS libraries (GOTO2, MKL) exist that will beat like all of the implementations I looked at in that site for problem sizes >15-20 or so.

So you think those results are misleading because they don't tell you about all the other programs that weren't measured - they only tell you about the programs that were measured?

Fourth, there shouldn't be much of a difference between fortran and C here if you use the restrict keyword (in C) and pass the right compiler options.

Until someone contributes that super C program with "the right compiler options" ...

-snip-

And it's worth noting that Java's memory usage is like at least 4-5x that of C in all the tests, if not more like 10x greater.

No, not "like at least 4-5x"

reverse-complement Java 311,496KB and C 374,196KB

regex-dna Java 606,432KB and C 317,424KB

k-nucleotide Java 397,356KB and C 180,484KB

mandelbrot Java 68,232KB and C 26,704KB

 

[trexpesto]

Momentum. A competitor would have to offer significant advantages to convince enough people to switch over. There are thousands of libraries out there for C and C++. Most of your middleware (3d engines, game engines etc) is written in one of the two, not to mention basically all of your APIs for interacting with the major operating systems.

Ha that's funny, I would have called it "inertia".

Speaking of games, and the OP (and forgetting the 'compiled' part):
If you want to talk speed of development and succinctness of code, Python is hard to beat.
* Used in games and especially mods to control those compiled libs. EveOnline.
* Lots of web stuff where the big performance overhead is remote calls. YouTube.
* Really dangerous giant industrial robots. Check this video, it is a really hairy cool project: http://www.pygame.org/news.html and search for
"Hard Real-time Python, or, Giant Robots of Doom."

Program development using Python is 5-10 times faster than using C/C++, and 3-5 times faster than using Java.

http://www.python.org/doc/essays/omg-darpa-mcc-position.html

I'm back on Java now, sigh.

 

[Schmide]

I may be wrong and it's not worth it. I'm tired

 

[HumblePie]

Why C/C++?

1) It has compilers for just about every machine in existence

2) It can be optimized for the best performance on any given hardware. This is especially important when dealing with embedded systems.

3) Tons of support and libraries for it have been built over the years.

4) Easy to learn and work with. The language syntax is fairly easy to learn and implement. Although many programmers do not write clean code that is easy to follow with the language, it can be done unlike some languages where you have to write in some really strange constructs that aren't always intuitive. COBOL and Python has constructs like that for example.

5) Inline assembly ability to allow even further code optimizations and the ability to write hardware drivers.


That's the top 5 reasons I think of for why C/C++ has been king of the hill for a long time. Although certain areas of computer programming have switched away from it. Internet apps and web sites for one. Microsoft has pushed C# hard over the last few years and with certain platforms and tools made for it that aren't made for C/C++ that makes many programmers want to switch for ease of programming. Some of the newer languages can be easier to program in that is true. However that can be a double edge sword. Sometimes you are stuck using a tool or construct for another language that prevents you from doing something you really want to do. C/C++ does not have that limitation.

 

[degibson]

C++: All the power of assembly language, combined with all the elegance of assembly language and all the useful inheritance features of assembly language.