4 ms·

This changes nothing. You could already compile to native code if you really wanted. This doesn't affect speed much at all - C++ gets the speed it does from not

by RyanZAG 14y ago

This changes nothing. You could already compile to native code if you really wanted. This doesn't affect speed much at all - C++ gets the speed it does from not doing bounding checks on numbers or arrays, and from the way templates work, etc. Plus ability to optimize pointer usage, and managing memory directly so you don't need garbage collection. It also doesn't help portability at all, since the C# libraries are still all mono/windows dependent. The CLR itself was never OS specific - it's the libraries. Total non-story. People see 'native' and immediately think that making it 'native' somehow turns C# into C++ and enables QT or something...

UnoriginalGuy 14y ago
Thank you. It is like nobody has ever heard of the ngen utility before. You have been able to compile a local copy of a C# application which runs "natively" since forever. It does improve performance, but doesn't magically turn it into a ASM/C/C++ executable for the reasons set out above.
- DrJokepu 14y ago
  > It does improve performance, but doesn't magically turn it into a ASM/C/C++ executable for the reasons set out above. Isn't that, however, exactly what the Mono folks are doing with MonoTouch to get apps written in C# run on iOS (and approved in the App Store)?
  - nicwise 14y ago
    Yup, thats exactly what Monotouch does. It's something like: C# -> IL -> Mono AOT* -> ARM binary -> xcode/LLVM -> normal iOS binary * AOT = ahead of time compiler - like JIT, but... before it's needed. There is a linker step in there to remove a load of stuff too. Works _great_.
  - RyanZAG 14y ago
    Not really - they're just swapping out the libraries for ones that they can use on iOS. It's not going to be portable off of iOS, etc. (EDIT: That is, the iOS specific UI code - obviously non-platform specific library based code will be completely portable) Plus it won't be as fast as writing it in C/obj C as it will have garbage collection overhead, type checking, bounds checking, etc etc. (For iOS style UI apps this isn't a concern as they're mostly just thick clients to real calculations done elsewhere, so speed barely matters as you are just relying on the speed of UIKit for graphics anyway.)
- pkolaczk 14y ago
  However, performance is usually pretty close to what can be achieved using C++.
- pjmlp 14y ago
  Many people even think that CLR runs the code interpreted!
lloeki 14y ago
> You could already compile to native code if you really wanted. Indeed, mono --aot and MonoTouch come to mind. http://www.mono-project.com/AOT http://www.mono-project.com/AOT
pjmlp 14y ago
> C++ gets the speed it does from not doing bounding checks on numbers or arrays, and from the way templates work, etc. Plus ability to optimize pointer usage, and managing memory directly so you don't need garbage collection. You can do all these things inside unsafe code in C# as well.
- RyanZAG 14y ago
  Good point, but unsafe code works just fine without compiling to native in the first place. JIT CIL unsafe code would probably perform identically to compiled code, as you'd only use unsafe code inside tight loops anyway - and the JIT will have compiled it to native on/before the first pass through.
  - pjmlp 14y ago
    I got a bit confused by your statement. CIL is always compiled to native code, either via JIT or AOT (ngen, mono -aot).
    - RyanZAG 14y ago
      That's right - I was addressing the issue where people think that they will turn C# into C++ by allowing for 'native compile'. In the cases where you use normal C#, compiling to native isn't going to make your code run as fast as C++ as you still have bounds checking, garbage collection, etc. In the case where you use unsafe C# code inside a loop, it's going to be running as native code anyway once the JIT runs through it. ie. This story is terribly misguided as it seems to imply that C# is changing into something else because of a few compiler changes...
      - pjmlp 14y ago
        Ok
- bunderbunder 14y ago
  And some of it doesn't even require unsafe code. In many cases C#'s compiler optimizes away the array bounds checks. I think there's also a very plausible argument to be made that in C# garbage collection is often a performance bonus, not a performance hit. It's a rather different beast from what a lot of other GC languages use. For some specific kinds of applications it's definitely pure overhead - but for the business applications the language was designed for, the speedups you get from improved locality of reference and overall faster allocation and deallocation of small objects can more than outweigh the cost of the collection runs themselves. Lower-level languages are great for when there's a lot to be gained by carefully managing CPU cycles. But considering how expensive (relatively speaking) a cache miss can be on modern hardware, there's a real danger of falling into the trap of being penny wise and pound foolish if you're not careful to take some time to diagnose your performance situation before writing prescriptions for it.

