9 ms·

Announcing .NET Native Preview

159 points by xyziemba 13y ago

tdicola 13y ago
I'm kind of scratching my head here, can someone explain what problem this solves? There's already a CLR and already a way to build native apps for Win 8, etc. This is a new CLR that can run new 'native' apps?
- spo81rty 13y ago
  CLR apps require just in time compiling which can take a little time to first run. So this should speed up opening the apps.
  - tdicola 13y ago
    Sure, but ngen solved that problem years ago: http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).aspx http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).a...
    - itsboring 13y ago
      Yeah, and mono's AOT too. I wonder if this is really just ngen integration into VS and thus not really a big deal.
    - spo81rty 13y ago
      So I guess this is ngen in the cloud to skip doing it on the PC.
      - sriramk 13y ago
        If I remember ngen is very architecture/platform specific - that is why it has to be done on the target machine. This sounds like it is done ahead of time with support for a variety of architectures.
    - andyjohnson0 13y ago
      See https://news.ycombinator.com/item?id=7520687 https://news.ycombinator.com/item?id=7520687
  - itsboring 13y ago
    It seems like this is basically just the same thing that Mono has done for a long time with AOT. I'm not really sure how it differs from the Ngen tool, though.
    - apardoe-MSFT 13y ago
      .NET Native addresses many of the same issues as Mono AOT but it has a radically different basis. We had the advantage of hindsight :) The biggest difference with NGen is the fact that .NET Native doesn't ever "fall back" to JIT compiled code. There are other differences--refactored runtime, static-optimized libraries, static marshalling, etc.--which can be seen by the perf wins over NGen. We're seeing 40% startup performance gain over NGen apps for top Windows Store apps.
      - rajeevk 13y ago
        @apardoe, one question: where will the compilation to machine instruction happen? From some comments in this thread, it seems that it will happen at app store server and not at developer's box. If that is the case then why will I need anything to do any settings in VS for building projects?
        apardoe-MSFT 13y ago
        @rajeevk, we could compile from MSIL and not tell the developer. But you probably appreciate the chance to test out the app on your own the way your user will run it. After all, you'll want to profile it or maybe find that last on-device, optimized-only bug...
        thomasz 13y ago
        What about stuff like Il.Emit and Expression<T>.Compile
        apardoe-MSFT 13y ago
        Reflection.Emit isn't allowed in the Windows Store profile so we haven't handled it in this go-around. Expression compile is supported and handled properly.
- plorkyeran 13y ago
  It gives faster startup time (due to AOT compilation rather than JIT), and doesn't require that the .NET framework be installed. Possibly better runtime performance, but I wouldn't expect huge gains there. P/Invoke should have lower overhead, which may be highly relevant for some things. I suspect that there's things that require this which they haven't announced yet, since on its own it seems like something kinda nice but not beneficial enough to justify creating.
  - tdicola 13y ago
    Yeah I don't understand the need to get rid of a .NET framework dependency though. This only supports building Windows store apps, which only run on devices that have the .NET framework right now...
    - itsboring 13y ago
      One admittedly crazy theory is that this is laying the groundwork for building iOS apps and therefore would compete with Xamarin. Any kind of JIT would not be allowed on the iOS app store.
      - deleted 13y ago
        [deleted]
      - tsenkov 13y ago
        The word is, that Microsoft is talking with Xamarin about a possible acquisition.
  - ebiggs 13y ago
    Start up times could be a big deal to compete with iOS? Especially in similar app lifecycle models where apps could be stopped and restarted implicitly by the OS?
  - Someone 13y ago
    "It [...] doesn't require that the .NET framework be installed." Are you sure? You still need the standard libraries, a garbage collector, its security checks when loading other code, and may want to use its compiler from your code. Together, that's a lot, maybe all, of what's in the framework.
DevKoala 13y ago
What is the difference between this and NGEN? Anybody?
- bskap 13y ago
  NGEN caches native code on the machine. You're still running from the CIL executable and you still need to have the framework installed, it just loads the machine code from the cache instead of JITing it. This appears to generate a native executable.
  - DevKoala 13y ago
    Thank you.
