ginuerzh / multi-language-bench

Automatically exported from code.google.com/p/multi-language-bench
0 stars 0 forks source link

No C#? #4

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
There isn't a C# version. It's one of the most used languages, you know? :-)

Original issue reported on code.google.com by xanato...@gmail.com on 15 Jun 2011 at 7:34

GoogleCodeExporter commented 8 years ago
I agree! I'm going to download the source code and try it on C#

Original comment by nico...@soleo.ca on 17 Jul 2011 at 2:37

GoogleCodeExporter commented 8 years ago
Message to the owner of this Project. I have taken the time to translate the 
java code in C# code with some help from Sharpen (a tool). I've attached a VC++ 
project to this message.

Results are disappointing. I think I don't know C# enough to judge if the 
translation was good enough, but the C# program runs just slightly faster than 
the un-optimized CPP version and terribly slower than Java. The optimized CPP 
version runs just a little bit faster than Java. I'm putting a table below:

OptimizedCPP: 41 seconds
Java: 46 seconds
C#: 97 seconds
UnoptimizedCPP: 100 seconds

There must be something I did wrong because in other tests I've run C# was 
closer to optimized CPP than Java was.

Trouble-wise, Java was clearly the easiest to get running. All the other ones 
were quite a pain... Lot's of time lost debugging and figuring out stuff.

Also not that in the C# I'm sending you, I did not bother to fix the memory 
usage function. It just prints 6000 all the time :).

Original comment by nico...@soleo.ca on 17 Jul 2011 at 8:00

Attachments:

GoogleCodeExporter commented 8 years ago
I had a little time yesterday so I converted the cpp code from svn to cs. I 
even tried compiling the cpp code with VC++ 2010. The only problem was the 
stack size (you need to enlarge the default stack size to 10mb or something 
similar on Windows). I made some tests. The cs version has the same CPU use of 
the cpp code when both of them are compiled in "Release" mode under x86. They 
take 1m30 (+-2 sec) on my machine. The cs version is "faster" because the 
garbage collector runs in another thread, so it uses around 1m15 "real time" 
(it used 1 processor and a piece of another processor). I'm using the "server" 
garbage collector. The conversion is 1:1 from the cpp one (I even replicated 
the typedefs using additional classes). Where the cs version loses is in the 
use of memory: the maximum memory footprint of the cpp version is 128.664kb 
(very stable, made some tests), while the maximum memory footprint of the cs 
version is 325.132 - 350.341 (it's quite random because the GC isn't 
deterministic, I've made some runs)
The only problem with the cs version is that you can't set the stack size of a 
cs app (I could have created a secondary thread with the needed stack size, 
because you CAN create a thread with any stack size), but I decided to use the 
editbin.exe app of visual studio. It's automatically launched when the 
compilation ends. And the stack size needs to be bigger than the one used under 
cpp. I've set 100mb just to be sure.
Ah... The c# version waits for a key to be pressed at the end. For measuring 
times I used the Task Manager (the waiting of a key doesn't "consume" CPU)

Original comment by xanato...@gmail.com on 18 Jul 2011 at 10:47

Attachments: