5 ms·

You are reading too much into events. MS likes Miguel because he brings some open source respectability to the NET platform. It is also a potential source of li

by teyc 15y ago

You are reading too much into events. MS likes Miguel because he brings some open source respectability to the NET platform. It is also a potential source of licensing revenue stream in the future. MS has no reason to want someone else's implementation of the CLR and VM.

DiabloD3 15y ago
Mono's VM executes C# bytecode faster than Microsoft's, and Mono's C# compiler produces better bytecode than Microsoft's. So, yeah, Microsoft is very interested in trying to make their core product faster so they can catch up to other solutions such as native code (C/C++) or Java (C# is still typically much slower than Java). Oh, and Mono can also compile to AoT binaries, which do not require Mono/.Net installed on the target system, such as being able to target iOS under Apple's anti-VM policy. Microsoft is very interested in all of these.
- jahewson 15y ago
  Complete nonsense: - Microsoft's CLR is vastly more sophisticated than Mono, involving millions of man-hours work, unless you show me a benchmark I have absolutely no reason to believe it executes bytecode faster, especially given that Microsoft Research publish papers on fast JIT [1]. - Mono still doesn't have a stable generational GC [2], I hope you like memory leaks and long pauses. - .NET can compile AoT binaries, and does this for all built-in libraries using ngen [3] In conclusion: Microsoft have no interest in any of Mono's technologies. [1] http://research.microsoft.com/en-us/projects/spur/ http://research.microsoft.com/en-us/projects/spur/ [2] http://mono-project.com/Generational_GC http://mono-project.com/Generational_GC [3] http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.71).aspx http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.71).as...
  - iam 15y ago
    Ngen still requires the CLR to be present though.
  - rodrigokumpera 15y ago
    Few things to notice here. Mono's new gc is quite solid now. Mono for Android customers use it by default. Yes, performance is not the best nor does it support a concurrent mode. But a garbage collector is one of those projects that is never done and always have an infinite amount of work left. Our gc has been improving a lot and the next release, for example, features a lot of scalability and performance work. Said that, if you compare it to other gcs offered on mobile environment we're doing very well. Mono features a much simpler JIT and runtime and this is a competitive advantage for us or do you think MS ships its desktop/server VM on winphone? We do, and it has teached us a lot about how been slim and simple makes you much more adaptable. Now on the subject of AOT, mono features a much more sofisticated system than .net, it's the only one that supports running without a JIT while retaining generics. BTW, I work for Xamarin but those are my personal opinions on the matter.
  - jstedfast 15y ago
    Hey, Xamarin dev here... Not that I want to defend Diablo-D3 (he's a troll), I do want to make a few slight corrections to your comment. 1. You are correct in that Microsoft's .NET VM performs better than Mono overall (at least in the general case), but Mono does perform better than .NET in some cases. Unfortunately I don't have a list of the areas where Mono outperforms .NET handy, so I can't list them here. Perhaps one of the other Mono devs can follow up and provide details. Most likely SIMD would be on the list. Whether Microsoft would be interested in taking Mono's implementation for these areas or not for their own VM is questionable. Likely not, as it would likely not be easily adaptable to their implementation anyway. 2. SGen is actually stable these days. It is used in Mono4Android and we are working on moving MonoTouch over to SGen as well. Moonlight was also being moved to SGen (it started out using Boehm because that was the default GC when the project was started) when the Novell layoffs came along. As responsible developers, we have been taking our time moving to SGen as the default GC because we don't want the move to break any existing apps if we can avoid it. As with all new things, there are still likely to be bugs here and there, but overall we feel that it is ready for use and we've been eating our own dog food. 3. As was mentioned in another comment already, Microsoft's AOT isn't quite the same as Mono's AOT which allows generation of binaries that do not require an external CLR to run.
    - jahewson 15y ago
      Glad to here that SGen is stable now, of course turning it on by default in Mono is the true test of 'stable', but as you say it's reckless to break things needlessly. There was once an entire company called Xenocode, founded by ex-MS devs, and built on the idea that it would be really useful to distribute .NET apps without the CLR. They had a tool which could do this, even with ngen'd assemblies. Turned out it wasn't so useful. They've now pivoted into enterprise application virtualisation, and their offering is similar to Softricity, which later became Microsoft App-V.
      - jstedfast 15y ago
        Distributing .NET apps w/o a CLR is probably the biggest strength of Mono - it's how Mono is able to work on iPhone, Wii and other devices which do not allow dynamic code generation. I would say that Xenocode's failure wasn't so much that no one found .NET w/o a CLR useful, it was that they likely only supported Windows. Oh well, Xenocode's loss is our gain :-)
- MichaelGG 15y ago
  Microsoft is very interested in AoT binaries that don't require a runtime installed? Microsoft has specifically said they have no plans to pursue this path, even though they could obviously do so. The reasons was that they didn't want to deal with patching all these programs that had the runtime embedded in them. I found that sort of a weak argument; they probably just wanted to get higher penetration numbers.
- teyc 15y ago
  Have you even tried to submit a patch to Microsoft for one of their Microsoft Shared-Source projects (there is a list here: http://www.microsoft.com/resources/sharedsource/default.mspx http://www.microsoft.com/resources/sharedsource/default.mspx ), ? It is near impossible to get MS to accept them. They will give away code, but paranoid about taking contributions.

by teyc 15y ago

DiabloD3 15y ago

Mono's VM executes C# bytecode faster than Microsoft's, and Mono's C# compiler produces better bytecode than Microsoft's. So, yeah, Microsoft is very interested in trying to make their core product faster so they can catch up to other solutions such as native code (C/C++) or Java (C# is still typically much slower than Java). Oh, and Mono can also compile to AoT binaries, which do not require Mono/.Net installed on the target system, such as being able to target iOS under Apple's anti-VM policy. Microsoft is very interested in all of these.

jahewson 15y ago
Complete nonsense: - Microsoft's CLR is vastly more sophisticated than Mono, involving millions of man-hours work, unless you show me a benchmark I have absolutely no reason to believe it executes bytecode faster, especially given that Microsoft Research publish papers on fast JIT [1]. - Mono still doesn't have a stable generational GC [2], I hope you like memory leaks and long pauses. - .NET can compile AoT binaries, and does this for all built-in libraries using ngen [3] In conclusion: Microsoft have no interest in any of Mono's technologies. [1] http://research.microsoft.com/en-us/projects/spur/ http://research.microsoft.com/en-us/projects/spur/ [2] http://mono-project.com/Generational_GC http://mono-project.com/Generational_GC [3] http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.71).aspx http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.71).as...
- iam 15y ago
  Ngen still requires the CLR to be present though.
- rodrigokumpera 15y ago
  Few things to notice here. Mono's new gc is quite solid now. Mono for Android customers use it by default. Yes, performance is not the best nor does it support a concurrent mode. But a garbage collector is one of those projects that is never done and always have an infinite amount of work left. Our gc has been improving a lot and the next release, for example, features a lot of scalability and performance work. Said that, if you compare it to other gcs offered on mobile environment we're doing very well. Mono features a much simpler JIT and runtime and this is a competitive advantage for us or do you think MS ships its desktop/server VM on winphone? We do, and it has teached us a lot about how been slim and simple makes you much more adaptable. Now on the subject of AOT, mono features a much more sofisticated system than .net, it's the only one that supports running without a JIT while retaining generics. BTW, I work for Xamarin but those are my personal opinions on the matter.
- jstedfast 15y ago
  Hey, Xamarin dev here... Not that I want to defend Diablo-D3 (he's a troll), I do want to make a few slight corrections to your comment. 1. You are correct in that Microsoft's .NET VM performs better than Mono overall (at least in the general case), but Mono does perform better than .NET in some cases. Unfortunately I don't have a list of the areas where Mono outperforms .NET handy, so I can't list them here. Perhaps one of the other Mono devs can follow up and provide details. Most likely SIMD would be on the list. Whether Microsoft would be interested in taking Mono's implementation for these areas or not for their own VM is questionable. Likely not, as it would likely not be easily adaptable to their implementation anyway. 2. SGen is actually stable these days. It is used in Mono4Android and we are working on moving MonoTouch over to SGen as well. Moonlight was also being moved to SGen (it started out using Boehm because that was the default GC when the project was started) when the Novell layoffs came along. As responsible developers, we have been taking our time moving to SGen as the default GC because we don't want the move to break any existing apps if we can avoid it. As with all new things, there are still likely to be bugs here and there, but overall we feel that it is ready for use and we've been eating our own dog food. 3. As was mentioned in another comment already, Microsoft's AOT isn't quite the same as Mono's AOT which allows generation of binaries that do not require an external CLR to run.
  - jahewson 15y ago
    Glad to here that SGen is stable now, of course turning it on by default in Mono is the true test of 'stable', but as you say it's reckless to break things needlessly. There was once an entire company called Xenocode, founded by ex-MS devs, and built on the idea that it would be really useful to distribute .NET apps without the CLR. They had a tool which could do this, even with ngen'd assemblies. Turned out it wasn't so useful. They've now pivoted into enterprise application virtualisation, and their offering is similar to Softricity, which later became Microsoft App-V.
    - jstedfast 15y ago
      Distributing .NET apps w/o a CLR is probably the biggest strength of Mono - it's how Mono is able to work on iPhone, Wii and other devices which do not allow dynamic code generation. I would say that Xenocode's failure wasn't so much that no one found .NET w/o a CLR useful, it was that they likely only supported Windows. Oh well, Xenocode's loss is our gain :-)
MichaelGG 15y ago
Microsoft is very interested in AoT binaries that don't require a runtime installed? Microsoft has specifically said they have no plans to pursue this path, even though they could obviously do so. The reasons was that they didn't want to deal with patching all these programs that had the runtime embedded in them. I found that sort of a weak argument; they probably just wanted to get higher penetration numbers.
teyc 15y ago
Have you even tried to submit a patch to Microsoft for one of their Microsoft Shared-Source projects (there is a list here: http://www.microsoft.com/resources/sharedsource/default.mspx http://www.microsoft.com/resources/sharedsource/default.mspx ), ? It is near impossible to get MS to accept them. They will give away code, but paranoid about taking contributions.