C# vs. C++ for Scientific Computing

Hi there Sagar_Indurkhya,

Im new to C# by the way but I would say that from what I have seen of C# I think it can be used to perform scientifically if one really wanted.

I mean I don't know what else is required from a language to be considered for scientific use, but as you said the 128 bit decimal data type that C# has is one good reason, because of that kind of precision not found in float or double.

As for pointers and unsafe code I don't know what application they would have to a scientific program, thats not to say they don't, Im saying I dont know! Surely a scientific program is one that carries out scientific tasks, so if it can be coded in one language why not another since its all about how you design and write the code to solve your specific problem. C# has that one advantage of 128bit precision for decimal numbers and a host of mathematical functions, but besides that I cannot tell you why else it should or should not be used.

There might be some problems in the language which I dont know of, maybe in performance that may not be good for scientific applications but then again I don't know, Im just guessing :P


DarkStar
UK

I'm fairly certain that in most benchmarks, math was the main area where .net was significantly slower. Mostly floating point and trigonometry were bad iirc.

Of course, that could be fixed by now.

See Blitz and MTL.

Reason1: C# is practically nonportable(ATM, MS only) . Powerful scientifical mahines and clusters are running unixes and linuxes, not windows, and have no .net (and it would take a lot of time to implement good JIT compilers for 'em)

"Decimal" ,guessing by name, probably should be not 128 bit but some weird and slow kind of BCD, at least if it's properly named. And, in C++ 128-bit precision is not a problem at all. In c++ you have no benefit to have it built-in, custom implementation is as fast. If in c#, custom implementation is slower than built-in, 128-bit numbers is not exactly adwantage, need to have it built-in is opposite.

And of course performance.

Also, how i could separate my integration method(RK4) and my simulator in C#? I guess it's harder than in C++ because probably there's no reliable way to use C++'s memory hacks for it.
All those nice features OOP gives for modularity often offer very small benefit for scientifical programs, becoz 'em is sometimes orthogonal. For example OOP concept doesn't make it significantly easier to separate integrator and simulator, it only helps a bit to make "packages" out of 'em, and to swich integrator at runtime(something that is probably never really needed in practice).
But science may switch to C# under pressure of not having competent C++ programmers....

In summary: C# was designed mainly not for science. That is, it's was the weakest side of C# ,and probably still is, optimizing JIT for math probably doesn't have too big priority on their "todo" list.
Yes, it's probably not a defect of language, but there may be defects in VM design. (say, JVM code by design isn't quite good for science)

Quote:

Original post by Dmytry Reason1: C# is practically nonportable(ATM, MS only) . Powerful scientifical mahines and clusters are running unixes and linuxes, not windows, and have no .net (and it would take a lot of time to implement good JIT compilers for 'em)

Utterly wrong. Before stating incorrect remarks please note DotGNU and the Mono projects. I have tested some C# applications running on various Linux distros as well as FreeBSD. There are even some features that are implemented in those that Microsoft has yet to have working.

C# is also a standard along with the CLI. It was offered to the standards committee not only by Microsoft but by other companies.

Quote:

"Decimal" ,guessing by name, probably should be not 128 bit but some weird and slow kind of BCD, at least if it's properly named.

Wrong.

Quote:

MSDN The decimal keyword denotes a 128-bit data type. Compared to floating-point types, the decimal type has a greater precision and a smaller range, which makes it suitable for financial and monetary calculations. Range: decimal ±1.0 × 10−28 to ±7.9 × 1028 Precision: 28-29 significant digits

Quote:

But science may switch to C# under pressure of not having competent C++ programmers....

And this is where you are deadly wrong. Higher level languages actually allow for BETTER scientists, because they can concentrate on the problem at hand and what they do best, not how to manage memory, create event systems, and other things not related to their field.

I am not saying that C# would be the best for this, just that higher level languages in general will be.

Quote:

In summary: C# was designed mainly not for science.

C# was designed for writing managed applications on top of the CLI/CLR. It is not meant for operating systems, drivers, etc.. but is specialized to application building.

Quote:

That is, it's was the weakest side of C# ,and probably still is, optimizing JIT for math probably doesn't have too big priority on their "todo" list.

Do you just make these things up as you go along? Where do you get this info on optimizing the JIT for math? It's odd because according to their developers and the advancements I've already seen between in C# 1.0 -> 2.0 you are utterly wrong.

Quote:

Yes, it's probably not a defect of language, but there may be defects in VM design. (say, JVM code by design isn't quite good for science)

Defects in VM design? You do realize that C# does not run in a VM right?

Surprising that Python isn't mentioned here, seeing that it has several resources for scientific computation, is widely portable, and is used by several national labs, most notably Lawrence Livermore Natl. Labs

This probably explains why C++ is emerging over C#, since its easy to integrate with Python.

