C++ Performance Vs. Java/C#

C++ performance vs. Java/C#

Generally, C# and Java can be just as fast or faster because the JIT compiler -- a compiler that compiles your IL the first time it's executed -- can make optimizations that a C++ compiled program cannot because it can query the machine. It can determine if the machine is Intel or AMD; Pentium 4, Core Solo, or Core Duo; or if supports SSE4, etc.

A C++ program has to be compiled beforehand usually with mixed optimizations so that it runs decently well on all machines, but is not optimized as much as it could be for a single configuration (i.e. processor, instruction set, other hardware).

Additionally certain language features allow the compiler in C# and Java to make assumptions about your code that allows it to optimize certain parts away that just aren't safe for the C/C++ compiler to do. When you have access to pointers there's a lot of optimizations that just aren't safe.

Also Java and C# can do heap allocations more efficiently than C++ because the layer of abstraction between the garbage collector and your code allows it to do all of its heap compression at once (a fairly expensive operation).

Now I can't speak for Java on this next point, but I know that C# for example will actually remove methods and method calls when it knows the body of the method is empty. And it will use this kind of logic throughout your code.

So as you can see, there are lots of reasons why certain C# or Java implementations will be faster.

Now this all said, specific optimizations can be made in C++ that will blow away anything that you could do with C#, especially in the graphics realm and anytime you're close to the hardware. Pointers do wonders here.

So depending on what you're writing I would go with one or the other. But if you're writing something that isn't hardware dependent (driver, video game, etc), I wouldn't worry about the performance of C# (again can't speak about Java). It'll do just fine.

One the Java side, @Swati points out a good article:

https://www.ibm.com/developerworks/library/j-jtp09275

What is faster- Java or C# (or good old C)?

The key piece of information in the question is this:

Every percent we can shave off our
processing time saves us tens of
thousands of dollars per year

So you need to consider how much it will cost to shave each percent off. If that optimization effort costs tens of thousands of dollars per year, then it isn't worth doing. You could make a bigger saving by firing a programmer.

With the right skills (which today are rarer and therefore more expensive) you can hand-craft assembler to get the fastest possible code. With slightly less rare (and expensive) skills, you can do almost as well with some really ugly-looking C code. And so on. The more performance you squeeze out of it, the more it will cost you in development effort, and there will be diminishing returns for ever greater effort. If the profit from this stays at "tens of thousands of dollars per year" then there will come a point where it is no longer worth the effort. In fact I would hazard a guess you're already at that point because "tens of thousands of dollars per year" is in the range of one salary, and probably not enough to buy the skills required to hand-optimize a complex program.

I would guess that if you have code already written in C, the effort of rewriting it all as a direct translation in another language will be 90% wasted effort. It will very likely perform slower simply because you won't be taking advantage of the capabilities of the platform, but instead working against them, e.g. trying to use Java as if it was C.

Also within your existing code, there will be parts that make a crucial contribution to the running time (they run frequently), and other parts that are totally irrelevant (they run rarely). So if you have some idea for speeding up the program, there is no economic sense in wasting time applying it to the parts of the program that don't affect the running time.

So use a profiler to find the hot spots, and see where time is being wasted in the existing code.

Update when I noticed the reference to the code being "multithreaded"

In that case, if you focus your effort on removing bottlenecks so that your program can scale well over a large number of cores, then it will automatically get faster every year at a rate that will dwarf any other optimization you can make. This time next year, quad cores will be standard on desktops. The year after that, 8 cores will be getting cheaper (I bought one over a year ago for a few thousand dollars), and I would predict that a 32 core machine will cost less than a developer by that time.

Java vs C#: Are there any studies that compare their execution speed?

The best comparison that I am aware of is The Computer Language Benchmarks Game.

It compares speed, memory use and source code size for (currently) 10 benchmarks across a large number of programming languages. The implementations of the benchmarks are user-submitted and there are continuous improvements, so the standings shift around somewhat.

The comparison is currently openjdk vs C# .NET Core.

Currently it is close, but .NET Core is slightly faster on most benchmarks.

Performance of C++ calls to Java code vs C# code

I cannot offer you a definitive answer, but I have done JNI to C library calls (not the reverse), .NET to wrapped Java library calls, and .NET to .NET library calls. I don't have official numbers on any of them, but the .NET to .NET calls, whether managed C++ or C# were both the easiest and fastest. Because they were both .NET, there was a common set of datatypes supported on both sides. In the other instances, there was lots of ugly marshaling code required to convert between datatypes in different languages. The .NET Framework was designed with the intent that calls between different .NET libraries would be transparent of their original language and it does this very well.

Another consideration is that in a high-volume environment, the performance of the individual libraries may be a bigger concern than the interop performance. In other words, if the Java library is 25% faster than the C# library, it may make sense to use the Java library even if the interop with C# is faster and easier than with Java.

C++ (Intel) vs Java (Hotspot) vs C# benchmark questions (code and results included)

You've got a logical problem in your C++ code which uses QueryPerformanceFrequency:

PCFreq = double(li.QuadPart)/1000000000.0; // <- this is not correct
PCFreq = li.QuadPart;                      // <- this is correct

You should just assign li.QuadPart to PCFreq and do your conversion to milliseconds or nanoseconds in your printing code:

// convert from seconds to milliseconds
cout << GetCounter() * 1000.0 << endl;

With this change I get actual timings for your C++ code. Whether or not these timings are "valid" or useful in making comparisons, I will not comment.

Brute force performance: Java vs C#

The short answer is, the smaller your tasks the greater the relative overhead. The overhead is largely fixed and can be 10 - 1000x higher than the task you are trying to perform. In each task try to perform 10 - 10,000x as much work making the overhead relatively small. Ideally, just divide all your work into N tasks (where N is the number of cores you have e.g. Runtime.getRuntime().availableProcessors() ) That way all your cores will be busy and you won't have to worry about the queue size (it will be 0 ;)

---

Longer answer....

I would make sure you are using the -server in all cases as this can improve the benchmark (or atleast give you more consistent results)

When you make a process multi-threaded you add overhead (locking/synchronization/cache coherency) and in return your tasks can run concurrently. It is very easy to write a program which has far more overhead than it gains by concurrency.

Here is an article I wrote on some of the pitfalls of writing a multi-thread program from a simple example and how a multi-threaded program can be much, much slower (trillions of times slower) http://vanillajava.blogspot.com/2011/11/why-concurency-examples-are-confusing.html

---

Related Topics