- pantaloons 13y ago
  No MDIL. NGEN can still JIT for things like cross domain generics and because it loads non-native code, still needs to optimize at run time. Project N compiles to fully native code, so there can be no JIT, and significantly smarter optimizations can happen since they don't impact performance at runtime.
  - DevKoala 13y ago
    Thank you.
  - apardoe-MSFT 13y ago
    @Pantaloons: Right on all counts. One clarification: .NET Native and MDIL are orthogonal. MDIL was used in Triton to split NGen into conceptually two pieces: the optimized part (in the Windows Phone Store) and the part bound on the customer's device to the installed Framework. .NET Native produces completely native binaries. MDIL/Triton produces NGen binaries that still need a runtime and, occasionally, a JIT.
    - shanselman 13y ago
      And Triton is...
overgard 13y ago
Do native apps still require a preinstalled CLR?
- plorkyeran 13y ago
  No. Second entry in the FAQ (http://msdn.microsoft.com/en-US/vstudio/dn642499.aspx http://msdn.microsoft.com/en-US/vstudio/dn642499.aspx).
  - overgard 13y ago
    Damn, that's awesome! For the longest time that was the only thing that really bothered me about writing .NET code.
    - chc 13y ago
      But doesn't anyone with the Windows Store already have the CLR?
      - overgard 13y ago
        Probably -- I don't care too much about the windows store, I'm more excited about being able to write C# code that doesn't require a VM. Not that there's anything /wrong/ with the CLR, but one thing I miss about C++ when I'm not writing it is self contained programs where it's just a small exe without a bunch of huge dependencies.
        moron4hire 13y ago
        I think you're forgetting about the Visual C++ 20xx Redistributables. They aren't exactly tiny. https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture3.PNG https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture3.PNG vs. the latest .NET install https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture4.PNG https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture4.PNG This is a brand new Windows 8.1 computer.
modeless 13y ago
So, uh, can I compile my C# app to an bare x64 .exe file, statically linked with no runtime dependency on the .NET Framework, that will run on Windows 7 and 8? Or not? Edit: This is a much better link: http://msdn.microsoft.com/en-US/vstudio/dn642499.aspx http://msdn.microsoft.com/en-US/vstudio/dn642499.aspx Still not sure though, as they say "only Windows Store apps can be created" which sounds suspiciously like "no".
- jimmcslim 13y ago
  From the original link they say "Today's preview supports Windows Store applications. We will continue to evolve and improve native compilation for the range of .NET applications." which suggests to me that it might be on the radar. However the scope of Windows desktop or server applications is obviously much broader, so it might be a harder problem to solve there.
  - apardoe-MSFT 13y ago
    @jimmcslim Quite right, the smaller Windows Store profile is a more scoped target. But everything is on the radar.
- mgraczyk 13y ago
  It sounds like that's the plan (from your link): "However, apps will get deployed on end-user devices as fully self-contained natively compiled code (when .NET Native enters production), and will not have a dependency on the .NET Framework on the target device/machine."
- deleted 13y ago
  [deleted]
api 13y ago
Only for Windows store? So who thinks walled gardens and feudalization are coming to all desktop OSes in the next 5 years? In the future, a store / certificate authority will be able to arbitrarily revoke your right to run anything on your computer that isn't approved.
- apardoe-MSFT 13y ago
  Today, Windows Store. Tomorrow, the world! :)
- tonyedgecombe 13y ago
  Compiled in the cloud as well: "Our compiler in the cloud compiles the app using .NET Native in the Store, creating a self-contained app package that’s customized to the device where the app will be installed."
- ksk 13y ago
  >In the future, a store / certificate authority will be able to arbitrarily revoke your right to run anything on your computer that isn't approved We're already there with Web Apps and other SaaS "innovative" technologies.
