• Advertisement
Sign in to follow this  

C# vs. C++ for Scientific Computing

This topic is 4869 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Yeah, so I noticed that a lot of people use FORTRAN, C, C++ for scientific stuff. I think a big reason is that much of the existing code base is in these languages. But I recently read an article that provides some good reasons for C#'s candidacy: <href="http://msdn.microsoft.com/msdnmag/issues/04/03/ScientificC/"> clicky </href> I think some of the good reasons are the portibility, the availability of Decimal(128bit floating point), etc. Also, JIT works better for applications that are running for a long time. Unlike Java, C# does let you use pointers and unsafe code.

Share this post


Link to post
Share on other sites
Advertisement
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Essentially if you can use Java (and take the speed hit) than C# is a perfect canadate.

If you want really optimized code then use C/C++ or a language that has compile time optimizations.

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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, ((-296 to 2 96)/ 10(0 to 28)), where -296 is equal to MinValue, and 296 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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 Microsofttm[grin]...

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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#.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Leffe
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.


And you can also do it with nGen on a Microsoft platform as well.

Share this post


Link to post
Share on other sites
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.


I can't speak for every field, of course, but this is assuredly not true for particle physics. We write our own code. As a result, it is often truly crappy code (and I am not excluding myself from this). The pessimisations and non-documentation in the software for the project I work on would make angels weep, not to mention the instabilities. But the thing is, ours is a deeply technical field, and it really needs someone who understands detectors, particles, and interactions to program for it.

Share this post


Link to post
Share on other sites
My guess is that C# would not interface properly (or efficiently) into the advanced IPC libraries used by massively parallel applications.

This would not be a problem if those libraries were rewritten to be efficient in C#, but they aren't.

Lots of people have lots of libraries for scientific computing. A lot of them are written in Fortran, some are written in C or C++.

Then the IPC library is extremely specialised to use special-purpose hardware which has extremely low latency node-node communication in the cluster.

So there's no reason in principle not to use C# for sci apps, but more of an integration issue.

My guess is that with .NET 2.0 (Or something else), FP performance is now good enough.

Mark

Share this post


Link to post
Share on other sites
Quote:
Original post by markr
My guess is that with .NET 2.0 (Or something else), FP performance is now good enough.


Don't get me wrong, I love the C# language but even with 2.0 (well the VSNET 2005 beta with C# and .NET 2.0) the FP performance is a lot better, but it still has aways to go for scientific performance in my opinion. Although I don't work in that field so that's really just a guess by myself.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement