Languages faster than C++

Question

It is said that Blitz++ provides near-Fortran performance.

Does Fortran actually tend to be faster than regular C++ for equivalent tasks?

What about other HL languages of exceptional runtime performance? I've heard of a few languages suprassing C++ for certain tasks... Objective Caml, Java, D...

I guess GC can make much code faster, because it removes the need for excessive copying around the stack? (assuming the code is not written for performance)

I am asking out of curiosity -- I always assumed C++ is pretty much unbeatable barring expert ASM coding.

Answer 1

This will depend a lot on the compiler, programmers, whether it has gc and can vary too much. If it is compiled directly to machine code then expect to have better performance than interpreted most of the time but there is a finite amount of optimization possible before you have asm speed anyway.

If someone said fortran was slightly faster would you code a new project in that anyway?

Answer 2

It's usually the algorithm not the language that determines the performance ballpark that you will end up in.

Within that ballpark, optimising compilers can usually produce better code than most assembly coders.

Premature optimisation is the root of all evil

This may be the "common knowledge" that everyone can parrot, but I submit that's probably because it's correct. I await concrete evidence to the contrary.

Answer 3

I wrote this just a few minutes ago:

http://stackoverflow.com/questions/608370/c-string-memory-management/610318#610318

Answer 4

Fortran is faster and almost always better than C++ for purely numerical code. The reason why Fortran is faster is: oldest compiled language (a lot of knowledge in optimizing compilers), it is still THE languages for numerical computations, so many compiler vendors make a living of selling optimizing compilers. There are also other, more technical reasons: Fortran (well, at least Fortran77) does not have pointers, and thus do not have the aliasing problems which plague the C/C++ languages in that domain. Many high performances libraries are still coded in Fortran, with a long (> 30 years) history; neither C or C++ have any good arrays constructs (C is too low level, C++ has as many array libraries as compilers on the planet, which are all incompatible with each other, thus preventing a pool of well tested, fast code).

Answer 5

FORTAN is typically faster than C++ for array processing because of the different ways the languages implement arrays - FORTRAN doesn't allow aliasing of array elements, whereas C++ does. This makes the FORTRAN compilers job easier. Also, FORTRAN has many very mature mathematical libraries which have been worked on for nearly 50 years - C++ has not been around that long!

Answer 6

It all depends on the compiler, take for example the Stalin Scheme compiler, it beats almost all languages in the Debian micro benchmark suite, but do they mention anything about compile times?

No, I suspect (I have not used Stalin before) compiling for benchmarks (iow all optimizations at maximum effort levels) takes a jolly long time for anything but the smallest pieces of code.

Answer 7

Performance of a compiled language is a useless concept: What's important is the quality of the compiler, ie what optimizations it is able to apply. For example, often - but not always - the Intel C++ compiler produces better performing code than g++. So how do you measure the performance of C++?

Where language semantics come in is how easy it is for the programmer to get the compiler to create optimal output. For example, it's often easier to parallelize Fortran code than C code, which is why Fortran is still heavily used for high-performance computation (eg climate simulations).

---

As the question and some of the answers mentioned assembler: the same is true here, it's just another compiled language and thus not inherently 'faster'. The difference between assembler and other languages is that the programmer - who ideally has absolute knowledge about the program - is responsible for all of the optimizations instead of delegating some of them to the 'dumb' compiler.

Eg function calls in assembler may use registers to pass arguments and don't need to create unnecessary stack frames, but a good compiler can do this as well (think inlining or fastcall). The downside of using assembler is that better performing algorithms are harder to implement (think linear search vs. binary seach, hashtable lookup, ...).

Answer 8

