4 ms·
It's worth nothing that if this approach becomes popular, it raises the bar for running code from Windows on top of Mono without any changes, although this ofte
by _wmd 12y ago
It's worth nothing that if this approach becomes popular, it raises the bar for running code from Windows on top of Mono without any changes, although this often never worked anyway except for simpler apps with few deps
At least for me, this was a small original appeal of C#/Mono
- pjmlp 12y ago> It's worth nothing that if this approach becomes popular I hope so. In the 90's we had strong typed languages with native compilers, somehow we got into this VM detour because everyone wanted to create applets. And those languages[1], for multiple reasons faded away. [1] Oberon(-2), Object Pascal, Modula-2, Modula-3, ...
- mbel 12y agoVery true. It's not exactly rational, but it always makes me sad when I realize that popularity of given language only slightly depends on quality of its design (Haskell seems to be a counter example, it survived years in obscurity and now seems to gain popularity).
- skrebbel 12y agoI don't see how: it always goes via MSIL and Mono runs MSIL. Admittedly, apps or libraries published solely as "native" binaries won't run on Mono, but I strongly suspect that those are typically native end-user apps which are very often Windows-specific already. Windows Store stuff, and similar. (I also strongly suspect that this entire "native" move was fueled purely by that top-of-the-bill Windows 8 computers take 5 seconds to start up the damn Weather app) On the library side, there's a strong move towards the opposite, actually: you can now make a (MSIL) DLL that runs on Windows, Windows Phone, iPhone, Android, Mono, etc etc without having do distribute different versions (basically, what Java always had) of the binary. It's overdue, but it's really nice. I'm not worried (and I run a dev team that runs a C# backend on mono/linux).
- bunderbunder 12y agoI also strongly suspect that this entire "native" move was fueled purely by that top-of-the-bill Windows 8 computers take 5 seconds to start up the damn Weather app Bingo. Especially on 64-bit machines, the time it takes for apps to launch can be downright embarrassing.
- Locke1689 12y agoKind of. If you fully understand Microsoft's portfolio it makes more sense. Desktop Windows 8 is a scenario, but not a very good representative. While 64-bit JIT time can take a while and CLR startup time can be really long, both of these things can be addressed in a variety of ways in vanilla Windows machines, ranging from NGen improvements to CLR pre-loading strategies. The real killer is alternate platforms. Every time you JIT in a mobile device it wastes time, CPU power, and battery life, all of which are much more limited than in a desktop machine. CLR startup can be mitigated somewhat, but resident memory is an especially precious commodity on mobile. The last real kicker is that security concerns mean that many platforms (XBox) mark a lot of their pages as NX, making JIT-ing in these pages very difficult or impossible. Moreover, better security infrastructure means doing this on more platforms more of the time, so this will become increasingly problematic. All together, this makes a very compelling case for AOT compilation.
- Maarten88 12y agoThe Weather App, as I understand it, is built by the Bing team, who use WinJS (javascript) for their apps. This native compiler backend is for .NET, so they wont benefit from this at all.
- skrebbel 12y agoDamn, there goes my theory. But then why the hell so slow?
- chinpokomon 12y agoIt was vastly improved with the 8.1 Update 1, but I'll grant you it was depressingly slow on Windows 8 and the 8.1 upgrade.