Another thing to take note of is that Decimal isn't quite the same as float or double. It was written primarily for dealing with currency operations because it doesn't have any rounding errors, but it also doesn't allow for high exponents. Here's an exerpt from Microsoft's documentation:

"The binary representation of an instance of Decimal consists of a 1-bit sign, a 96-bit integer number, and a scaling factor used to divide the 96-bit integer and specify what portion of it is a decimal fraction. The scaling factor is implicitly the number 10, raised to an exponent ranging from 0 to 28.

Therefore, the binary representation of a Decimal value is of the form, ((-2⁹⁶ to 2 ⁹⁶)/ 10^{(0 to 28)}), where -2⁹⁶ is equal to MinValue, and 2⁹⁶ is equal to MaxValue."

Operations on Decimals are also quite a bit slower than on floats/doubles, so overall the Decimal struct wasn't really meant for scientific math, but more for financial calculations. Just my two bits worth.

EDIT: Sorry, I guess Saruman already kinda touched on this.

Quote:

Original post by psamty10 This probably explains why C++ is emerging over C#, since its easy to integrate with Python.

Actually Python would push C# not C++.

Currently Python.NET is being worked on and is in far stages by a couple groups. Any application written in Python.NET will seemlessly integrate with any C# application.

So I don't see that as one of the reasons C++ has a larger userbase than C#. I mean note that MANY places including governments, scientific research labs, etc will not use a language or platform until it has fully proven itself... I mean look how long it even took game developers to start using C++ over C. THAT alone is the single biggest reason at the current time that a lot of major development places will not be using C# right now.

Quote:

Original post by TheBluMage Operations on Decimals are also quite a bit slower than on floats/doubles, so overall the Decimal struct wasn't really meant for scientific math, but more for financial calculations. Just my two bits worth.

I totally agree. The major reason for Decimals are in financial systems or other applications needing accurate decimal places, but without large exponents.

Quote:

Original post by Saruman Quote: Original post by Dmytry Reason1: C# is practically nonportable(ATM, MS only) . Powerful scientifical mahines and clusters are running unixes and linuxes, not windows, and have no .net (and it would take a lot of time to implement good JIT compilers for 'em) Utterly wrong. Before stating incorrect remarks please note DotGNU and the Mono projects.

Sure, it will take nearly forever to get to comparable performance. I mean on x86. It will take even longer to get to comparable performance on supercomputers, if it ever will be jit-compiled on supercomputers.

Quote:

I have tested some C# applications running on various Linux distros as well as FreeBSD. There are even some features that are implemented in those that Microsoft has yet to have working. C# is also a standard along with the CLI. It was offered to the standards committee not only by Microsoft but by other companies. Quote: "Decimal" ,guessing by name, probably should be not 128 bit but some weird and slow kind of BCD, at least if it's properly named. Wrong.

So the MS choosen wrong name for that.
Decimal it's decimal, it's storen in binary coded decimal and currently may be *sometimes* used for extremely large numbers if one want to avoid binary->decimal conversion.

Quote:

MSDN The decimal keyword denotes a 128-bit data type. Compared to floating-point types, the decimal type has a greater precision and a smaller range, which makes it suitable for financial and monetary calculations. Range: decimal ±1.0 × 10−28 to ±7.9 × 1028 Precision: 28-29 significant digits

okay

Quote:

Quote: But science may switch to C# under pressure of not having competent C++ programmers.... And this is where you are deadly wrong. Higher level languages Quote: Is C# so higher level than C++? actually allow for BETTER scientists,

If you're talking about physics, they hire professional programmers to code the code. No one expect great physicists to code simulation. It's coded by programmers.

Quote:

because they can concentrate on the problem at hand and what they do best, not how to manage memory, create event systems, and other things not related to their field.

Yes, exactly, physicists concentrate, and programmers do their job.

Quote:

I am not saying that C# would be the best for this, just that higher level languages in general will be.

I agree. But C# probably will not be better than C++ enough to cause switch. But if C++ will be alot less popular than C#, there will be less competent C++ programmers, so they will have to swich to C#, that's what i meant.

Quote:

Quote: In summary: C# was designed mainly not for science. C# was designed for writing managed applications on top of the CLI/CLR. It is not meant for operating systems, drivers, etc.. but is specialized to application building.

As do C++ and others, specialised to make/"build" applications....

Quote:

Quote: That is, it's was the weakest side of C# ,and probably still is, optimizing JIT for math probably doesn't have too big priority on their "todo" list. Do you just make these things up as you go along? Where do you get this info on optimizing the JIT for math? It's odd because according to their developers and the advancements I've already seen between in C# 1.0 -> 2.0 you are utterly wrong. Quote: I really doubt it otimizes something for SSE. It's just too much effort, and most applications don't see the difference. Accordinly to what i know, it's not that much faster than java. Quote: Yes, it's probably not a defect of language, but there may be defects in VM design. (say, JVM code by design isn't quite good for science) Defects in VM design? You do realize that C# does not run in a VM right?