What Blitz++ is competing against is not so much the Fortran language, but the man-centuries of work going into Fortran math libraries. To some extent the language helps: an older language has had a lot more time to get optimizing compilers (and , let's face it, C++ is one of the most complex languages). On the other hand, high level C++ libraries like Blitz++ and uBLAS allows you to state your intentions more clearly than relatively low-level Fortran code, and allows for whole new classes of compile-time optimizations.

However, using any library effectively all the time requires developers to be well acquainted with the language, the library and the mathematics. You can usually get faster code by improving any one of the three...

Answer 9

if the code is not written for performance then C# is faster than C++.

A necessary disclaimer: All benchmarks are evil.

Here's benchmarks that in favour of C++.

The above two links show that we can find cases where C++ is faster than C# and vice versa.

Answer 10

the thing with c++ is that it is very close to the hardware level. In fact, you can program at the hardware level (via assembly blocks). In general, c++ compilers do a pretty good job at optimisations (for a huge speed boost, enable "Link Time Code Generation" to allow the inlining of functions between different cpp files), but if you know the hardware and have the know-how, you can write a few functions in assembly that work even faster (though sometimes, you just can't beat the compiler).

You can also implement you're own memory managers (which is something a lot of other high level languages don't allow), thus you can customize them for your specific task (maybe most allocations will be 32 bytes or less, then you can just have a giant list of 32-byte buffers that you can allocate/deallocate in O(1) time). I believe that c++ CAN beat any other language, as long as you fully understand the compiler and the hardware that you are using. The majority of it comes down to what algorithms you use more than anything else.

Answer 11

I interpret this question as "what can make a language faster than C/C++" and there are several ways to do it:

• Better compiler which generates better optimized code. Even another C/C++ compiler can beat yours.
• Better/faster libraries provided with the language. TurboPower software used to sell "optimized RTL" for Turbo Pascal, making your Pascal code faster :)
• Declarative programming constructs. Instead of providing how the code works you tell it what to do and compiler can decide on how to optimize it. Simplest example would be foreach vs for(i=0;i < 10; i++). Compiler can generate better code for foreach since it doesn't have to follow a specific order. If x86 dec instruction was faster than inc instruction than foreach would use reverse loops, which would be faster.
• JIT. Just in time compilation in Java and .NET proven faster than native code on certain scenarios since JIT can do additional optimizations based on runtime values which a static compiler doesn't know about.
• Similarly garbage collection can be more performant than explicit memory cleanup on certain cases.

All these come with downsides and that's why we shouldn't choose a language based on it being fast solely.

Answer 12

C# is much faster than C++ - in C# I can write an XML parser and data processor in a tenth the time it takes me to write it C++.

Oh, did you mean execution speed?

Even then, if you take the time from the first line of code written to the end of the first execution of the code, C# is still probably faster than C++.

This is a very interesting article about converting a C++ program to C# and the effort required to make the C++ faster than the C#.

So, if you take development speed into account, almost anything beats C++.

Skizz

OK, to address tht OP's runtime only performance requirement: It's not the langauge, it's the implementation of the language that determines the runtime performance. I could write a C++ compiler that produces the slowest code imaginable, but it's still C++. It is also theoretically possible to write a compiler for Java that targets IA32 instructions rather than the Java VM byte codes, giving a runtime speed boost.

The performance of your code will depend on the fit between the strengths of the language and the requirements of the code. For example, a program that does lots of memory allocation / deallocation will perform badly in a naive C++ program (i.e. use the default memory allocator) since the C++ memory allocation strategy is too generalised, whereas C#'s GC based allocator can perform better (as the above link shows). String manipulation is slow in C++ but quick in languages like php, perl, etc.

Answer 13

Whether fortran is facter than c++ is a matter of discussion. Some say yes, some say no; I won't go into that. It depends on the compiler, the architecture you're running it on, the implementation of the algorithm ... etc.

Where fortran does have a big advantage over C is the time it takes you to implement those algorithms. And that makes it extremely well suited for any kind of numerical computing. I'll state just a few obvious advatages over C:

