Coffeehouse Thread

101 posts

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

Back to Forum: Coffeehouse
  • User profile image
    felix9

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

    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.

    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.

  • User profile image
    Bass

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

  • User profile image
    Richard.Hein

    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. 

  • User profile image
    magicalclick

    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.

    Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.
    Last modified
  • User profile image
    SteveRichter

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

  • User profile image
    bondsbw

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

  • User profile image
    Blue Ink

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

  • User profile image
    felix9

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

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

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

  • User profile image
    magicalclick

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

     

    Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.
    Last modified
  • User profile image
    Charles

    I'd encourage you to not speculate on incomplete technical information in a job description or at least don't base conclusions on partial data...

    Wait for the folks who know what they're talking about to talk about what's really going on  when they have something complete to share.

    C

  • User profile image
    01001001

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

  • User profile image
    Sven Groot

    @Charles: But speculation is fun...

  • User profile image
    Charles

    , Sven Groot wrote

    @Charles: But speculation is fun...

    Indeed it is. Just don't take it too seriously (it's fun...) Smiley
    C

  • User profile image
    felix9

    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.

  • User profile image
    Charles

    @felix9: Good boy.

    C

  • User profile image
    DeathBy​VisualStudio

    OMG! Is this the end of .NET? Wink

    That was fun.

  • User profile image
    felix9

    , DeathByVisualStudio wrote

    OMG! Is this the end of .NET? Wink

    That was fun.

    Of course not, its a Nirvana ! of the Phoenix ! Smiley (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 ?

    , 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 !

  • User profile image
    SteveRichter

    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.

     

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.