7 ms·

Microsoft asking for engineer to work on a native compiler for C++ and C#

34 points by z3phyr 14y ago

bdfh42 14y ago
Using the .NET Micro Framework C# can already run pretty close to the metal - so why not? See https://tindie.com/shops/nwazet/netduino-go/ https://tindie.com/shops/nwazet/netduino-go/ for an accessible example set up.
- jbester 14y ago
  .NET Micro framework is actually a different beast in that's it's close to the metal but it's not compiled to a specific architecture. The MF is a bytecode interpreter vs the mainline dotnet framework which is JIT'd or AOT compiled (with NGEN). This approach gives a couple advantages and a couple disadvantages. Specifically, the advantages the debugging and reloading can be done extremely quickly, the bytecode is small thus giving a lot of functionality per the byte of storage space, and it's significantly easier to port from microcontroller to microcontroller. Downsides, it's pretty slow - typically the heavy lifting happens in the HAL/MF, and you can't write interrupt handlers directly in it - although you can indirectly via the managed driver interface.
ylatuya 14y ago
Mono already compiles to native code with LLVM: http://www.mono-project.com/Mono:Runtime:Documentation:LLVM http://www.mono-project.com/Mono:Runtime:Documentation:LLVM
candl 14y ago
Windows Phone 8 applications (C#) get AOT compiled to machine code. Here's an overview: http://www.silverlightshow.net/items/Windows-Phone-8-Compile-in-the-Cloud.aspx http://www.silverlightshow.net/items/Windows-Phone-8-Compile... Some video sessions: [Deep Dive into the Kernel of .NET on WP8 - (talk about compilation starts around the 22 minute mark)] http://channel9.msdn.com/Events/Build/2012/3-005 http://channel9.msdn.com/Events/Build/2012/3-005 [Inside Compiler in the Clound and MDIL] http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and-Peter-Sollich-Inside-Compiler-in-the-Cloud-and-MDIL http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and...
mercurial 14y ago
It's a link to a stackexchange post which contains essentially nothing but the link to a post on the Channel 9 forums :( Apart from this niggle, sounds promising. Actual link here: http://channel9.msdn.com/Forums/Coffeehouse/MS-working-on-a-same-compiler-for-C-AND-C--Not-in-incubation-but-for-production- http://channel9.msdn.com/Forums/Coffeehouse/MS-working-on-a-...
polskibus 14y ago
This would open lots of possibilities, however teaching all those c#_with_no_c++_background programmers about proper use of destructors and RAII may be hard ;)
Yuioup 14y ago
Misleading title. It should read "Microsoft asking for engineer to work on a native compiler for C++ and C#".
- z3phyr 14y ago
  Done that!
  - Yuioup 14y ago
    Awesome :-)
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.)
InclinedPlane 14y ago
C# is probably my favorite language, although to be honest I don't have much experience with Ruby, Python, or Coffeescript. However, coding in C# (especially post v3.5) always feels like easy mode. You've got type safety but you've also got enormous flexibility with lambda expressions, extension methods, and so much other good stuff. And then the IDE becomes a real force multiplier instead of just a crutch to keep you from falling down as it can be with Java and other less savory languages, for example. It'll be exciting to see how this affects the C# ecosystem. Although it's even more interesting what this says about Microsoft's plans for the future of the CLR. It seems as though MS might be coming to the conclusion that it was a failed experiment, which is interesting given the success of other VM systems such as the JVM. It'll be interesting to see whether or not this move helps advance C# adoption outside of the windows platform.
- moreshoes 14y ago
  > C# is probably my favorite language, although to be honest I don't have much experience with Ruby, Python, or Coffeescript. http://i.imgur.com/iWBOL.gif http://i.imgur.com/iWBOL.gif
  - duiker101 14y ago
    This is not reddit/4chan/9gag or whatever, please avoid posting if you don't have any constructive thing to say. Also please read the guidelines http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html
- moreshoes 14y ago
  Nothing about this comment, short of your preference of C# over languages (and non-languages) you don't have any experience with, makes any sense at all. It's wild speculation based on a StackExchange question speculating on something that isn't even implied by a linked job listing. Microsoft has not, nor will they, come to the conclusion that the CLR was a failed experiment. As for the actual job listing, it has precious little consequence for anything or anyone, save for possible application speedups for certain use cases on certain architectures a few years down the road.