• 1-based array indexing (tremendously helpful when implementing larger models, and you don't have to think about it, but just FORmula TRANslate
• has a power operator (**) (God, whose idea was that a power function will do ? Instead of an operator?!)
• it has, I'd say the best supoort for multidimensional arrays of all the languages in the current market (and it doesn't seem that's gonna change so soon) - A(1,2) just like in math
• not to mention avoiding the loops - A=B*C multiplies the arrays (almost like matlab syntax with compiled speed)
• it has parallelism features built into the language (check the new standard on this one)
• very easily connectible with languages like C, phython, so you can make your heavy duty calculations in fortran, while .. whatever ... in the language of your choise, if you feel so inclined
• completely backward compatible (since whole F77 is a subset of F90) so you have whole century of coding at your disposal
• very very portable (this might not work for some compiler extensions, but in general it works like a charm)
• problem oriented solving community (since fortran users are usually not cs, but math, phy, engineers ... people with no programming, but rather problem solving experience whose knowledge about your problem can be very helpful)

Can't think of aynthing else off the top of my head right now, so this will have to do.

Answer 14

D can sometimes be faster than C++ in practical applications, largely because the presence of garbage collection helps avoid the overhead of RAII and reference counting when using smart pointers. For programs that allocate large amounts of small objects with non-trivial lifecycles, garbage collection can be faster than C++-style memory management. Also, D's builtin arrays allow the compiler to perform better optimizations in some cases than C++'s STL vector, which the compiler doesn't understand. Furthermore, D2 supports immutable data and pure function annotations, which recent versions of DMD2 optimize based on. Walter Bright, D's creator, wrote a JavaScript interpreter in both D and C++, and according to him, the D version is faster.

Answer 15

Doing much better than C++ is mostly going to be about making the compiler understand what the programmer means. An example of this might be an instance where a compiler of any language infers that a region of code is independent of its inputs and just computes the result value at compile time.

Another example of this is how C# produces some very high performance code simply because the compiler knows what particular incantations 'mean' and can cleverly use the implementation that produces the highest performance, where a transliteration of the same program into C++ results in needless alloc/delete cycles (hidden by templates) because the compiler is handling the general case instead of the particular case this piece of code is giving.

A final example might be in the Brook/Cuda adaptations of C designed for exotic hardware that isn't so exotic anymore. The language supports the exact primitives (kernel functions) that map to the non von-neuman hardware being compiled for.

Answer 16

Is that why you are using a managed browser? Because it is faster. Or managed OS because it is faster. Nah, hang on, it is the SQL database.. Wait, it must be the game you are playing. Stop, there must be a piece of numerical code Java adn Csharp frankly are useless with. BTW, you have to check what your VM is written it to slag the root language and say it is slow.

What a misconecption, but hey show me a fast managed app so we can all have a laugh. VS? OpenOffice?

Answer 17

You must be using some odd managed XML parser as you load this page then. :)

We continously profile code and the gain is consistently (and this is not naive C++, it is just modern C++ with boos). It consistensly paves any CLR implementation by at least 2x and often by 5x or more. A bit better than Java days when it was around 20x times faster but you can still find good instances and simply eliminate all the System.Object bloat and clearly beat it to a pulp.

One thing managed devs don't get is that the hardware architecture is against any scaling of VM and object root aproaches. You have to see it to believe it, hang on, fire up a browser and go to a 'thin' VM like Silverlight. You'll be schocked how slow and CPU hungry it is.

Two, kick of a database app for any performance, yes managed vs native db.

Answer 18

Ahh... The good old question - which compiler makes faster code?

1. It only matters in code that actually spends much time at the bottom of the call stack, i.e. hot spots that don't contain function calls, such as matrix inversion, etc.

2. (Implied by 1) It only matters in code the compiler actually sees. If your program counter spends all its time in 3rd-party libraries you don't build, it doesn't matter.

3. In code where it does matter, it all comes down to which compiler makes better ASM, and that's largely a function of how smartly or stupidly the source code is written.

With all these variables, it's hard to distinguish between good compilers.

However, as was said, if you've got a lot of Fortran code to compile, don't re-write it.