Well, .net VM.

JIT compiled VM is still a VM. Look at Java(maybe something have been changed, but at least as i know java). Everything is a class. It's slow almost no matter what you do.
Yes, C# can be compiled to native code.

Yes,theoretically JIT compiled VM someday will be faster than native code. But i think it's not happened yet, and it will take some time to achieve.

I'm talking about today. Science relies on yesterday's situation(why they use fortran), and is absolutely unlikely to massively swich to C# so-on. Science still often uses fortran.

also, if science will swich to C# ,science will have to use C# for as long time as fortran... and where C# will be in next 10 years, we don't know, because it's still recent language. Personally i expect that in next 15 years MS surely will make some other language be mainstream.

In fact i have nothing against C# as language, but it's tool of The Evil Microsoft^tm[grin]...

Quote:

Original post by Dmytry If you're talking about physics, they hire professional programmers to code the code. No one expect great physicists to code simulation. It's coded by programmers.

That's his whole point...by moving to higher level languages, you allow physicists/mathmeticians/whatever to do the coding with relying on programmers to do it for them. Who better to code a physics engine than a physicist? A physicist knows what errors are acceptable, where shortcuts can be taken, what shortcuts can be taken, et cetera. A programmer doesn't. By cutting out the middle man, you improve productivity. If the high level language is adequate for the task at hand, you do so without sacrificing program speed. Its win/win for everybody but the code monkee.

CM

Quote:

Original post by Dmytry If you're talking about physics, they hire professional programmers to code the code. No one expect great physicists to code simulation. It's coded by programmers.

Actually, more often than not they don't. Just for a simple example, Brian Greene (discoverers of the mirror manifolds of Calabi-Yau spaces, with Ronen Plesser), Paul Aspinwall, and David Morrison got together and solved the Calabi-Yau space flip flop by writing a program which generated the mirror manifold and compared the resulting physics of the two before and after the event. Aspinwall is a physicist, not a professional programmer, and he is the one who wrote the program.

Quote:

Original post by Conner McCloud Quote: Original post by Dmytry If you're talking about physics, they hire professional programmers to code the code. No one expect great physicists to code simulation. It's coded by programmers. That's his whole point...by moving to higher level languages, you allow physicists/mathmeticians/whatever to do the coding with relying on programmers to do it for them. Who better to code a physics engine than a physicist? A physicist knows what errors are acceptable, where shortcuts can be taken, what shortcuts can be taken, et cetera. A programmer doesn't. By cutting out the middle man, you improve productivity. If the high level language is adequate for the task at hand, you do so without sacrificing program speed. Its win/win for everybody but the code monkee. CM

Hehe.
Yet another, now economical reason why they will not switch to C#.

i guess physicists will code in fortran/c++/c#/java/python/whatever they like/will like, and big simulations on supercomputers will be written probably in C++ , *maybe* using codemonkey to translate from C#
And everyone will be happy...
btw. I tend to always blame any language. Just because any language have many drawbacks. I blamed C++ more than i blamed C# and Java alltogether...

I had a job working for the physics department at Indiana University over the summer. Another programmer and I were hired for the sole purpose of re-writing an extremely time consuming program. The old system they were using took 25 hours to complete one run. It was written by physists in C or C++, I don't remember. After we had finished our version of the program, with the help from a physists who had just completed grad school, it took 7 mins to run the same test. We weren't even trying that hard to make the program especially fast, only write a new version while not doing anything stupid, yet we still made it run in 45 mins instead of 25 hours (we then did some profiling and got it down to 7 mins).

My point in all of this is that it is sometimes better for programmers to do the programming, especially when speed is an issue. All of the people in the department however coded small scripts and programs on their own for small tasks and they did it in the language that best fit the problem. Normally shell script, perl, c, etc. I think that a high level language is good for these tasks, but when they want something done quickly without having to learn how to write fast code, the programmer gets to use whatever language they want. This removes some of the advantage of a high level language that the scientists can write in it, but when they aren't writing it, it isn't much of an issue any more.

Dwiel

How do you compile C# to native code? Also, if you know the specification of the destination system, would it be possible to optimize at compile time?

Quote:

Original post by Dmytry and big simulations on supercomputers will be written probably in C++

Accualy, this is not the case today ;)
Alot of the high performance simulations working on supercomputers (or even more so big clusters) is written in FORTRAN. One of the main reasons is that FORTRAN compilers often are special-written to generate good performance for simulations, and that the language in itself is good for parallellization etc.

-M

Quote:

Original post by Sagar_Indurkhya How do you compile C# to native code? Also, if you know the specification of the destination system, would it be possible to optimize at compile time?

Yes, Mono can do that.