Reply to: C# vs C++ performance

[AtW]

If it automatically sales then AtW would be rich and he wouldn't have to scrimp and save for his beloved sofa.

I'll have some shrimp on me sofa

[doodab]

I'd love to know how C# compared, they don't mention the test platform (that I could see) but I assume Linux. For a paper I would expect to know:

• Hardware platform
• Operating system
• C++ compiler
• Was C++ 32 or 64 bit
• Java version

Are those details in there somewhere? For it to be a 100% credible paper we should be able to repeat the experiment. I'm not disputing the results, but such things are important. Are those data available?

It does miss a bit of detail but you can repeat the experiment by downloading the source code and running it yourself on whatever platforms you like, which is likely to give you more relevant results IMO.

[d000hg]

I'd love to know how C# compared, they don't mention the test platform (that I could see) but I assume Linux. For a paper I would expect to know:

• Hardware platform
• Operating system
• C++ compiler
• Was C++ 32 or 64 bit
• Java version

Are those details in there somewhere? For it to be a 100% credible paper we should be able to repeat the experiment. I'm not disputing the results, but such things are important. Are those data available?

[doodab]

Interesting paper from google comparing C++, Java, Scala and their own language Go here:

https://days2011.scala-lang.org/site...s3-1-Hundt.pdf

[d000hg]

I think you mean it automatically scales but in reality it doesn't. The vast majority of the work is a simple process which can be run in parallel.

That's what I meant by automatically scaling.

[eek]

SKA is an application which automatically sales, as are nearly all web-apps. Making arbitrary code multi-threaded effectively is hard.

If it automatically sales then AtW would be rich and he wouldn't have to scrimp and save for his beloved sofa.

I think you mean it automatically scales but in reality it doesn't. The vast majority of the work is a simple process which can be run in parallel.

[d000hg]

W

SKA C# code runs on a cluster with 1 TB of RAM and 144 cores.

HTH

SKA is an application which automatically sales, as are nearly all web-apps. Making arbitrary code multi-threaded effectively is hard.

[BlasterBates]

I assume you are referring to solaris studio. The debugger(dbx) isn't actually written in Java at all, your problem is the IDE which is IIRC an old version of netbeans and quite likely tulip.

Have you tried using the latest version? Instructions to set it up with sun studio compiler and debugger can be found Configuring the NetBeans IDE for C/C++/Fortran - NetBeans IDE 7.0 here (solaris studio 12 is a way down the page)

Thx for that I'll check it out, good tip.

One problem is the app is massive, even with the old native motif debugger it was slow, but bearable. But You're right we should research it a bit and see if we can't get a better version. With normal apps it's a bit slow but generally OK.

I've been meaning to hunt around for something better, maybe some open source thing, or get niftier with dbx.

[doodab]

The trouble is there's a lot of propoganda about VM' s being just as fast as a native compled code. That's baloney and always will be. Java and C# are 3GL languages just like any other that have their own runtime environments, there's an overhead and with a large amount of data that is very noticeable. I have to face a horribly slow Java app everyday that slows my productivity down. These 3GL's are great for User interfaces but shouldn't really be used for serious "Data processing"; you simply throw away CPU "bandwidth".

I assume you are referring to solaris studio. The debugger(dbx) isn't actually written in Java at all, your problem is the IDE which is IIRC an old version of netbeans and quite likely tulip.

Have you tried using the latest version? Instructions to set it up with sun studio compiler and debugger can be found Configuring the NetBeans IDE for C/C++/Fortran - NetBeans IDE 7.0 here (solaris studio 12 is a way down the page)

[BlasterBates]

The trouble is there's a lot of propoganda about VM' s being just as fast as a native compled code. That's baloney and always will be. Java and C# are 3GL languages just like any other that have their own runtime environments, there's an overhead and with a large amount of data that is very noticeable. I have to face a horribly slow Java app everyday that slows my productivity down. These 3GL's are great for User interfaces but shouldn't really be used for serious "Data processing"; you simply throw away CPU "bandwidth".

[AtW]

I ran it on a machine with dual cores. And it only used one. So there's your money wasted then.

Who is making general purpose single cores CPUs anymore? Most of such CPUs are multi cores and for all intents and purposes dual cores are free.

Any code these days that aims to have high performance should not only be parallel to support multiple cores on the same box, but also (if that is required) multiple boxes working in sync towards same goal.

SKA C# code runs on a cluster with 1 TB of RAM and 144 cores.

HTH

[doodab]

Nice work.

I can't see that any of this is doing any extra bounds checking or anything fundamentally different in the algorithms, so it has to come down to general inefficiencies of the runtime. To be honest, as much as I'm a C++ programmer and obviously wanted my side to win, I'm kind of suprised. I was expecting with all the improvements of JIT and modern processors to be getting about 10% at best with C++.

/clrure is a bit pointless really; without the ability to seemlessly integrate with native code I'd never bother with C++ .NET, and just use C#. If anything C# is probably easier for an experienced C++ programmer to figure out than C++ .NET.

The algorithms are probably the same, but array bounds checking is done by the runtime, it actually generates extra instructions to do it. One of the common optimisations is eliminating the checks when the compiler and VM can guarantee that it won't be a problem e.g. a for array access in a loop with upper bound = size of the array etc, so without looking at the libraries & generated code in detail it's impossible to tell if that is happening or not.

I would still argue that for the average server side business or web app even a 2x speedup on something like that is irrelevant because what you are speeding up only represents a small fraction of where the time goes anyway. And as you pointed out the difference between good code and average code can be worth twice as much as the difference between languages, which means I'm probably best off sticking with Java.

[VectraMan]

x2 performance can be achieved by buying double number of cores - usually that's cheaper than paying for x2 time of programmer dealing with C++ buggy code.

I ran it on a machine with dual cores. And it only used one. So there's your money wasted then.

[VectraMan]

I meant identical code as /clrure. I had a look at sorting small structures that contain a key & array index as I think that's more like something I would do, and disregarding setup, allocation, copying etc, just timing the call to the sort routines I got:

Native takes ~70ms for 1/2 million items
C++ CLR takes ~150ms
C# takes ~ 400ms using Array.Sort<T> and IComparer
C# with ~150ms using the "indirect" sort Array.Sort<int, T>

So the native code seems to have a 2x advantage and the best C# method seems to vary quite a bit depending on what you are sorting i.e. for the downloaded code the use of a delegate was fastest, I found IComparer faster and the indirect sort faster still.

I will knock something similar up in Java later if I can be arsed.

Edit: Java takes about 500ms out of the box (the code is a JUnit test BTW, force of habit) but can be reduced quite a lot by e.g. using latest VM instead of 1.5, tuning vmopts, so I'm down to sub 200ms now.

Nice work.

I can't see that any of this is doing any extra bounds checking or anything fundamentally different in the algorithms, so it has to come down to general inefficiencies of the runtime. To be honest, as much as I'm a C++ programmer and obviously wanted my side to win, I'm kind of suprised. I was expecting with all the improvements of JIT and modern processors to be getting about 10% at best with C++.

/clrure is a bit pointless really; without the ability to seemlessly integrate with native code I'd never bother with C++ .NET, and just use C#. If anything C# is probably easier for an experienced C++ programmer to figure out than C++ .NET.

[eek]

x2 performance can be achieved by buying double number of cores - usually that's cheaper than paying for x2 time of programmer dealing with C++ buggy code.

HTH

only if the code runs in parallel or is sensibly threaded.

Buying an x core processor is probably not much use for your average single thread noddy c# application. For most other uses though faster hardware is far more likely to fix a problem