Author: Russell Reagan
Date: 19:37:57 04/24/04
Go up one level in this thread
On April 24, 2004 at 07:34:52, Omid David Tabibi wrote: >Since C# cannot be compiled to native code, it will of course be much slower >than C/C++. I don't think it has to be "much slower" than native C/C++. Because of the JIT compiler, the code that is run will be native machine code. After the program has been running for a short amount of time, the JIT compiler shouldn't need to continue compiling many things (since it has already compiled them to native machine code). There is of course some runtime overhead for all of this, along with things like garbage collection. In theory, the JIT compiler/managed code could be even faster than the native C/C++, but in practice it probably will not be (but maybe close). On other message boards, people report the C# program running anywhere from 3% to 80% slower than the C/C++ equivalent. I think that currently, there are some things that C# can do just as fast as C/C++, and other things that it does prett poorly. I think this is a matter of the language, compilers, and runtime environments still being relatively young. Compilers and runtime environments will probably be improved quite a bit in the future. For instance, look at this benchmark: http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html You see that for some reason nested loops in C# perform about five times slower than C and C++. Things like that will probably be identified and improved in the future. At the very least, we could use unsafe code and pointers in any bottleneck areas.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.