VexXtreme 13y ago
So is this going to work on Linux?
keithwarren 13y ago
It seems the comments area here is full of lots of questions and few answers. Let me try to clear some things up. Lets start with how it currently works... When you create an application or website in C#,F#,VB.NET or any other .NET language you are not really 'compiling' it per se to native code, you are compiling it to an intermediate language called IL - very much like Java byte code. When your application or website is run for the first time the .NET runtime converts this code to native code on the local computer and then caches this binary and officially compiled native version of your code. The result is, the first time you run your app or a section of the code there is a small performance hit while the .NET runtime converts your code to native. Let me be perfectly clear, this is a one time thing - a first time thing. Once you have gotten past that every subsequent run is going to be as fast as other native code. (Why is it not as fast as something written in c or c++ you may ask - because there are other things the .net runtime is providing for you like garbage collection, but that is a whole other talk) So how is this different? This preview allows you to skip this JIT process and image caching process altogether. This is first targeted for Windows store apps, when you would first run it on your machine it was slow on first launch because all this extra work was being done. Microsoft decided they could take the server side resources they had and run this JIT and imaging process ahead of time and when someone downloads and installs your app - this work was already done and first launch would be faster - as much as 60% faster. There are also lots of changes under the hood to make this all work better - Andrew Pardoe is on this comment thread further down and mentioned things like a refactored runtime, static-optimized libraries, static marshalling all combining for performance wins. Does this mean I can build apps for Unix with C# No, Mono is still the best way to do that Can I build simple console apps with this and deploy to machines without the .NET runtime? No, right now this is only available for Windows Store apps. Besides, unless you have some Windows 98 machines sitting around nearly every PC has the .NET runtime. Will this make my app run faster? Starting up, yes. Normal operation, probably not. .NET runtime and jitter have been around a long time and they are impressively efficient and fast. This includes some tweaks to parts of the runtime but don't expect to see your text file processing app go from 10 seconds to 2 or something like that. Will this help me pick up chicks? Depends.
- deleted 13y ago
  [deleted]
Yuioup 13y ago
No mention anywhere of ASP.NET. Is this going to help ASP.NET in any way?
- detay 13y ago
  I asked the same question. Seems like they are just trying to get something out of the mobile so far.
BuckRogers 13y ago
So is this the mysterious 'M#' technology revealed?
- CmonDev 13y ago
  That's a language, this is a compiler tech.
  - BuckRogers 13y ago
    That's already known. If you knew anything about 'M#' you'd realize these two have to be related somehow. That's the question.
    - apardoe-MSFT 13y ago
      @BuckRogers, these two are related somehow. We've definitely benefitted from conversations with the M# people and they've likely benefitted from conversations with us. In fact, Joe Duffy once worked for our humble little .NET team :)
tsenkov 13y ago
Was someone from marketing writing this: "the performance of C++ with the productivity of C#" ... on startup. And not even on every startup, but only the first. And not even the first, since, as you know, there already are a lot of (unarguably, productive) features (such as GC etc.) making apps slower than C++ apps. Also, is it just me, but this sounds like a glorified NGen in the usual build process (compiling for production goes straight to native), instead of NGen in the background optimisation service? I am all about getting the new tools, switching to new, more productive ways of development (in fact I was programming in C# for about 3 years), I simply hate when false information is being spread, just because it sounds better to the sales person.
ksec 13y ago
There was GCJ that used to do this for Java. Sadly it has been discontinued. It is interesting how every old is new again, we went from AOT to JIT and Back to AOT again.
- pjmlp 13y ago
  > There was GCJ that used to do this for Java. Sadly it has been discontinued. There are lots of other AOT compilers for Java available. > It is interesting how every old is new again, we went from AOT to JIT and Back to AOT again. Yep, we already went through this as everyone founded out P-Code wasn't fast enough. Then Anders Hejlsberg created Turbo Pascal.
bananas 13y ago
This is great. I hope they make this available for web apps because we've got 45 second warmup time and CPU spamming due to the massive size of the work the JIT has to do when we deploy. Total pain. I imagine this would help them keep costs down on Azure as well.
- kennethh 13y ago
  It is possible to precompile web apps already today.
  - bananas 13y ago
    I'm talking these two steps, not page precompilation: 1. Proxy generation (castle) -> IL 2. IL -> Native.
- duncans 13y ago
  From my experience, much of an ASP.NET web app's start time is not so much the JIT-ing but before that, when the ASP.NET runtime compiles pages/views (aspx/cshtml etc) into *.cs then DLLs. Pre-compiling can mitigate this. Larger EF models can have quite an impact. Also if you use New Relic, it can seriously affect startup time too.
  - bananas 13y ago
    Yes and no. We ship our views as content as we have a custom UI front end that isn't razor or asp.net. The startup time for us is compiling NH proxies and the fact that our bin dir is huge: http://imgur.com/EyjR5WH http://imgur.com/EyjR5WH It takes forever for the JIT to actually compile all code paths in these assemblies. There's no PDBs in there either. Our domain and NH maps consume 42Mb of that to give you an idea.
detay 13y ago
Microsoft: "We could speed up your server-side code, but instead we did speed up the slow windows mobile apps that nobody cares about."
- simplyinfinity 13y ago
  here, educate yourself http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).aspx http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).a...
  - detay 13y ago
    thanks, but no thanks. I won't go ngen just to speed up my start-up time on my web applications. http://stackoverflow.com/questions/385841/does-it-help-to-use-ngen http://stackoverflow.com/questions/385841/does-it-help-to-us...