smallegan 14y ago
This title should include a question mark.
jstclair 14y ago
The link should probably go directly to the job posting, since the StackExchange -> Channel9 posts don't really provide any additional information. The compilerjobs link (http://www.compilerjobs.com/db/jobs_view.php?editid1=648 http://www.compilerjobs.com/db/jobs_view.php?editid1=648) has a bit more details: "Specifically this work will include: • Engineering parts of the reader for MSIL • Creating a native compiler internal representation that the existing compiler can optimize • Designing and implementing new managed optimizations to augment the existing optimizer like range check elimination or speeding up C# constructs on vector machines • Engineering and co-designing the ability to emit a new object file format that will support rapid linking • Fixing all existing phases of the compiler so that managed code can be correctly and efficiently compiled with the new auot-vectorizing/auto-parallelizing Win 8 compiler." So, this sounds to me like an element of high-performance computing (maybe with the recent work getting Hadoop running on Windows?), rather than a fully-native toolchain.
nopassrecover 14y ago
Isn't this somewhat related to the goal of the Roslyn CTP (http://msdn.microsoft.com/en-us/vstudio/roslyn.aspx http://msdn.microsoft.com/en-us/vstudio/roslyn.aspx)?
- moreshoes 14y ago
  Doubtful. These are entirely different parts of the toolchain, and the goals (while similar in wording) are entirely different from each other.
  - Permit 14y ago
    No, if you watch the videos, Anders specifically says that they plan to eat their own dog food on this one and expose APIs to the same compiler they use. He also says that they're rewriting the C# compiler entirely in C# as part of Roslyn.
    - moreshoes 14y ago
      Exactly, and that has nothing at all to do with the position posted by Microsoft in terms of this thread.
Permit 14y ago
This is really strange to me as Anders Hejlsberg says they're implementing the C# compiler in C# as part of the Roslyn project. http://channel9.msdn.com/Blogs/Charles/The-Roslyn-Project-Meet-the-Design-Team http://channel9.msdn.com/Blogs/Charles/The-Roslyn-Project-Me...
- noblethrasher 14y ago
  But a managed code compiler could still generate native (and managed) code if needed. Or a new C# compiler could be written in some kind of native C# variant that generates both managed and native code.
  - pjmlp 14y ago
    Like bartok, the MSIL->x86 compiler in Singularity.
nicwise 14y ago
C# can "go native" right now. NGEN precompiles the IL into native code if you use the normal framework. Mono AOT compiles (and links) code into various architectures, but MonoTouch and Mono for Android (http://xamarin.com http://xamarin.com) would be the major public uses for it - native iOS / Android apps using C#. If you wonder "can they be any good": go get the new Rdio app. It's done in MonoTouch (and their Android one, in beta, is done in Mono for Android)

34 points by z3phyr 14y ago

Using the .NET Micro Framework C# can already run pretty close to the metal - so why not? See https://tindie.com/shops/nwazet/netduino-go/ https://tindie.com/shops/nwazet/netduino-go/ for an accessible example set up.

jbester 14y ago
.NET Micro framework is actually a different beast in that's it's close to the metal but it's not compiled to a specific architecture. The MF is a bytecode interpreter vs the mainline dotnet framework which is JIT'd or AOT compiled (with NGEN). This approach gives a couple advantages and a couple disadvantages. Specifically, the advantages the debugging and reloading can be done extremely quickly, the bytecode is small thus giving a lot of functionality per the byte of storage space, and it's significantly easier to port from microcontroller to microcontroller. Downsides, it's pretty slow - typically the heavy lifting happens in the HAL/MF, and you can't write interrupt handlers directly in it - although you can indirectly via the managed driver interface.

ylatuya 14y ago

Mono already compiles to native code with LLVM: http://www.mono-project.com/Mono:Runtime:Documentation:LLVM http://www.mono-project.com/Mono:Runtime:Documentation:LLVM

candl 14y ago

Windows Phone 8 applications (C#) get AOT compiled to machine code. Here's an overview: http://www.silverlightshow.net/items/Windows-Phone-8-Compile-in-the-Cloud.aspx http://www.silverlightshow.net/items/Windows-Phone-8-Compile... Some video sessions: [Deep Dive into the Kernel of .NET on WP8 - (talk about compilation starts around the 22 minute mark)] http://channel9.msdn.com/Events/Build/2012/3-005 http://channel9.msdn.com/Events/Build/2012/3-005 [Inside Compiler in the Clound and MDIL] http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and-Peter-Sollich-Inside-Compiler-in-the-Cloud-and-MDIL http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and...

mercurial 14y ago

It's a link to a stackexchange post which contains essentially nothing but the link to a post on the Channel 9 forums :( Apart from this niggle, sounds promising. Actual link here: http://channel9.msdn.com/Forums/Coffeehouse/MS-working-on-a-same-compiler-for-C-AND-C--Not-in-incubation-but-for-production- http://channel9.msdn.com/Forums/Coffeehouse/MS-working-on-a-...

polskibus 14y ago

This would open lots of possibilities, however teaching all those c#_with_no_c++_background programmers about proper use of destructors and RAII may be hard ;)

Yuioup 14y ago

Misleading title. It should read "Microsoft asking for engineer to work on a native compiler for C++ and C#".

z3phyr 14y ago
Done that!
- Yuioup 14y ago
  Awesome :-)

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

