1

As we know, .net has CLI and JIT to execute programs. but these two stage maybe cause to lower speed and performance in compare with c++ that compile all codes in one stage. I want to know that .net's languages how to overcome this disadvantage and deal with it?

reihan
  • 23
  • 6
  • Is this a significant enough disadvantage _in your situation_ that you need to? – ProgrammingLlama May 05 '18 at 06:22
  • I just want to compare c++ and .net performance and time of execution...I want to know how can reach to the speed of c++ in .net generally. – reihan May 05 '18 at 06:35
  • Have you read [this](https://stackoverflow.com/questions/138361/how-much-faster-is-c-than-c) – ProgrammingLlama May 05 '18 at 06:42
  • I read this. this article don't persuade me.I think there is some thing about compilers in c++ and .net that I don't know.please help me – reihan May 05 '18 at 07:37
  • Step through the code in the Visual Studio debugger, looking at the generated machine code (especially in a release build). Then you can answer your own question. Any performance overhead is probably just the cost of the JIT compilation, plus garbage collection of course. Also, benchmark something in native C++ vs .net. Then you'll know a lot more. – Paul Sanders May 05 '18 at 07:45
  • @PaulSanders Iwant to know the answer in point of view relation of instruction and compiler and duty of compiler.can you explain me is it true that .net is as fast as c++?how? – reihan May 05 '18 at 07:55
  • Didn't I just answer that? I don't know precisely but I did outline ways that you could find out for yourself. – Paul Sanders May 05 '18 at 08:05
  • Apparently 10 years ago the difference was [five oranges](https://stackoverflow.com/a/138384/597607). Today it might be just 2 apples, or less. You have to decide if any difference in "speed" is worth the difference in convenience of using a specific language. Otherwise you could choose to write in assembly and deliver the worlds fastest program 10 years too late. – Bo Persson May 05 '18 at 08:22
  • Jitting just isn't a bottleneck at all, beyond its amortized cost .NET has had ahead-of-time compilation since its inception. Done by Ngen.exe and later .NET Native. Code optimization is less effective, but that only ever plays a role when you write sloppy code, you can do that in C++ as well. The overhead that is harder to factor away is making the code verifiable and type-safe, a hard requirement for a garbage-collected runtime environment. A feature that otherwise nobody ever complains about. – Hans Passant May 05 '18 at 09:17

1 Answers1

3

Having worked on both C++ compilers and now having spent the past few years working on the .Net JIT, I think there are a few things worth considering:

  • As many others have pointed out, the JIT is running in process with your app, and it tries to carefully balance quick JIT times versus the quality of jitted code. The more elaborate optimizations seen in C++ often come with very high compile time price tags, and there are some pretty sharp knees in the compile-time-vs-code-quality graph.
  • Prejitting seemingly can change this equation somewhat as the jit runs beforehand and could take more time, but prejitting's ability to enlarge optimization scope is quite limited (for instance we try and avoid introducing fragile cross-assembly dependencies, and so for example won't inline across assembly boundaries). So prejitted code tends to run somewhat more slowly than jitted code, and mainly helps application startup times.
  • .Net's default execution model precludes many interprocedural optimizations, because of dynamic class loading, reflection, and the ability of a profiler to update method bodies in a running process. We think, by and large, that the productivity and app architecture gains from these features are worth the trouble. But for cases where these features are not needed we are looking for ways to ensure that if your app doesn't need it, your app won't pay for it.
  • For example we have some "pure" AOT work going on over in CoreRT but as a consequence reflection is limited.
  • .Net Core 2.1 includes a preview of Tiered jitting, which will allow us to ease some of the constraints on jit time -- we'll be able to invest more time jitting methods that we know are frequently executed. So I would expect to see more sophisticated optimizations get added to the JIT over time.
  • .Net Core 2.1 also includes a preview of Hardware Intrinsics so you can take full advantage of the rich instruction sets available on modern hardware.
  • .Net's JIT does not yet get much benefit from profile feedback. This is something we are actively working on changing, though it will take time, and will likely be tied into tiering.
  • The .Net execution model fundamentally alters the way one needs to think about certain compiler optimizations. For instance, from the compiler's standpoint, many operations -- including low level things like field access -- can raise semantically meaningful exceptions (in C++ only calls/throws can cause exceptions). And .Net's GC is precise and relocating which imposes constraints on optimizations in other ways.
Andy Ayers
  • 892
  • 6
  • 13