forgotAgain 13y ago
Its truly a great thing. A single file deployment would be a tremendous improvement. Also removing the ease with which distributed applications can be decompiled helps as well. Hopefully the marketing people let them spread it to all of their application types.
mamcx 13y ago
This could lead to a way to build a dynamic language on top of .NET and eventually be usable in iOS? I ask because: http://docs.xamarin.com/guides/ios/advanced_topics/limitations/ http://docs.xamarin.com/guides/ios/advanced_topics/limitatio... aka: No Dynamic Code Generation
rbanffy 13y ago
It's interesting. It's more like a "static JIT" (BIT?) that does not account for the different data characteristics the instructions will process (which is something a JIT would/should do because it alters the actual program flow), but I find the "fast from the start" idea very compelling. I wonder how long will it take to Oracle (or the OpenJDK folks) to react to it.

159 points by xyziemba 13y ago

I'm kind of scratching my head here, can someone explain what problem this solves? There's already a CLR and already a way to build native apps for Win 8, etc. This is a new CLR that can run new 'native' apps?

spo81rty 13y ago
CLR apps require just in time compiling which can take a little time to first run. So this should speed up opening the apps.
- tdicola 13y ago
  Sure, but ngen solved that problem years ago: http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).aspx http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).a...
  - itsboring 13y ago
    Yeah, and mono's AOT too. I wonder if this is really just ngen integration into VS and thus not really a big deal.
  - spo81rty 13y ago
    So I guess this is ngen in the cloud to skip doing it on the PC.
    - sriramk 13y ago
      If I remember ngen is very architecture/platform specific - that is why it has to be done on the target machine. This sounds like it is done ahead of time with support for a variety of architectures.
  - andyjohnson0 13y ago
    See https://news.ycombinator.com/item?id=7520687 https://news.ycombinator.com/item?id=7520687
- itsboring 13y ago
  It seems like this is basically just the same thing that Mono has done for a long time with AOT. I'm not really sure how it differs from the Ngen tool, though.
  - apardoe-MSFT 13y ago
    .NET Native addresses many of the same issues as Mono AOT but it has a radically different basis. We had the advantage of hindsight :) The biggest difference with NGen is the fact that .NET Native doesn't ever "fall back" to JIT compiled code. There are other differences--refactored runtime, static-optimized libraries, static marshalling, etc.--which can be seen by the perf wins over NGen. We're seeing 40% startup performance gain over NGen apps for top Windows Store apps.
    - rajeevk 13y ago
      @apardoe, one question: where will the compilation to machine instruction happen? From some comments in this thread, it seems that it will happen at app store server and not at developer's box. If that is the case then why will I need anything to do any settings in VS for building projects?
      - apardoe-MSFT 13y ago
        @rajeevk, we could compile from MSIL and not tell the developer. But you probably appreciate the chance to test out the app on your own the way your user will run it. After all, you'll want to profile it or maybe find that last on-device, optimized-only bug...
        thomasz 13y ago
        What about stuff like Il.Emit and Expression<T>.Compile
        apardoe-MSFT 13y ago
        Reflection.Emit isn't allowed in the Windows Store profile so we haven't handled it in this go-around. Expression compile is supported and handled properly.
