I used the release builds for the benchmark, here are the results:
d : 26 seconds to compute pi with a precision of 10000 digits.
c# : 34,745(34.745) seconds to compute pi with a precision of 10000 digits.
c++ : 15 seconds to compute pi with a precision of 10000 digits.

I do not want to start a language war... we had enough such wars in the past days and I have just made this benchmark because I saw the “What do you think of the D language?“ thread and was testing d.

I'm just surprised a little: I thought that D shouldn't be much slower than c++ and I thought that c# would be much faster. Maybe there is some optimization option I have not used(?)
What do you think about the results?

(maybe some one can test java)
(I really like the invariant and unittest features of D, are there equivalents for c#?)
-I can't reply until tomorrow-

Initial figures on my system before modification were in the vicinity of about 19s (probably closer to 20) for the C++ and 38s for the C#. This version of the C# runs in just under 22s. I brought the same optimizations back to the C++ version, but they didn't appear to have any particular effect.

Perhaps someone can step up and defend D's honor. 26s is much worse than I expected. (Although the fact that the D code was written by Digital Mars does not bode well.)

Original post by KambizBut because of the modifications we should not compare these result with the others.

Under which conditions may we compare one result with another?

Presumably, one is only allowed to use the exact implementation originally written in C, without taking into account the fact that a good C implementation may be a terrible implementation for another language.

In short, when comparing the performance of languages, one must assume that all programmers are competent at no languages other than C.

Original post by PromitPresumably, one is only allowed to use the exact implementation originally written in C, without taking into account the fact that a good C implementation may be a terrible implementation for another language.

You seem to be right. I've only just noticed that the version advertised as C++ isn't C++, but is in fact C.

Original post by KambizI'm just surprised a little: I thought that D shouldn't be much slower than c++ and I thought that c# would be much faster. Maybe there is some optimization option I have not used(?)What do you think about the results?

Interesting, but you're comparing the Microsoft C++ optimizer with the Digital Mars C++ optimizer. DMD, the Digital Mars D compiler, is built using the Digital Mars C++ optimizer.

To compare apples-apples, it makes sense to compare DMD versus DMC++, or GDC versus g++, as then the optimizer and code generator would be the same for each language. I tried DMD and DMC++, and got essentially the same times for each.

I actually have a suspicion that some of the modifications I applied in the C# version will improve the D version's performance as well. Anyone want to try my edits on D and see what happens? I really don't feel like downloading DMD.

Original post by Kambizd : 26 seconds to compute pi with a precision of 10000 digits.c# : 34,745(34.745) seconds to compute pi with a precision of 10000 digits.c++ : 15 seconds to compute pi with a precision of 10000 digits....I do not want to start a language war...

Yeah, right. The fact that you only gave a decimal point only for the C# version (using a comma to represent it, making it look like a huge number) and your dismissal of Promit's benchmark implies that you hold a certain prejudice toward C#. Now, theres nothing inherently wrong with that but trying to spread propaganda in the form of a benchmark is pretty sad if you ask me.

i don't want to comment on the benchmark a lot. quite frankly these kind of performance benchmarks don't mean so much, but yes they can be interesting in some cases. a pure number crunching benchmark should be winnable by a native language like c++, no surprise there. a realistic number cruncher would resort to simd instructions anyways which (for now) leaves all other alternatives far behind.. but that's only a matter of time (for me that is the main reason not to use managed languages for these kinds of applications. i need the simd capabilities the metal offers).i like the fact, though, that people are starting to defend c# like most of us here do with c++ and the sc++l. that kind of advocacy for a certain language is a very good sign for the language (and - admit it! - its creators). i think that on its own is a good process.

Original post by barakusYeah, right. The fact that you only gave a decimal point only for the C# version (using a comma to represent it, making it look like a huge number) [...] implies that you hold a certain prejudice toward C#.

I think you're reading too much to that. In Europe (where he's from), believe it or not, people use comma to separate decimals (mind-boggling, I know!). And that only C# version had decimals is likely due to the fact that in C# he had to write the outputting code slightly differently. The C-version's timing and output is more of a direct port from the original D code (using the same printf statement).

Quote:

your dismissal of Promit's benchmark

I think this was fair. It's not like Promit's code is more idiomatic C#, it's just a tweak that happens to make .NET run faster. Similar tweaks could probably be found in C++ and D versions as well, and we could spend weeks optimizing each one. Why not actually compare versions that are near identical in code to save the trouble? It even looks to me like his code would make the algorithm wrong due to the fact that floating point math isn't as accurate, but I didn't check this..

I've deleted the AP replies that seem intent on derailing this thread. So far the discussion is clean and interesting - whilst these benchmarks may not be the best way to compare languages they are a good platform for learning and discussing various characteristics.

The whole "," or "." thing is a bit pointless - why bother arguing over something so silly [smile]

I'm not much of a .net freak but to me it seems like .net is going to be slower no matter what in this specific case. It's basically a series of tight loops with bounds checked array accesses which will generate at least an extra branch for each array access, probably with stack unwinding also.

I see nothing wrong with the test and it demonstrates what is a fairly well known weakness of .net, tight loops and a lot of array accesses.

Original post by Anonymous PosterIt's not like Promit's code is more idiomatic C#, it's just a tweak that happens to make .NET run faster. Similar tweaks could probably be found in C++ and D versions as well, and we could spend weeks optimizing each one. Why not actually compare versions that are near identical in code to save the trouble? It even looks to me like his code would make the algorithm wrong due to the fact that floating point math isn't as accurate, but I didn't check this..

Different languages work in different ways. It is extremely biased to write a program in one language (C++) and expect a direct port to run equally fast on other languages (D or C#, in this case). Spending "weeks" (hopefully less) on optimizing each language according to their strengths would provide the best benchmarks. After all, I could care less how well C# or D implements C-specific algorithms. What I care about is the performance I'll achieve using those languages in the way they're designed.