MS working on a same compiler for C++ AND C# ! Not in 'incubation' but for production !

This is NOT for the TSI (Technical Strategy and Incubation) but for STB (Server and Tools Business) !

This is NOT for the Bartok/Phoenix compilers but for the Visual C++ compiler !

This is NOT for an incubation project but for shipping (could be internally thought) products !

Finally some Midori ideas goes into product teams !

Hmmm....maybe .NET 5 will be the new Visual Basic 5 which compiles the P-Code to native using Visual C++ compiler.

So Going Native doesnt necessarily mean Going C++ and we can optimize for both programmer productivity and performance, how about that ?

https://careers.microsoft.com/jobdetails.aspx?jid=81769
http://www.compilerjobs.com/db/jobs_view.php?editid1=648

We are looking for a software engineer to fill a critical role in the C++ compiler team at Microsoft. The successful candidate must be able to (1) help us ship new compilers and tools (2) bang out elegant scripting code, (3) work hand-in-hand with some of the best compiler architects in the business, and (4) demonstrate a strong desire to improve all automation used to ship the tools compile all major products in Microsoft.

We offer a chance to learn compiler and system technology from the ground up while helping to shape the future of C, C++ and C#. For Windows 8, Microsoft has invested in the automatic vectorization and parallelization of unaltered C++ in an initial effort to move the entire Microsoft platform to all the new hardware from Intel, AMD and ARM. Microsoft has an ambitious agenda to take those technologies to the next level and to ship enhancements to the compiler tool chain on a quarterly cadence. We need a key engineer to help us accomplish that aggressive goal while using this as an opportunity to learn about the development of compilers and operating systems.

To accomplish this, the candidate will work on improving all the automation used to stress the compiler while building Win 8, SQL and Office. This includes development activities for an essential automation system that is used for stressing the live development compiler while helping the development team understand and resolve key failures. As Microsoft continues to advance the state of the art with automatic vectorization and automatic parallelization capabilities across dissimilar architectures the need to grow the optimizer team is a priority for the company. This compiler will be used for both C++ and C#.

Specifically this work will include:
• Creating new automation for stressing the new compiler
• Improve all the existing automation for building and stressing Windows and SQL
• Interface to the Windows, SQL, Phone and Console teams to deliver new compilers
• Work to coordinate compiler development with PM and QA teams
• Do performance analysis for code quality and throughput
• Create new harnessing and automation for a new effort to compile C# using the native C++ compiler
• Working effectively across both managed and native, compilers and runtimes.
• Learning compiler technology by working alongside senior compiler architects building new compiler technology that ships internally on a regular and short cadence
Since the compiler is used to compile all the C++ software in the company the candidate must respect mission critical correctness by helping to identify the overall quality of the compiler for throughput, correctness, performance and code size. This is a great opportunity for an engineer that would like to learn about compiler and/or system programming while making sure it ships with as little friction as possible.

https://careers.microsoft.com/jobdetails.aspx?jid=81397

We are looking for an exceptional candidate for the C++ optimizer team at Microsoft. The successful candidate must be able to (1) design new compiler innovations for both native and managed code, (2) bang out elegant code, (3) work hand-in-hand with some of the best compiler architects in the business, and (4) demonstrate a strong desire to learn. We offer a chance to help shape the future of high performance computing for many platforms by exploiting the ever wider vectors and the higher numbers of cores on each new generation of microprocessor that Microsoft will have to respond to in the next 12 to 18 months. For Windows 8, Microsoft has invested in the automatic vectorization and parallelization of unaltered C++ in an initial effort to move the entire Microsoft software platform to all the new hardware from Intel, AMD and ARM. Microsoft has an ambitious agenda to take those technologies to the next level. We want to expand that technology for both C++ and now C#.

