Blog Post

.NET 4.5 - Multicore JIT

Play .NET 4.5 - Multicore JIT
Sign in to queue


Multicore JIT is a .NET 4.5 compiler technology that uses parallelization to reduce the JIT compilation time during application startup.

Multicore JIT team says:

"With Multicore JIT, methods are compiled on two cores in parallel. The more code you execute on your startup path, the more effective Multicore JIT will be at reducing startup time. Improvements of 20%-50% are very typical, which is great news to anyone developing medium to large .NET Framework applications that are not able to take advantage of NGen. You can improve the startup time of your application by up to 50% with very little work, even if it runs off of a USB stick."

Who better to explain this than .NET Performance Architect Vance Morrison and Multicore JIT program manager Dan Taylor? They are joined by software engineer Rick Brewster from the Windows team to discuss how this technology works and why it matters. Rick works on a large .NET Windows desktop application and Multicore JIT has clearly sped up his app's startup time. We'll get the inside scoop from both those who designed the technology and those who use it in production.



Download this episode

The Discussion

  • User profile image
    Florian Maetschke

    Wow! I would love to see this in Silverlight 6, too.

  • User profile image

    ..why the * we can't have full jit cache.. ;/

  • User profile image
  • User profile image

    Although this kind of improvments are certainly welcomed, what I really want is more optimized code gen, and I guess with MDIL the actual JIT has LESS work to do at app startup time, thats win-win.

  • User profile image

    I think they've got a slightly wrong/too damn conservative mindset here.  Sure jitting methods when their not needed may be a "waste" in terms of I want to flash deep fry this entire buffalo in 10 seconds flat. But I believe Jitting in chunks when they seem probable to be used is a far better way to go and cache the jitted methods for use later on, ambient CPU and RAM size is still growing...

    A good analogy to this is the CPU's themselves, not like the CPU grabs a single friggin bit of data out of memory, the CPU's pull the data as cache-lines and chunks at a time for faster speeds even tho the data in the memory isn't all being used. Of course it causes things like false sharing and memory location contention when it's not done right but still, hardware went to grabbing more data than is needed in one go, I think that Vance shouldn't be so picky on being 100% efficient as if it were kernel space or if this code was used for lunar launches & space exploration. If he wants, why don't they just put in heuristics or hints to the CPU's so that CPU's can also be 98% efficient using/hinting to the branch prediction engines built into current CPU's and do their tracing to help it along?

  • User profile image

    @Vance Morrison,

    Could you please give us some ideas on how the performance of multicore .Net JIT compares to Java JIT on multicore?



  • User profile image

    The implementation of the feature is pretty odd. I would've implemented it a bit differently. Some alternatives:

    1. Collect startup profiles automatically for each and every application.
    2. Run NGEN in the background when you launch a non-ngened app.

    I see the benefits of the API but if you did it this way every single app would benefit from the Multicore JIT. Now only a few apps will benefit since most developers will never learn about all this cool technology. At least you could've managed the profile directory automatically...

    In the video you talked about command line arguments. Most apps probably won't use command line arguments. And the developers caring about that scenario could still add calls to the current API.

    It'd be great if you could elaborate more why you implemented the way it is.

  • User profile image

    Dear Ivan, its because of lazy and uninovative people like you the managed code runs badly, you always rely on the machine power, rather then intelligence.

  • User profile image

    @ivan: I consider your comment offensive and not to the point. I didn't say "code runs badly". I just want to know the performance difference between Java and .Net JIT .


  • User profile image

    Now, now... Keep it civil. Please don't be disrespectful of others, ivan...

  • User profile image

    Dapfor .Net Grid is a high-performance component based on WinForms technology for performance-sensitive applications. Supported CLRs: 2.0, 3.0, 3.5, 4.0.Grids of different vendors have almost the same performance when working with static data, i.e. insertion, deletion and data sorting speed remain unchanged dapfor. com

Add Your 2 Cents