Hacker News Reader

Comment by RyanZAG | Hacker News Reader

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...

View on HN

> 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.

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.

I got a bit confused by your statement.

CIL is always compiled to native code, either via JIT or AOT (ngen, mono -aot).

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...

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.

> And some of it doesn't even require unsafe code. In many cases C#'s compiler optimizes away the array bounds checks.

Quite true.

> For some specific kinds of applications it's definitely pure overhead...

I started coding back in the early 90's, so I have a lots of experience with manual memory management. Nowadays I use mostly GC enabled ones (native or managed).

There some special cases like real time systems, or very complex games where GC might hurt, but I think the main issue is that many developers lack the knowledge to use GC enabled languages properly.

You need to organize the data structures and algorithms in a GC friendly way, which is different than doing manual memory management. Allocating memory faster than the GC can handle it, or getting 1GB just because, won't make your application behave nicely.

> Lower-level languages are great for when there's a lot to be gained by carefully managing CPU cycles ...

On the other hand, the optimizer is sometimes limited in what it can do, because of those low level constructs. C pointer aliasing is a good example.

For me, the best solution would be a kind of hybrid approach, similar to what .NET already does, or the Lisp environments also do.

You make use of a VM like environment (with JIT) for development purposes, but additionally have the option to aot the code to native for redistribution.

So lets say like ngen, but where all the non used stuff is removed.

But good developers should also be able to drop down to Assembly, C, C++, if the application really requires it.

> good developers should also be able to drop down to Assembly, C, C++, if the application really requires it.

The ability to do that easily is one reason why I used to be very fond of Objective-C.

With something like .NET, though, I submit that it shouldn't be too much easier than what we already get with P/Invoke. The unmanaged code really should be isolated in order to prevent it from corrupting the managed code's memory space, but that inevitably means that there's a hefty performance toll to calling into the unmanaged code. Having the ability to pepper the application with tiny little snippets of low-level code would probably do more harm than good, by enticing less-experienced developers to make a habit of burning 10X time in domain-crossing every time they want to save X time in CPU cycles.

I kind of like Objective-C, sadly it is a MacOS X language, as GNUStep does not offer the required portability across all systems I develop for.

Where does the C# compiler erase an array bounds check? That would require the C# compiler to emit unsafe IL which wouldn't verify. The C# team has said they try for a fairly direct translation to MSIL; there's no super sophisticated optimization going in the C# compiler.

I think you mean the CLR/JIT often removes array checks if it can detect it (such as in certain loop constructs).

Please correct me if I'm wrong.

Yes, the JIT/NGEN takes care of if it it can prove by dataflow analysis that the indexes are always within bounds.

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.

> 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)?

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_.

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.)

However, performance is usually pretty close to what can be achieved using C++.

Many people even think that CLR runs the code interpreted!

> 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

Reply on news.ycombinator.com