Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

bcooley

bcooley bcooley

Niner since 2006

  • Future directions for C# and Visual Basic

    @niall:

    > While the lack of generic support for numeric types isn't a great thing, this is definitely not a performance issue.

    Agreed.  It's a nasty papercut.  But issues like these really do put off native developers.  I can't say that this alone had anything to do with the move back to C++, but well who knows.

    >"B) they realized that native level performance really matters on mobile, and so does C and C++."
    Java is pretty damn successful on Android.

    Yes, and so is C++. 

    Lots of native apps are written on android, including Mono.  Mono is also native on Android via C++.  And mono can also run native on android.

    > I guess the outside communication was "we don't use it due to performance issues", but as I said, just watch as they are now opening to Javascript and the excuses will change, just the real intention won't.

    i don't know anything about the internal politics of MS, but I actually do think that the internal teams would probably have preferred to use C# for both Windows components and Office. 

    >"Interoperability with C / C++ / headers"
    I can't really comment on it, but doubt this one is gonna happen, this would mean that the future characteristics of C++ (partially) define the future characteristics of C#, and would stop C# from being an independent language.

    Mono will be addC++ interop in an upcoming release (at least they've blogged about it).  Their interop uses a C++ compiler to automatically generate interop assembly code that can be directly consumed from C#.

    >"Optimized Code Generation"

    No, the code generated by the jitter is not well optimized, simply because there is no time to optimize it.  .NET's jitter does not do hotspot optimization, and NGEN does not optimize. 

    Mono compiles AOT using LLVM, which is apple's optimizing C++ compiler backend.

    > Anyways, in C#, features that support manageability and extensibility of large code bases will always be favored over ones that improve performance but lower the first two. Performance is the secondary goal.

    Well, that's too bad for Microsoft's .NET I guess.  I wonder how having to move the Windows 8 platform to C++ and javascript will help managability and extensibility?

  • Future directions for C# and Visual Basic

    I'll also point out that the above list looks very different for Mono, proving that "it didn't have to be this way".

  • Future directions for C# and Visual Basic

    Here is a comparison of iOS/Objective C and .NET in terms of what Objective-C supports that .NET does not that makes it work for Apple -> in the primary dev language role -- the role that .NET has largely been a failure for at Microsoft.

    Interoperability with C           ObjC/Yes    .NET/PInvoke

    Interoperability with C++       ObjC/Yes    .NET/No(very difficult)

    Interoperability with C/C++ headers      ObjC/Yes     .NET/No

    Cost of call to native code                 ObjC/None     .NET/Thunk

    Optimized Code Generation   ObjC/Yes   .NET/No

    CPU Vector Instructions          ObjC/Yes      .NET/No

    CPU Auto Vectorization     ObjC/Yes     .NET/No

    Management of large/complex Memory/Heap Objects          ObjC/Yes       .NET/No

    GC, ref counting, and manual mm.        ObjC/Yes      .NET/GC only.

    Direct marshalling of Memory Bufs to Heap Objects        ObjC/Yes     .NET/No  (Ever wonder why it takes so long for game levels to load in .NET?)

    Control of memory alignment             ObjC/Yes         .NET/No

    Support for numeric generics            ObjC/Yes(C++)     .NET/No

    Macro/practical metaprogramming       ObjC/Yes(C preprocessor)      .NET/No

    Large working set sizes                 ObjC/No                   .NET/Yes

    Slow startup time                           ObjC/No                  .NET/Yes

    -------------

    This is a very long list of very important missing features in .NET vs. Objective-C.  This doesn't mean that .NET isn't useful as a high level application platform (like Java), but it does mean that it simply can't fill the role that Objective-C fills for OSX/iOS as the primary dev platform for Windows 8  or Win Mobile.  This is the reason for the resurgence of C++ at Microsoft for WinRT and mobile.

     

  • Future directions for C# and Visual Basic

    "Yep, with a lot of work, that few percent performance overhead C# currently has over C++ could have been almost completely removed. They chose to improve other areas that they considered more important."

    @niall I understand where you're coming from, and trust me we're on the same side as far as preferring the 3-10% loss in performance vs. native.  Unfortunately there's quite a bit of native code out there, and actually native performance and native interoperability does really matter.

    Imagine if you were an Office programmer with 2-3 million lines of C/C++ code and you were told that over the next 3 years the team would be moving exclusively to C#.  Would that make sense?  If you understand why it doesn't, you'll understand where .NET went wrong during Vista and the continuing problems with where it is now.

  • Future directions for C# and Visual Basic

    @rab36:  I agree.  Microsoft has pulled off unifying it's previously fractured platform again with WinRT, and looks to have positioned itself well into the future.  Unfortunately for .NET that unification revolves around native code and C++, and not .NET.  Sure there is nothing preventing anyone from writing apps in .NET, but it is not at the core of the platform, and it will not offer either the performance, nor easy interoperability with traditional C++ libraries.   The platform is built on C++.  The reason for this is simple: performance and interoperability with existing C and C++ code.

    As a comparison, take a look at the iOS/OSX platform, which revolves around Objective C.  Objective C is somewhat hobbled by it's reliance on selectors, which use a form of optimized dynamic dispatch.  However Objective C actually "is" C and C++.  C and C++ code can be intermixed freely in Objective C, you do not pay a penalty for JIT compilation, and code that does not use Objective C selectors runs with the same performance as any C/C++ function, and there is no GC penalty.

    Contrast the strategy.  In the mid 200x's Microsoft introduced Win/FX with WPF, WCF, and other major .NET based replacements for the native level Windows platform.  Apple introduced Cocoa and the other NS based "kit" libraries for OSX.  The .NET Windows platform is now deprecated on on it's way out in favor of the native Win 8 platform, while Cocoa became the standard platform across all apple devices.  

    Native performance and tight interop with C and C++ won on both platforms.  Java has been deprecated on iOS, and .NET has been put in 2nd place (though certainly it is NOT deprecated) on Windows 8.  

    My post and original point was that it really didn't have to be this way.

  • Future directions for C# and Visual Basic

    @Novox:

    Precisely.

    That, and I suspect that the Core desktop and application (Office) teams also put their collective feet down and insisted that the future platform not sacrifice native level performance

    There's really so much that could be done to improve managed performance.  Eliminating some of the thunking overhead by re-engineering the native compilers to be more managed friendly.  Moving operations that would require native/managed interop into C#/VB.   The biggest optimization that was never done was to AOT/NGEN managed code and add it to the cache using an optimizing compiler.  Mono has done this for mobile platforms with LLVM, not microsoft.  I really don't understand what the benefit is of running the JIT on all code each time it's run.. it slows performance and disallows serious optimiztion.

    There's also the issue of a very poor interop experience with C and C++ code from managed code.  PInvoke worked for C code but required transliteration of anything in the header files, but never for C++, and that put most C++ library access out of reach for managed code.  No effort has really been put forward to solving these issues, or even admitting that they exist.

    In any case, it's really a lost opportunity to push what is really a better platform towards covering more of the development stack, at least down into large complex applications, scientific work, or games.  Instead the core and app teams decided to fix the module and platform issues with C++ and move forward.

     

  • Future directions for C# and Visual Basic

    @Mc

    I spent a bit of time hovering over the keyboard before clicking "Comment", even returned a while later to re-read the post, and decided to leave the post as is.  It just needed to be said.  

    If you check Microsoft Connect, you'll see that there are quite a few outstanding issues related to performance and access to the CPU and GPU.  These issues date from as long ago as 2004 (lack of support for numerical operations in generics).  There is still really no way to fully or easily access the power of either the CPU or GPU through .NET without dropping into native code, and even there you're dealing with thunking issues.  This matters because .NET is the primary development platform for mobile devices, and these devices are underpowered relative to the desktop.

    I fully appreciate that the old C/C++ infrastructure for the VB/C# compiler needs to be replaced, and that there is a nice upside to this in that it simplifies support for refactoring and other IDE features.  However it's simply far more important to address the performance issues with the platform as a whole, and to recognize that it's primary use is no longer necessarily on desktops with desktop level cpu power, and not necessarily being used to write desktop web or LOB apps.

     

  • Future directions for C# and Visual Basic

    So, essentially what the .NET team has been working on for the last four years is async (yes. absolutely amazing stuff) and then to follow that up..  wait for it..  a Microsoft version of Resharper?(!!!)  

    Seriously.. C# vNext is going to be nothing more than access to the compiler so that we can build our own refactorings for visual studio?  Who really needs that?

    In the mean time, Herb Sutter and the rest of the Windows core group have realized that performance actually matters and fixed C++.   Do we have access to the fully power of the CPU or GPU in .NET?  No.  Do we have auto-vectorization in the .net runtime?  Do we have access to vector instructions in any form?  Do we have proper numeric generic support for games or scientific computing?  Has anyone spent any time whatsoever on narrowing the gap between native and managed?  How about something on the order of Mono's LLVM optimizing native AOT compiler???

    F# at least has type providers.. which are modestly useful to somebody.

    Honestly.. what the hell have you guys been doing?

    Respectfully.. Benjamin Cooley