@bcooley
>“There are many cases where how memory is managed for large mutable datasets gives native code a very wide margin of performance advantage.”
I am aware of some of these cases, they can usually be overcome by knowing the nature of the GC well enough (plus avoiding heap allocation whenever possible). Have yet to see an application whose performance can’t get close to the C++ one with the right optimizations. Of course, improving the garbage collector is always good but the resources of the developer team are limited.
>“completely missing the support for numeric”
While the lack of generic support for numeric types isn’t a great thing, this is definitely not a performance issue. If you want to make a high-performance numeric library, you'll often need to use the basic characteristics of the data type. You obviously can't make the same optimizations for integer and floating point numbers, and often even 32 and 64 bit integers require different algorithms to most effectively solve specific operations on them. For performance, you need to use type-specific algorithms anyway.
>“B) they realized that native level performance really matters on mobile, and so does C and C++.”
Java is pretty damn successful on Android.
>“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#.”
Well, until the language has actually proved itself well enough, moving all existing code to it doesn’t make sense. But the office team wrote its new online content in Javascript, at the times when Silverlight was having its peak (already around ~70% coverage, and no post-“shifted” madness). The Windows team introduced several new applications since .NET was published, and none of those were written in .NET (except for Media Center maybe? but seriously…). 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.
>”Interoperability with C / C++ / headers”
I actually thought you copied this stuff out of an objective-c marketing table, ‘cause you fragmented up features that are tied close together into multiple lines several times. Anyways (googled it and couldn’t find, so I guess you made it up this way yourself for some reason), 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. Possibly in the form of some extension, some automatic wrapper generator similar to how now C# communicates with WinRT. But I bet there are tons of gotchas in making something like that work.
>”Interoperability with native heap / Management of large/complex Memory/Heap Objects / GC, ref counting, and manual mm. / Direct marshalling of Memory Bufs to Heap Objects / Control of memory alignment”
I guess allowing lower-level memory management could be beneficial in some cases. Again, the C# team needs to measure how much it would lower the current advantageous characteristics of C#, and how much resources providing this feature would require from their side, which they obviously are limited with.
>”CPU Vector Instructions / CPU Auto Vectorization”
Yep, I guess it’s pretty much a matter of resources on the developer team’s side again.
>”Macro/practical metaprogramming”
I bet it’s not gonna happen. C# doesn’t have macros by design. It has several advantages that weren’t an issue 30 years ago when C++ was designed, but much clearer to see today. Ever noticed how much better VS intellisense is working with C# code compared to Visual C++? Huge part of the reason is macros.
>”Support for numeric generics“
Nope, C++ doesn’t have support for numeric generics neither, those are templates. Different breed. Generics are type-safe and support robust programming very well. Templates have whole other attributes and are useful for different scenarios.
>”Optimized Code Generation”
Oh, it’s there. The compiler optimizes the code a lot. Of course it can always be improved. By the way, there are some 3rd party tools that further optimize at least the IL as well.
>”Slow startup time”
Ngen is already there, it doesn’t eliminate the difference? I never had much issue with any of my application’s startup time, never used ngen for that purpose, so I don’t know. If not, I guess this is again a matter of resources.
>”I'll also point out that the above list looks very different for Mono, proving that "it didn't have to be this way"
Mono runs applications with severely lower performance than the .NET Framework on Windows. Really no need to comment more on this.
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. In C++, the order is pretty much the opposite (with a huge added legacy burden that make it qualify for the first two aspects even a lot worse than it would without). It could still get even a lot closer to native performance than it is today, still I wouldn’t ever expect macros to appear in it, for example.
>“There are many cases where how memory is managed for large mutable datasets gives native code a very wide margin of performance advantage.”
I am aware of some of these cases, they can usually be overcome by knowing the nature of the GC well enough (plus avoiding heap allocation whenever possible). Have yet to see an application whose performance can’t get close to the C++ one with the right optimizations. Of course, improving the garbage collector is always good but the resources of the developer team are limited.
>“completely missing the support for numeric”
While the lack of generic support for numeric types isn’t a great thing, this is definitely not a performance issue. If you want to make a high-performance numeric library, you'll often need to use the basic characteristics of the data type. You obviously can't make the same optimizations for integer and floating point numbers, and often even 32 and 64 bit integers require different algorithms to most effectively solve specific operations on them. For performance, you need to use type-specific algorithms anyway.
>“B) they realized that native level performance really matters on mobile, and so does C and C++.”
Java is pretty damn successful on Android.
>“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#.”
Well, until the language has actually proved itself well enough, moving all existing code to it doesn’t make sense. But the office team wrote its new online content in Javascript, at the times when Silverlight was having its peak (already around ~70% coverage, and no post-“shifted” madness). The Windows team introduced several new applications since .NET was published, and none of those were written in .NET (except for Media Center maybe? but seriously…). 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.
>”Interoperability with C / C++ / headers”
I actually thought you copied this stuff out of an objective-c marketing table, ‘cause you fragmented up features that are tied close together into multiple lines several times. Anyways (googled it and couldn’t find, so I guess you made it up this way yourself for some reason), 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. Possibly in the form of some extension, some automatic wrapper generator similar to how now C# communicates with WinRT. But I bet there are tons of gotchas in making something like that work.
>”Interoperability with native heap / Management of large/complex Memory/Heap Objects / GC, ref counting, and manual mm. / Direct marshalling of Memory Bufs to Heap Objects / Control of memory alignment”
I guess allowing lower-level memory management could be beneficial in some cases. Again, the C# team needs to measure how much it would lower the current advantageous characteristics of C#, and how much resources providing this feature would require from their side, which they obviously are limited with.
>”CPU Vector Instructions / CPU Auto Vectorization”
Yep, I guess it’s pretty much a matter of resources on the developer team’s side again.
>”Macro/practical metaprogramming”
I bet it’s not gonna happen. C# doesn’t have macros by design. It has several advantages that weren’t an issue 30 years ago when C++ was designed, but much clearer to see today. Ever noticed how much better VS intellisense is working with C# code compared to Visual C++? Huge part of the reason is macros.
>”Support for numeric generics“
Nope, C++ doesn’t have support for numeric generics neither, those are templates. Different breed. Generics are type-safe and support robust programming very well. Templates have whole other attributes and are useful for different scenarios.
>”Optimized Code Generation”
Oh, it’s there. The compiler optimizes the code a lot. Of course it can always be improved. By the way, there are some 3rd party tools that further optimize at least the IL as well.
>”Slow startup time”
Ngen is already there, it doesn’t eliminate the difference? I never had much issue with any of my application’s startup time, never used ngen for that purpose, so I don’t know. If not, I guess this is again a matter of resources.
>”I'll also point out that the above list looks very different for Mono, proving that "it didn't have to be this way"
Mono runs applications with severely lower performance than the .NET Framework on Windows. Really no need to comment more on this.
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. In C++, the order is pretty much the opposite (with a huge added legacy burden that make it qualify for the first two aspects even a lot worse than it would without). It could still get even a lot closer to native performance than it is today, still I wouldn’t ever expect macros to appear in it, for example.
posted by niall