plorkyeran 13y ago
It gives faster startup time (due to AOT compilation rather than JIT), and doesn't require that the .NET framework be installed. Possibly better runtime performance, but I wouldn't expect huge gains there. P/Invoke should have lower overhead, which may be highly relevant for some things. I suspect that there's things that require this which they haven't announced yet, since on its own it seems like something kinda nice but not beneficial enough to justify creating.
- tdicola 13y ago
  Yeah I don't understand the need to get rid of a .NET framework dependency though. This only supports building Windows store apps, which only run on devices that have the .NET framework right now...
  - itsboring 13y ago
    One admittedly crazy theory is that this is laying the groundwork for building iOS apps and therefore would compete with Xamarin. Any kind of JIT would not be allowed on the iOS app store.
    - deleted 13y ago
      [deleted]
    - tsenkov 13y ago
      The word is, that Microsoft is talking with Xamarin about a possible acquisition.
- ebiggs 13y ago
  Start up times could be a big deal to compete with iOS? Especially in similar app lifecycle models where apps could be stopped and restarted implicitly by the OS?
- Someone 13y ago
  "It [...] doesn't require that the .NET framework be installed." Are you sure? You still need the standard libraries, a garbage collector, its security checks when loading other code, and may want to use its compiler from your code. Together, that's a lot, maybe all, of what's in the framework.

DevKoala 13y ago

What is the difference between this and NGEN? Anybody?

bskap 13y ago
NGEN caches native code on the machine. You're still running from the CIL executable and you still need to have the framework installed, it just loads the machine code from the cache instead of JITing it. This appears to generate a native executable.
- DevKoala 13y ago
  Thank you.
pantaloons 13y ago
No MDIL. NGEN can still JIT for things like cross domain generics and because it loads non-native code, still needs to optimize at run time. Project N compiles to fully native code, so there can be no JIT, and significantly smarter optimizations can happen since they don't impact performance at runtime.
- DevKoala 13y ago
  Thank you.
- apardoe-MSFT 13y ago
  @Pantaloons: Right on all counts. One clarification: .NET Native and MDIL are orthogonal. MDIL was used in Triton to split NGen into conceptually two pieces: the optimized part (in the Windows Phone Store) and the part bound on the customer's device to the installed Framework. .NET Native produces completely native binaries. MDIL/Triton produces NGen binaries that still need a runtime and, occasionally, a JIT.
  - shanselman 13y ago
    And Triton is...

overgard 13y ago

Do native apps still require a preinstalled CLR?

