.NET 4.5 - Multicore JIT

Description

Multicore JIT is a .NET 4.5 compiler technology thatuses 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.

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?

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

Collect startup profiles automatically for each and every application.

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.

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