InclinedPlane 14y ago

C# is probably my favorite language, although to be honest I don't have much experience with Ruby, Python, or Coffeescript. However, coding in C# (especially post v3.5) always feels like easy mode. You've got type safety but you've also got enormous flexibility with lambda expressions, extension methods, and so much other good stuff. And then the IDE becomes a real force multiplier instead of just a crutch to keep you from falling down as it can be with Java and other less savory languages, for example. It'll be exciting to see how this affects the C# ecosystem. Although it's even more interesting what this says about Microsoft's plans for the future of the CLR. It seems as though MS might be coming to the conclusion that it was a failed experiment, which is interesting given the success of other VM systems such as the JVM. It'll be interesting to see whether or not this move helps advance C# adoption outside of the windows platform.

moreshoes 14y ago
> C# is probably my favorite language, although to be honest I don't have much experience with Ruby, Python, or Coffeescript. http://i.imgur.com/iWBOL.gif http://i.imgur.com/iWBOL.gif
- duiker101 14y ago
  This is not reddit/4chan/9gag or whatever, please avoid posting if you don't have any constructive thing to say. Also please read the guidelines http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html
moreshoes 14y ago
Nothing about this comment, short of your preference of C# over languages (and non-languages) you don't have any experience with, makes any sense at all. It's wild speculation based on a StackExchange question speculating on something that isn't even implied by a linked job listing. Microsoft has not, nor will they, come to the conclusion that the CLR was a failed experiment. As for the actual job listing, it has precious little consequence for anything or anyone, save for possible application speedups for certain use cases on certain architectures a few years down the road.

smallegan 14y ago

This title should include a question mark.

jstclair 14y ago

The link should probably go directly to the job posting, since the StackExchange -> Channel9 posts don't really provide any additional information. The compilerjobs link (http://www.compilerjobs.com/db/jobs_view.php?editid1=648 http://www.compilerjobs.com/db/jobs_view.php?editid1=648) has a bit more details: "Specifically this work will include: • Engineering parts of the reader for MSIL • Creating a native compiler internal representation that the existing compiler can optimize • Designing and implementing new managed optimizations to augment the existing optimizer like range check elimination or speeding up C# constructs on vector machines • Engineering and co-designing the ability to emit a new object file format that will support rapid linking • Fixing all existing phases of the compiler so that managed code can be correctly and efficiently compiled with the new auot-vectorizing/auto-parallelizing Win 8 compiler." So, this sounds to me like an element of high-performance computing (maybe with the recent work getting Hadoop running on Windows?), rather than a fully-native toolchain.

nopassrecover 14y ago

Isn't this somewhat related to the goal of the Roslyn CTP (http://msdn.microsoft.com/en-us/vstudio/roslyn.aspx http://msdn.microsoft.com/en-us/vstudio/roslyn.aspx)?

moreshoes 14y ago
Doubtful. These are entirely different parts of the toolchain, and the goals (while similar in wording) are entirely different from each other.
- Permit 14y ago
  No, if you watch the videos, Anders specifically says that they plan to eat their own dog food on this one and expose APIs to the same compiler they use. He also says that they're rewriting the C# compiler entirely in C# as part of Roslyn.
  - moreshoes 14y ago
    Exactly, and that has nothing at all to do with the position posted by Microsoft in terms of this thread.

Permit 14y ago

This is really strange to me as Anders Hejlsberg says they're implementing the C# compiler in C# as part of the Roslyn project. http://channel9.msdn.com/Blogs/Charles/The-Roslyn-Project-Meet-the-Design-Team http://channel9.msdn.com/Blogs/Charles/The-Roslyn-Project-Me...

noblethrasher 14y ago
But a managed code compiler could still generate native (and managed) code if needed. Or a new C# compiler could be written in some kind of native C# variant that generates both managed and native code.
- pjmlp 14y ago
  Like bartok, the MSIL->x86 compiler in Singularity.

nicwise 14y ago

C# can "go native" right now. NGEN precompiles the IL into native code if you use the normal framework. Mono AOT compiles (and links) code into various architectures, but MonoTouch and Mono for Android (http://xamarin.com http://xamarin.com) would be the major public uses for it - native iOS / Android apps using C#. If you wonder "can they be any good": go get the new Rdio app. It's done in MonoTouch (and their Android one, in beta, is done in Mono for Android)