To accomplish this, the candidate will work on improving the optimization, vectorization and parallelization phases of the Microsoft C++ compiler both for C++ and C#. This includes both significant research and/or simultaneous product development activities. As Microsoft continues to advance the state of the art with automatic vectorization and automatic parallelization capabilities across dissimilar architectures the need to grow the optimizer team is a priority for the company. Since we are taking on a managed language like C# the candidate will assist in compiling MSIL byte codes using the native C++ compiler.

Specifically this work will include:
• engineering parts of the reader for MSIL and type loader
• providing technical leadership across all the components in the new compile paths
• coordination with both the PM and QA teams
• performance analyis
• creating a native compiler internal representation the existing compiler can optimize
• the design and implementation of 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 and
• 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
• working effectively across both domains – managed and native, compiler and runtime.
Since the compiler is used to compile all the C++ software in the company the candidate must respect mission critical correctness by helping to improve the overall quality of the compiler for throughput, correctness, performance and code size as all members of the team currently do.

It's hilarious how much detail you can get about a company's strategy just by reading their job openings.

Awesome.  There's less and less reason to have a CLR or VM if you have a compiler that can take in various languages and target various architectures just as well - and better.  There's a session on auto vectorization that was just live today ... I only caught a part of it and plan to check it out this weekend.

Someone correct me if I'm wrong here, but if you have deterministic finalization that works with move semantics as you have with C++ 11, which allows you to avoid falling back to raw pointers and having to manage memory outside of destructors etc..., then performant C++ and C# become quite similar.  The compiler can make the C# behave as it would if it were managed code (GC wise ... ignoring CAS or other CLR services), but better since there's true deterministic finalization.  Since older C++ compilers didn't have move semantics for reference types, then trying to get C# code to compile down to native would result in copy semantics and horrible performance. 

Hope to see C# compiled to native code. I have seen an employeer trying to migrate C# to C++ for additional hardware support and performance. But, such task is going to be a lot harder than simple C#. This would eliminate the need for such task.

What does this mean for Anders? Will he have to answer to the native language team before any additions to C#?

@magicalclick: Assuming you were not attempting to write drivers in C#, what about it is slower or supports less hardware than C++?  (Of course, I'm assuming you are still targeting Windows...)

Case studies tend to show that C# produces better performance than C++.  I've seen where people have set out to show how bad C# performs compared to native code, and change their minds once they see the results.

This isn't meant to troll, but I'm genuinely curious since this is not the typical path taken.

20 hours ago, Richard.Hein wrote

Awesome.  There's less and less reason to have a CLR or VM if you have a compiler that can take in various languages and target various architectures just as well - and better.  There's a session on auto vectorization that was just live today ... I only caught a part of it and plan to check it out this weekend.

Someone correct me if I'm wrong here, but if you have deterministic finalization that works with move semantics as you have with C++ 11, which allows you to avoid falling back to raw pointers and having to manage memory outside of destructors etc..., then performant C++ and C# become quite similar.  The compiler can make the C# behave as it would if it were managed code (GC wise ... ignoring CAS or other CLR services), but better since there's true deterministic finalization.  Since older C++ compilers didn't have move semantics for reference types, then trying to get C# code to compile down to native would result in copy semantics and horrible performance. 

As I see it, the challenge to get C# get deterministic finalization is to make it able to break out of its dependence on the GC. Extending the language would just beef up the unsafe part of the language; what would be really cool would be to get the compiler spot by usage when a reference can be (safely and verifably) converted into an unique_ptr, a shared_ptr, or even just allocate it on the stack.

23 hours ago, Bass wrote

It's hilarious how much detail you can get about a company's strategy just by reading their job openings.

Oh its not about 'company strategy' but just some geeky technology tibits, of course its just speculating but speculating is always fun ! Especially when MS is not as open as before.

14 hours ago, SteveRichter wrote

What does this mean for Anders? Will he have to answer to the native language team before any additions to C#?

Well, I read it carefully and sometimes it actually says the compiler is compiling MSIL, so it could work like NGEN/JIT or a post-compiling phase. of course the C# frontend (Roslyn?) could be integrated too, to provide more analysis and optimizing possiblities. So basically Anders owns the frontend and VC team has the backend (or one of the backends) I guess.

