Coffeehouse Thread

101 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

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

Back to Forum: Coffeehouse
  • User profile image
    blowdart

    , felix9 wrote

    As Linus Torvalds said : Just For Jun.

    No no it's Just For Jon. You see the CLR team is amazed at the Skeet's stack overflow rep. Maybe if they change the compiler he'll be stumped for a while and everyone else can get a chance to ask questions.

    Note: This is a lie.

  • User profile image
    DeathBy​VisualStudio

    , felix9 wrote

    *snip*

    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 ?

    Thanks for humoring my sarcasm. Though VB5 => VB6 is not a fair comparison. VB6 => .NET I think is more along those lines especially if some incarnation of the CLR isn't part of the Nirvana's picture.

    True about NGEN.

  • User profile image
    Blue Ink

    , SteveRichter wrote

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

    I believe that needs to be put in the right context. Garbage collection can be more performant than reference counting, so if you are designing a language that relies heavily on managed memory, a GC is the way to go. But there's the rub... C++ offers you options that allow you to express your code without using reference counting at all, possibly at the expense of memory safety.

    Take for instance an object that is not meant to survive the scope it's allocated in. Assuming it's a reference type, in C# it gets invariably allocated on the managed heap and you incur collection costs. In C++, you could use a unique_ptr, or even just allocate it on the stack. Sure, that's not foolproof, but the gains in performance and memory pressure are significant.

    That's where a smarter compiler could really help: in C++ it could be more aggressive in detecting dangerous situations; in C#, it could detect cases in which the lifetime of an object can be safely determined at compile time and get them out of the hair of the GC (and possibly onto the stack).

    This is just the tip of the iceberg, but I already rambled enough. Smiley

  • User profile image
    felix9

    Well, well, I think this 'compiler' has little to do with C++ front end, its not about trans-compile C# to C++ , I guess its all about the c2.dll aka Microsoft Optimizing Compiler.

    , blowdart wrote

    *snip*

    No no it's Just For Jon. You see the CLR team is amazed at the Skeet's stack overflow rep. Maybe if they change the compiler he'll be stumped for a while and everyone else can get a chance to ask questions.

    Note: This is a lie.

    LMAO! OK.

    sorry for the typo. Embarassed

  • User profile image
    Bass

    @Blue Ink:

    I'm no expert in this, but I think reference counting is also more predictable (latency wise) making it superior memory management method for real time applications. GC performance depends on the GC algorithm, but I never recall seeing a GC that was conclusively proven to be faster than reference counting. One thing GC does have that reference counting does not is the ability to handle circular references though.

     

  • User profile image
    JoshRoss

    , Bass wrote

    @Blue Ink:

    One thing GC does have that reference counting does not is the ability to handle circular references though.

    Isn't that why people use weak references?

  • User profile image
    Blue Ink

    , Bass wrote

    I'm no expert in this, but I think reference counting is also more predictable (latency wise) making it superior memory management method for real time applications. GC performance depends on the GC algorithm, but I never recall seeing a GC that was conclusively proven to be faster than reference counting. One thing GC does have that reference counting does not is the ability to handle circular references though. 

    The performance of reference counting is pretty much constant with respect to the amount of available memory. Conversely, garbage collectors will improve steadily as you add more memory (interesting special case when the amount of memory is infinite). So, if GC's aren't ahead right now, they will eventually be.

     

  • User profile image
    jalfd

    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.

    But for an application where it makes sense to talk about performance *at all*, the majority of the time will *not* be spent in WinRT.

    But, and this is the important point, no one said anything about reference counting.

    Smart pointers != shared pointers.

    Shared pointers use reference counting, and they are *a* form of smart pointer. They are, by far, the slowest kind of smart pointer, and certainly not the first one you should look to.

    Most of the time, you can/should use something like unique_ptr, which is, well, optimal. There is literally no overhead to using it.

    And even smart pointers aren't the final word. They are just a single example of RAII. RAII is how *all* resources in C++ are managed. Not just memory, but sockets, files, locks and anything else.

    And resource management is not the reason why C++ can be faster than C#. The reason for *that* is that C++ supports a number of way to produce zero-overhead abstractions.

     

    So really, you're barking up the wrong tree. Overuse of shared pointers is one way in which (bad) C++ code can be made incredibly slow. But no one said to use shared pointers everywhere in modern C++ code. They said to use *smart pointers*.

     

    If you just tag a reference count onto every object in C++, then it's going to be slow. But in C++, you don't *need* to reference count the vast majority of objects, because you (and the compiler) *know* when they should be destroyed (hint: when they go out of scope)

  • User profile image
    SteveRichter

    , jalfd wrote

    Most of the time, you can/should use something like unique_ptr, which is, well, optimal. There is literally no overhead to using it.

    How does unique_ptr work?   Why do you have to use the move function when assigning 1 unique_ptr to another?

      unique_ptr<wstring> pMsg(new wstring) ;  *pMsg = L"The unique_ptr class supersedes auto_ptr" ;  ::OutputDebugString(pMsg->c_str( )) ;//  auto pMsg3 = pMsg ;  // compile error.  auto pMsg3 = move(pMsg) ;  ::OutputDebugString(pMsg3->c_str( )) ;

    and how to build a collection of unique_ptr?

      vector<unique_ptr<wstring>> msgList;  msgList.push_back(pMsg3) ;  // compile error.

     

    http://msdn.microsoft.com/en-us/library/dd293668.aspx
    http://msdn.microsoft.com/en-us/library/ee410601.aspx#2

     

  • User profile image
    banjomatic

    @SteveRichter: unique_ptr is non-copyable by design as the unique_ptr owns the memory. If you want to transfer ownership, you need to std::move otherwise you'd have two unique_ptr's owning the same data (violating the uniqueness).

    If you want to share ownership of memory between multiple smart pointers, you would use shared_ptr instead as its reference count is adjusted on copy/assignment, etc.

    As for the std::vector of std::unique_ptr, this can be done with emplacement, this will construct the unique_ptr inside the vector itself with the raw pointer passed in. But i think with move semantics, std::vector<std::wstring> might be more appropriate.

     

    I'm still figuring out all of the c++11 guidance myself, but maybe something like this:

    std::wstring msg(L"The unique_ptr class supersedes auto_ptr");
    ::OutputDebugString(msg.c_str( ));
    msgList.push_back(std::move(msg));


  • User profile image
    SteveRichter

    , banjomatic wrote

     

    I'm still figuring out all of the c++11 guidance myself, but maybe something like this:

    1
    2
    3
    std::wstring msg(L"The unique_ptr class supersedes auto_ptr");
    ::OutputDebugString(msg.c_str( ));
    msgList.push_back(std::move(msg));


    got it. thank you. I ask about collections because they are a basis of XAML programming, I am kind of sceptical of C++ collections performing well and being easy to use.

     

     

  • User profile image
    AlejoLanza

    Sounds like after failing to get C++/CX accepted, MS will try by turning C# as its native language. Once that happens, will MS keep investing in C++ as well?

  • User profile image
    spivonious

    @AlejoLanza: I'd be glad to see C++ go away for Windows development. Native C# would beat it in usability and at least meet it in performance.

  • User profile image
    evildictait​or

    , SteveRichter wrote

    I thought the lesson learned by the designers of the GC was that reference counting was slower than garbage collecting. 

    Reference counting is orders of magnitude faster than performing a GC.

    The reason .NET and other managed languages choose a GC is it detects circular references.

    Consider a linkedlist with reference counting:

    func main()
    {

    LinkedListNode i = new LLNode();
    // ref count of i = 1
    LinkedListNode j = new LLNode();
    // ref count of j = 1
    i->Flink = j;
    // ref count of i = 2
    j->Blink = i;
    // ref count of j = 2

    i = nullptr;
    // ref count of i = 1
    j = nullptr
    // ref count of j = 1

    }

    So now we've leaked i and j. Nobody points to them, but their ref-count is 1 (and hence won't be deleted) since i points to j and j points to i.

    GC solves this problem by saying that both i and j are not reachable at the end of main, and hence are eligible for collection.

  • User profile image
    objectref

    Hi,

    any news on this project ?

  • User profile image
    felix9

    Nope. but the job has been posted again recently, still hiring I guess.

    But, in the WP8 Cloud JIT story something called MDIL was revealed, dont know if its related but quite possible, because MDIL seems to be at the right level a native optimizer could be working on.

  • User profile image
    objectref

    A WP8 app written in C#, gets automatically compiled to native ARM code when you submit it on the Store, so no there is no JIT anymore there.

    Wondering if we will see this on the Desktop too...

  • User profile image
    Ultrahead

    Any news (official or not) about the compiler?

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.