performance puzzle
-
My statement was made because I had to maintain some Native code I wrote some years ago. I realized how retarded I had become doing retards' languages.
peterchen wrote:
Are you open to evidence for my statement
I'm all ears (big, pointy ears).
NULL
Mechanical wrote:
doing retards' languages
Exactly what is a retards' languages?
-
I have a short program which check prime number. Run multiple time a single slow loop, to test performance. I have a C++, C# and F# version. (to be fair with C# the C++ version use fixed sized 32 bit integers, instead of native size int, but that doesn't seem to make a difference anyway) A few things puzzle me. 1. The c++ is definitely faster! my best C# tweak makes C++ 20% faster. That surprises me because C# is compiled too (at runtime, at the first run) and I am only looping over byte array and using int number, I am not doing interop, and even I use stackalloc and pointer in (unsafe) C# so there is no bound check. And the algorithm is so simple that it's hard to believe (but it must be true) that the C++ compiler optimize the generated code further than the JITted C# one... 2. creating an array with stackalloc result in faster loop (5%) than using fixed(&array[0]), in fact using fixed(&array[0]) has the same speed than using normal (safe and bound checked) array!! how come!?! 3. F# is 25% slower than C#. Well I guess I should not be too surprised and I guess that teach me the posts about amazing performance of F# have less to do with some "magic F# quality" and more to do with the heavy type inference / use of generic and "fast delegate" replacement, which is not really put to use in my sample. So, what is the question? err.. Well, any C# performance tip is welcome!
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
Years back, I wrote identical implementations in C# and C for a Blowfish cipher. The C version had a managed C++ interface for .NET consumption. Then running both, I found the C version (even though in a .NET wrapper) was about 5 times faster than the C# code. I compared the C code's generated assembler to a hand written assembler version, and they were almost 100% identical (kudos for the C++ compiler here). Anyways, there is no way C# can ever get close to native performance when you are number crunching.
-
Mechanical wrote:
doing retards' languages
Exactly what is a retards' languages?
-
I suppose it is whatever a certain individual in the back room uses for his 'software engineering'.
Indivara wrote:
I suppose it is whatever a certain individual in the back room uses for his 'software engineering'
Are you trying to please Big Brother ? If yes, then you are smart.
NULL
-
Interesting - Can you post code? If it's too much for a post try http://pastebin.com/[^]
Simon
C++ ======================================
int _tmain(int argc, _TCHAR* argv[])
{
if (argc != 2)
{
std::cerr << "Usage:\tsieve [iterations]\n";
return 1;
};size\_t NUM = \_wtoi(argv\[1\]); DWORD dw = ::GetTickCount();
#if ! CS-Speed
char primes[8192+1];
int pbegin = 0;
int begin = 2;
int end = 8193;while (NUM -- != 0) { for (int i = 0; i < end; i++) { primes\[i\] = 1; } for (int i = begin; i < end; ++i) { if (primes\[i\] != 0) { int p = i; // using this extra variable speeds up C++!!! (and slow down C# if I do it) for (int k = i + p; k < end; k += p) { primes\[k\] = 0; } } } }
#else
WORD end = 8193;
char primes[8193];
while (NUM-- != 0)
{
for (WORD i = 0; i < end; i++)
primes[i] = 1;for (WORD i = 2; i < end; ++i) if (primes\[i\] != 0) for (WORD k = 2 \* i; k < end; k += i) primes\[k\] = 0; }
#endif
DWORD dw2 = ::GetTickCount(); std::cout << "Milliseconds = " << dw2-dw << std::endl; return 0;
}
====================================== C# ======================================
unsafe static void Main(string[] args)
{
if (args.Length != 1)
{
Console.WriteLine("Usage:\tsieve [iterations]");
return;
}int NUM = int.Parse(args\[0\]); var t0 = DateTime.Now; int end = 8193; var primes = stackalloc byte\[end\]; while (NUM-- != 0) { for (int i = 0; i < end; i++) primes\[i\] = 1; for (int i = 2; i < end; ++i) if (primes\[i\] != 0) for (int k = 2 \* i; k < end; k += i) primes\[k\] = 0; } var dt = DateTime.Now - t0; System.Console.WriteLine("Milliseconds = {0}", dt.TotalMilliseconds);
}
====================================== F# ======================================
open System
[<EntryPoint>]
let main args =let NUM = Int32.Parse args.\[0\] let t0 = DateTime.Now let primes : byte\[\] = Array.zeroCreate ( 8192 + 1 ) let aend = 8192 for nloop = 1 to NUM do for i = 0 to aend do primes.\[i\] <- 1uy for i = 2 to aend do if primes.\[i\] <> 0uy then let mutable k = 2 \* i while k <= aend do primes.\[k\] <- 0uy k <- k + i let dt = DateTime.Now - t0 Console.WriteLine("Milliseconds = {0}", dt.TotalMilliseconds) 0
===============================
-
Indivara wrote:
I suppose it is whatever a certain individual in the back room uses for his 'software engineering'
Are you trying to please Big Brother ? If yes, then you are smart.
NULL
-
I have a short program which check prime number. Run multiple time a single slow loop, to test performance. I have a C++, C# and F# version. (to be fair with C# the C++ version use fixed sized 32 bit integers, instead of native size int, but that doesn't seem to make a difference anyway) A few things puzzle me. 1. The c++ is definitely faster! my best C# tweak makes C++ 20% faster. That surprises me because C# is compiled too (at runtime, at the first run) and I am only looping over byte array and using int number, I am not doing interop, and even I use stackalloc and pointer in (unsafe) C# so there is no bound check. And the algorithm is so simple that it's hard to believe (but it must be true) that the C++ compiler optimize the generated code further than the JITted C# one... 2. creating an array with stackalloc result in faster loop (5%) than using fixed(&array[0]), in fact using fixed(&array[0]) has the same speed than using normal (safe and bound checked) array!! how come!?! 3. F# is 25% slower than C#. Well I guess I should not be too surprised and I guess that teach me the posts about amazing performance of F# have less to do with some "magic F# quality" and more to do with the heavy type inference / use of generic and "fast delegate" replacement, which is not really put to use in my sample. So, what is the question? err.. Well, any C# performance tip is welcome!
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
I think that even plain
C
is best suited for such a task. I suppose you may have performace boosts, from higher level language, only if they allow you to implement a better algorithm for a complex problem (I mean, whenever implementing the same algorithmC++
is too difficult because you have to take care of too many details, etc...). In any case,C#
was created to speed up code development (without loosing too much performance), right? :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Years back, I wrote identical implementations in C# and C for a Blowfish cipher. The C version had a managed C++ interface for .NET consumption. Then running both, I found the C version (even though in a .NET wrapper) was about 5 times faster than the C# code. I compared the C code's generated assembler to a hand written assembler version, and they were almost 100% identical (kudos for the C++ compiler here). Anyways, there is no way C# can ever get close to native performance when you are number crunching.
As I understood it, theoretically there is no reason why .NET shouldn't even be better, as it is compiled just for the machine it is executing on! That's what they say in their propaganda! I guess it depends on how much optimization they can run during the JIT compilation. But this algorithm is so simple, I thought there wasn't much left to optimize!!! I guess just one innocent instruction can make a difference when looped over a huge number of times... BTW, C#4 is faster! :)
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
I think that even plain
C
is best suited for such a task. I suppose you may have performace boosts, from higher level language, only if they allow you to implement a better algorithm for a complex problem (I mean, whenever implementing the same algorithmC++
is too difficult because you have to take care of too many details, etc...). In any case,C#
was created to speed up code development (without loosing too much performance), right? :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]indeed, but they had this propaganda that .NET is JIT compiled just for the machine it's running on, so that theoretically it can even be faster! (it's what they used to say) Further C# 4 is way faster and this algorithm is so simple I can hardly see why the JITted version couldn't be as good as the compiled C version... guess I was wrong.. guess when things are looped over a huge number of time, just 1 instruction can make a big difference....
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
My statement was made because I had to maintain some Native code I wrote some years ago. I realized how retarded I had become doing retards' languages.
peterchen wrote:
Are you open to evidence for my statement
I'm all ears (big, pointy ears).
NULL
Mechanical wrote:
I had to maintain some Native code I wrote some years ago. I realized how retarded I had become doing retards' languages.
Although I don't think much, your statement is wrong. Why? Simply because the reverse of it would be true also. Meaning that if you used to work on retard language, then went genius language for 4 or so years, if you would be asked to maintain a retard language piece of code you wouldn't be able to do it wright away. You would be a retard genius in a retard language. :)
I used to think.... Finally I realized it's no good.
-
I think that even plain
C
is best suited for such a task. I suppose you may have performace boosts, from higher level language, only if they allow you to implement a better algorithm for a complex problem (I mean, whenever implementing the same algorithmC++
is too difficult because you have to take care of too many details, etc...). In any case,C#
was created to speed up code development (without loosing too much performance), right? :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]Plus I just bought a WP7 and some game take up to a minute to load, and I was wondering about optimization, and I was wondering if they plan to do ahead of time compilation of apps when deployed (instead of JIT) and I was wondering how good is the performance, etc...
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
I think that even plain
C
is best suited for such a task. I suppose you may have performace boosts, from higher level language, only if they allow you to implement a better algorithm for a complex problem (I mean, whenever implementing the same algorithmC++
is too difficult because you have to take care of too many details, etc...). In any case,C#
was created to speed up code development (without loosing too much performance), right? :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
C++ ======================================
int _tmain(int argc, _TCHAR* argv[])
{
if (argc != 2)
{
std::cerr << "Usage:\tsieve [iterations]\n";
return 1;
};size\_t NUM = \_wtoi(argv\[1\]); DWORD dw = ::GetTickCount();
#if ! CS-Speed
char primes[8192+1];
int pbegin = 0;
int begin = 2;
int end = 8193;while (NUM -- != 0) { for (int i = 0; i < end; i++) { primes\[i\] = 1; } for (int i = begin; i < end; ++i) { if (primes\[i\] != 0) { int p = i; // using this extra variable speeds up C++!!! (and slow down C# if I do it) for (int k = i + p; k < end; k += p) { primes\[k\] = 0; } } } }
#else
WORD end = 8193;
char primes[8193];
while (NUM-- != 0)
{
for (WORD i = 0; i < end; i++)
primes[i] = 1;for (WORD i = 2; i < end; ++i) if (primes\[i\] != 0) for (WORD k = 2 \* i; k < end; k += i) primes\[k\] = 0; }
#endif
DWORD dw2 = ::GetTickCount(); std::cout << "Milliseconds = " << dw2-dw << std::endl; return 0;
}
====================================== C# ======================================
unsafe static void Main(string[] args)
{
if (args.Length != 1)
{
Console.WriteLine("Usage:\tsieve [iterations]");
return;
}int NUM = int.Parse(args\[0\]); var t0 = DateTime.Now; int end = 8193; var primes = stackalloc byte\[end\]; while (NUM-- != 0) { for (int i = 0; i < end; i++) primes\[i\] = 1; for (int i = 2; i < end; ++i) if (primes\[i\] != 0) for (int k = 2 \* i; k < end; k += i) primes\[k\] = 0; } var dt = DateTime.Now - t0; System.Console.WriteLine("Milliseconds = {0}", dt.TotalMilliseconds);
}
====================================== F# ======================================
open System
[<EntryPoint>]
let main args =let NUM = Int32.Parse args.\[0\] let t0 = DateTime.Now let primes : byte\[\] = Array.zeroCreate ( 8192 + 1 ) let aend = 8192 for nloop = 1 to NUM do for i = 0 to aend do primes.\[i\] <- 1uy for i = 2 to aend do if primes.\[i\] <> 0uy then let mutable k = 2 \* i while k <= aend do primes.\[k\] <- 0uy k <- k + i let dt = DateTime.Now - t0 Console.WriteLine("Milliseconds = {0}", dt.TotalMilliseconds) 0
===============================
Cool. I'm looking at it now. I'll post back in a bit.
Simon
-
indeed, but they had this propaganda that .NET is JIT compiled just for the machine it's running on, so that theoretically it can even be faster! (it's what they used to say) Further C# 4 is way faster and this algorithm is so simple I can hardly see why the JITted version couldn't be as good as the compiled C version... guess I was wrong.. guess when things are looped over a huge number of time, just 1 instruction can make a big difference....
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
Super Lloyd wrote:
indeed, but they had this propaganda that .NET is JIT compiled just for the machine it's running on, so that theoretically it can even be faster!
I guess this happens also for
C++
, in this case. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Super Lloyd wrote:
indeed, but they had this propaganda that .NET is JIT compiled just for the machine it's running on, so that theoretically it can even be faster!
I guess this happens also for
C++
, in this case. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]Mmm... indeed! Silly me! :laugh:
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
Super Lloyd wrote:
how do I get the disassembly of the JITted code?!
Like I said, throw an uncaught exception. Attach the debugger when it is thrown. To prevent certain optimizations, ensure that throwing the exceptions happens at a place that the compiler can't prove will be reached. Then open the disassembly view. (doesn't exist in express editions)
Cool, I have both assembly version side by side now! :) Mm.. the C++ has much short loop! (I mean much less assembly instruction in the loop) :~ Now trying to read the ASM closely and guess what went "wrong" in the C# version...
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
Cool. I'm looking at it now. I'll post back in a bit.
Simon
yes, do post back please! :P
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
Cool, I have both assembly version side by side now! :) Mm.. the C++ has much short loop! (I mean much less assembly instruction in the loop) :~ Now trying to read the ASM closely and guess what went "wrong" in the C# version...
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
Super Lloyd wrote:
any C# performance tip is welcome!
That is like looking for performance from Java: You won't get it. If you need (or want) performance, don't do retards' languages. I know this thread isn't meant to incite hatred against retards' languages.
NULL
Mechanical wrote:
That is like looking for performance from Java: You won't get it.
You are horribly wrong here. In some cases, C# can outperform C/C++ performance-wise. And that is because of the optimizations that can be made at intermediate-level i.e, IL or bytecode or whatever (which people like you think might be the reason for slowness). See here for a performance comparison between different languages[^] However, if you like to follow the sheep, go ahead.
-
C++ ======================================
int _tmain(int argc, _TCHAR* argv[])
{
if (argc != 2)
{
std::cerr << "Usage:\tsieve [iterations]\n";
return 1;
};size\_t NUM = \_wtoi(argv\[1\]); DWORD dw = ::GetTickCount();
#if ! CS-Speed
char primes[8192+1];
int pbegin = 0;
int begin = 2;
int end = 8193;while (NUM -- != 0) { for (int i = 0; i < end; i++) { primes\[i\] = 1; } for (int i = begin; i < end; ++i) { if (primes\[i\] != 0) { int p = i; // using this extra variable speeds up C++!!! (and slow down C# if I do it) for (int k = i + p; k < end; k += p) { primes\[k\] = 0; } } } }
#else
WORD end = 8193;
char primes[8193];
while (NUM-- != 0)
{
for (WORD i = 0; i < end; i++)
primes[i] = 1;for (WORD i = 2; i < end; ++i) if (primes\[i\] != 0) for (WORD k = 2 \* i; k < end; k += i) primes\[k\] = 0; }
#endif
DWORD dw2 = ::GetTickCount(); std::cout << "Milliseconds = " << dw2-dw << std::endl; return 0;
}
====================================== C# ======================================
unsafe static void Main(string[] args)
{
if (args.Length != 1)
{
Console.WriteLine("Usage:\tsieve [iterations]");
return;
}int NUM = int.Parse(args\[0\]); var t0 = DateTime.Now; int end = 8193; var primes = stackalloc byte\[end\]; while (NUM-- != 0) { for (int i = 0; i < end; i++) primes\[i\] = 1; for (int i = 2; i < end; ++i) if (primes\[i\] != 0) for (int k = 2 \* i; k < end; k += i) primes\[k\] = 0; } var dt = DateTime.Now - t0; System.Console.WriteLine("Milliseconds = {0}", dt.TotalMilliseconds);
}
====================================== F# ======================================
open System
[<EntryPoint>]
let main args =let NUM = Int32.Parse args.\[0\] let t0 = DateTime.Now let primes : byte\[\] = Array.zeroCreate ( 8192 + 1 ) let aend = 8192 for nloop = 1 to NUM do for i = 0 to aend do primes.\[i\] <- 1uy for i = 2 to aend do if primes.\[i\] <> 0uy then let mutable k = 2 \* i while k <= aend do primes.\[k\] <- 0uy k <- k + i let dt = DateTime.Now - t0 Console.WriteLine("Milliseconds = {0}", dt.TotalMilliseconds) 0
===============================
Nothing to do with the optimisation, but what about using the StopWatch class instead of datetime? Start the stop watch immediately before you enter the loop, and then stop it as soon as the loop exists.
Dave Find Me On: Web|Facebook|Twitter|LinkedIn CPRepWatcher now available as Packaged Chrome Extension, visit my articles for link.