plorkyeran 13y ago
No. Second entry in the FAQ (http://msdn.microsoft.com/en-US/vstudio/dn642499.aspx http://msdn.microsoft.com/en-US/vstudio/dn642499.aspx).
- overgard 13y ago
  Damn, that's awesome! For the longest time that was the only thing that really bothered me about writing .NET code.
  - chc 13y ago
    But doesn't anyone with the Windows Store already have the CLR?
    - overgard 13y ago
      Probably -- I don't care too much about the windows store, I'm more excited about being able to write C# code that doesn't require a VM. Not that there's anything /wrong/ with the CLR, but one thing I miss about C++ when I'm not writing it is self contained programs where it's just a small exe without a bunch of huge dependencies.
      - moron4hire 13y ago
        I think you're forgetting about the Visual C++ 20xx Redistributables. They aren't exactly tiny. https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture3.PNG https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture3.PNG vs. the latest .NET install https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture4.PNG https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture4.PNG This is a brand new Windows 8.1 computer.

modeless 13y ago

So, uh, can I compile my C# app to an bare x64 .exe file, statically linked with no runtime dependency on the .NET Framework, that will run on Windows 7 and 8? Or not? Edit: This is a much better link: http://msdn.microsoft.com/en-US/vstudio/dn642499.aspx http://msdn.microsoft.com/en-US/vstudio/dn642499.aspx Still not sure though, as they say "only Windows Store apps can be created" which sounds suspiciously like "no".

jimmcslim 13y ago
From the original link they say "Today's preview supports Windows Store applications. We will continue to evolve and improve native compilation for the range of .NET applications." which suggests to me that it might be on the radar. However the scope of Windows desktop or server applications is obviously much broader, so it might be a harder problem to solve there.
- apardoe-MSFT 13y ago
  @jimmcslim Quite right, the smaller Windows Store profile is a more scoped target. But everything is on the radar.
mgraczyk 13y ago
It sounds like that's the plan (from your link): "However, apps will get deployed on end-user devices as fully self-contained natively compiled code (when .NET Native enters production), and will not have a dependency on the .NET Framework on the target device/machine."
deleted 13y ago
[deleted]

api 13y ago

Only for Windows store? So who thinks walled gardens and feudalization are coming to all desktop OSes in the next 5 years? In the future, a store / certificate authority will be able to arbitrarily revoke your right to run anything on your computer that isn't approved.

apardoe-MSFT 13y ago
Today, Windows Store. Tomorrow, the world! :)
tonyedgecombe 13y ago
Compiled in the cloud as well: "Our compiler in the cloud compiles the app using .NET Native in the Store, creating a self-contained app package that’s customized to the device where the app will be installed."
ksk 13y ago
>In the future, a store / certificate authority will be able to arbitrarily revoke your right to run anything on your computer that isn't approved We're already there with Web Apps and other SaaS "innovative" technologies.

VexXtreme 13y ago

So is this going to work on Linux?

keithwarren 13y ago

It seems the comments area here is full of lots of questions and few answers. Let me try to clear some things up. Lets start with how it currently works... When you create an application or website in C#,F#,VB.NET or any other .NET language you are not really 'compiling' it per se to native code, you are compiling it to an intermediate language called IL - very much like Java byte code. When your application or website is run for the first time the .NET runtime converts this code to native code on the local computer and then caches this binary and officially compiled native version of your code. The result is, the first time you run your app or a section of the code there is a small performance hit while the .NET runtime converts your code to native. Let me be perfectly clear, this is a one time thing - a first time thing. Once you have gotten past that every subsequent run is going to be as fast as other native code. (Why is it not as fast as something written in c or c++ you may ask - because there are other things the .net runtime is providing for you like garbage collection, but that is a whole other talk) So how is this different? This preview allows you to skip this JIT process and image caching process altogether. This is first targeted for Windows store apps, when you would first run it on your machine it was slow on first launch because all this extra work was being done. Microsoft decided they could take the server side resources they had and run this JIT and imaging process ahead of time and when someone downloads and installs your app - this work was already done and first launch would be faster - as much as 60% faster. There are also lots of changes under the hood to make this all work better - Andrew Pardoe is on this comment thread further down and mentioned things like a refactored runtime, static-optimized libraries, static marshalling all combining for performance wins. Does this mean I can build apps for Unix with C# No, Mono is still the best way to do that Can I build simple console apps with this and deploy to machines without the .NET runtime? No, right now this is only available for Windows Store apps. Besides, unless you have some Windows 98 machines sitting around nearly every PC has the .NET runtime. Will this make my app run faster? Starting up, yes. Normal operation, probably not. .NET runtime and jitter have been around a long time and they are impressively efficient and fast. This includes some tweaks to parts of the runtime but don't expect to see your text file processing app go from 10 seconds to 2 or something like that. Will this help me pick up chicks? Depends.

deleted 13y ago
[deleted]

Yuioup 13y ago

No mention anywhere of ASP.NET. Is this going to help ASP.NET in any way?

detay 13y ago
I asked the same question. Seems like they are just trying to get something out of the mobile so far.

BuckRogers 13y ago

So is this the mysterious 'M#' technology revealed?

