Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

.NET 4.5 - Multicore JIT

37 minutes, 30 seconds


Right click “Save as…”

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.


Follow the discussion

  • Oops, something didn't work.

    Getting subscription
    Subscribe to this conversation
  • Florian MaetschkeFlorian Maetschke

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

  • radiomanradioman

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

  • felix9felix9 the cat that walked by itself

    Rick Brewster's post:

  • felix9felix9 the cat that walked by itself

    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.

  • Eric AguiarHeavens​Revenge Know Thyself

    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?

  • ivan_ivan_ g

    @Vance Morrison,

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



  • 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.

  • ivanivan

    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.

  • ivan_ivan_ g

    @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 .


  • CharlesCharles Welcome Change

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

  • jagvirjagvir

    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

Remove this comment

Remove this thread


Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.