by RyanZAG 14y ago

UnoriginalGuy 14y ago

Thank you. It is like nobody has ever heard of the ngen utility before. You have been able to compile a local copy of a C# application which runs "natively" since forever. It does improve performance, but doesn't magically turn it into a ASM/C/C++ executable for the reasons set out above.

DrJokepu 14y ago
> It does improve performance, but doesn't magically turn it into a ASM/C/C++ executable for the reasons set out above. Isn't that, however, exactly what the Mono folks are doing with MonoTouch to get apps written in C# run on iOS (and approved in the App Store)?
- nicwise 14y ago
  Yup, thats exactly what Monotouch does. It's something like: C# -> IL -> Mono AOT* -> ARM binary -> xcode/LLVM -> normal iOS binary * AOT = ahead of time compiler - like JIT, but... before it's needed. There is a linker step in there to remove a load of stuff too. Works _great_.
- RyanZAG 14y ago
  Not really - they're just swapping out the libraries for ones that they can use on iOS. It's not going to be portable off of iOS, etc. (EDIT: That is, the iOS specific UI code - obviously non-platform specific library based code will be completely portable) Plus it won't be as fast as writing it in C/obj C as it will have garbage collection overhead, type checking, bounds checking, etc etc. (For iOS style UI apps this isn't a concern as they're mostly just thick clients to real calculations done elsewhere, so speed barely matters as you are just relying on the speed of UIKit for graphics anyway.)
pkolaczk 14y ago
However, performance is usually pretty close to what can be achieved using C++.
pjmlp 14y ago
Many people even think that CLR runs the code interpreted!

lloeki 14y ago

> You could already compile to native code if you really wanted. Indeed, mono --aot and MonoTouch come to mind. http://www.mono-project.com/AOT http://www.mono-project.com/AOT

pjmlp 14y ago

> C++ gets the speed it does from not doing bounding checks on numbers or arrays, and from the way templates work, etc. Plus ability to optimize pointer usage, and managing memory directly so you don't need garbage collection. You can do all these things inside unsafe code in C# as well.

RyanZAG 14y ago
Good point, but unsafe code works just fine without compiling to native in the first place. JIT CIL unsafe code would probably perform identically to compiled code, as you'd only use unsafe code inside tight loops anyway - and the JIT will have compiled it to native on/before the first pass through.
- pjmlp 14y ago
  I got a bit confused by your statement. CIL is always compiled to native code, either via JIT or AOT (ngen, mono -aot).
  - RyanZAG 14y ago
    That's right - I was addressing the issue where people think that they will turn C# into C++ by allowing for 'native compile'. In the cases where you use normal C#, compiling to native isn't going to make your code run as fast as C++ as you still have bounds checking, garbage collection, etc. In the case where you use unsafe C# code inside a loop, it's going to be running as native code anyway once the JIT runs through it. ie. This story is terribly misguided as it seems to imply that C# is changing into something else because of a few compiler changes...
    - pjmlp 14y ago
      Ok
bunderbunder 14y ago
And some of it doesn't even require unsafe code. In many cases C#'s compiler optimizes away the array bounds checks. I think there's also a very plausible argument to be made that in C# garbage collection is often a performance bonus, not a performance hit. It's a rather different beast from what a lot of other GC languages use. For some specific kinds of applications it's definitely pure overhead - but for the business applications the language was designed for, the speedups you get from improved locality of reference and overall faster allocation and deallocation of small objects can more than outweigh the cost of the collection runs themselves. Lower-level languages are great for when there's a lot to be gained by carefully managing CPU cycles. But considering how expensive (relatively speaking) a cache miss can be on modern hardware, there's a real danger of falling into the trap of being penny wise and pound foolish if you're not careful to take some time to diagnose your performance situation before writing prescriptions for it.