CmonDev 13y ago
That's a language, this is a compiler tech.
- BuckRogers 13y ago
  That's already known. If you knew anything about 'M#' you'd realize these two have to be related somehow. That's the question.
  - apardoe-MSFT 13y ago
    @BuckRogers, these two are related somehow. We've definitely benefitted from conversations with the M# people and they've likely benefitted from conversations with us. In fact, Joe Duffy once worked for our humble little .NET team :)

tsenkov 13y ago

Was someone from marketing writing this: "the performance of C++ with the productivity of C#" ... on startup. And not even on every startup, but only the first. And not even the first, since, as you know, there already are a lot of (unarguably, productive) features (such as GC etc.) making apps slower than C++ apps. Also, is it just me, but this sounds like a glorified NGen in the usual build process (compiling for production goes straight to native), instead of NGen in the background optimisation service? I am all about getting the new tools, switching to new, more productive ways of development (in fact I was programming in C# for about 3 years), I simply hate when false information is being spread, just because it sounds better to the sales person.

ksec 13y ago

There was GCJ that used to do this for Java. Sadly it has been discontinued. It is interesting how every old is new again, we went from AOT to JIT and Back to AOT again.

pjmlp 13y ago
> There was GCJ that used to do this for Java. Sadly it has been discontinued. There are lots of other AOT compilers for Java available. > It is interesting how every old is new again, we went from AOT to JIT and Back to AOT again. Yep, we already went through this as everyone founded out P-Code wasn't fast enough. Then Anders Hejlsberg created Turbo Pascal.

bananas 13y ago

This is great. I hope they make this available for web apps because we've got 45 second warmup time and CPU spamming due to the massive size of the work the JIT has to do when we deploy. Total pain. I imagine this would help them keep costs down on Azure as well.

kennethh 13y ago
It is possible to precompile web apps already today.
- bananas 13y ago
  I'm talking these two steps, not page precompilation: 1. Proxy generation (castle) -> IL 2. IL -> Native.
duncans 13y ago
From my experience, much of an ASP.NET web app's start time is not so much the JIT-ing but before that, when the ASP.NET runtime compiles pages/views (aspx/cshtml etc) into *.cs then DLLs. Pre-compiling can mitigate this. Larger EF models can have quite an impact. Also if you use New Relic, it can seriously affect startup time too.
- bananas 13y ago
  Yes and no. We ship our views as content as we have a custom UI front end that isn't razor or asp.net. The startup time for us is compiling NH proxies and the fact that our bin dir is huge: http://imgur.com/EyjR5WH http://imgur.com/EyjR5WH It takes forever for the JIT to actually compile all code paths in these assemblies. There's no PDBs in there either. Our domain and NH maps consume 42Mb of that to give you an idea.

detay 13y ago

Microsoft: "We could speed up your server-side code, but instead we did speed up the slow windows mobile apps that nobody cares about."

simplyinfinity 13y ago
here, educate yourself http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).aspx http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).a...
- detay 13y ago
  thanks, but no thanks. I won't go ngen just to speed up my start-up time on my web applications. http://stackoverflow.com/questions/385841/does-it-help-to-use-ngen http://stackoverflow.com/questions/385841/does-it-help-to-us...

forgotAgain 13y ago

Its truly a great thing. A single file deployment would be a tremendous improvement. Also removing the ease with which distributed applications can be decompiled helps as well. Hopefully the marketing people let them spread it to all of their application types.

mamcx 13y ago

This could lead to a way to build a dynamic language on top of .NET and eventually be usable in iOS? I ask because: http://docs.xamarin.com/guides/ios/advanced_topics/limitations/ http://docs.xamarin.com/guides/ios/advanced_topics/limitatio... aka: No Dynamic Code Generation

rbanffy 13y ago

It's interesting. It's more like a "static JIT" (BIT?) that does not account for the different data characteristics the instructions will process (which is something a JIT would/should do because it alters the actual program flow), but I find the "fast from the start" idea very compelling. I wonder how long will it take to Oracle (or the OpenJDK folks) to react to it.