Open GoogleCodeExporter opened 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
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:
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:
Original issue reported on code.google.com by
xanato...@gmail.com
on 15 Jun 2011 at 7:34