9 hours ago, bondsbw wrote

@magicalclick: Assuming you were not attempting to write drivers in C#, what about it is slower or supports less hardware than C++?  (Of course, I'm assuming you are still targeting Windows...)

Case studies tend to show that C# produces better performance than C++.  I've seen where people have set out to show how bad C# performs compared to native code, and change their minds once they see the results.

This isn't meant to troll, but I'm genuinely curious since this is not the typical path taken.

Tell the news to Herb Sutter ! or read this :

https://careers.microsoft.com/jobdetails.aspx?jid=76831

Managed code can be much higher performing when it is compiled by an ahead-of-time advanced optimizing compiler to native code.

@bondsbw:

To my understanding, it is embeded system. So, I guess they don't have .Net for it. Personally I don't know the whole story behind it.

I agree with the performance statement. Although if you really start to crunch the performance, C++ is definitly faster. The caveat is, crunching that performance is very challenging and often makes more mistakes on the way. But, some companies do have the resources for that.

@Charles: Shut down Channel9 and start the ministry of truth from 1984.

That will solve all of Bill Gates's pesky problems with humanity and speculation once and for all.

@Charles: But speculation is fun...

OK. I'm fully aware of the hilariousness of speculating, but its way more funnier than waiting, right ? I'm not going to base any business decisions on that, and I believe nobody will.

As Linus Torvalds said : Just For Jun.

OMG! Is this the end of .NET?

That was fun.

19 hours ago, DeathByVisualStudio wrote

OMG! Is this the end of .NET?

That was fun.

Of course not, its a Nirvana ! of the Phoenix ! (Nirvana could be a perfect codename btw)

VB5 is not the end of VB right ? that was VB6 ...... oh wait.

No, this is just a logical thing when the CLR want to reach resource-constrained devices,
do you think the managed language teams will sit there listening Herb Sutter bragging about
the performance advantages of C++/native code and then give up and do nothing ? huh.

At least, a much-better optimized NGEN wont kill the platform right ?

20 hours ago, Charles wrote

@felix9: Good boy.

C

So, may I go on ? talking about 'incomplete technical information' or 'partial data', there are indeed so many questions and mysteries about this thing.

What about the CLR ? will it be exactly the same CLR too ? or something like SLR ? I guess the Redhawk itself is somehow dead, because a seperate and different runtime is not practical, if you can't port existing .NET code directly, then its not that useful.

Then how compatible will the language be ? IIRC Bartok has some limitations on language features right ? (could be wrong though) Can I set 'Compile to native' as a checkbox, like in VB5 ? or could it be a seperate kind of project type with some rules ?

IIRC the benefits of VB5 native compiling were limited because most of the code calls into the runtime library / COM anyway and wont gain much from native code in itself, except heavy math routines. And in the WinRT world you can always write those code in native languages. so ... I guess Herb Sutter was right about the inlining of templates, without virtual calls, C++ is still better.

What about P/Invoke and reversed P/Invoke ? IIRC one good thing about Redhawk is low cost and seamless calls between C and C# code, right ? is this why we wont need XNA anymore ?

What about the Metadata ? Reflections ? Emit ?

Hmmmm..... really want to hear someone really knows what they are talking about to talk !

IIRC the benefits of VB5 native compiling were limited because most of the code calls into the runtime library / COM anyway and wont gain much from native code in itself, except heavy math routines. And in the WinRT world you can always write those code in native languages. so ... I guess Herb Sutter was right about the inlining of templates, without virtual calls, C++ is still better.

[/quote]

yeah, I do not follow at all how a C++ WinRT app is more efficient and less power using than C# when the majority of the time the app is in the WinRT.  And if a modern C++ app is supposed to use smart pointers, how is that more efficient that C# references?  I thought the lesson learned by the designers of the GC was that reference counting was slower than garbage collecting.