<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" media="screen" href="/styles/xslt/rss.xslt"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:media="http://search.yahoo.com/mrss/" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:c9="http://channel9.msdn.com">
<channel>
	<title>Comment Feed for Channel 9 - .NET 4.5 - Multicore JIT</title>
	<atom:link rel="self" type="application/rss+xml" href="http://channel9.msdn.com/posts/NET-45-Multicore-JIT/rss"></atom:link>
	<image>
		<url>http://media.ch9.ms/ch9/5271/82c45062-4406-4b89-852c-854c64b45271/MulticoreJITNET45_100.jpg</url>
		<title>Channel 9 - .NET 4.5 - Multicore JIT</title>
		<link></link>
	</image>
	<description>Multicore JIT is a .NET 4.5 compiler technology that&amp;nbsp;uses parallelization to reduce the JIT compilation time during application startup.Multicore JIT team says: &amp;quot;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.&amp;quot;Who better to explain this than .NET Performance Architect Vance Morrison and Multicore JIT program manager Dan&amp;nbsp;Taylor?&amp;nbsp;They are joined by&amp;nbsp;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&amp;nbsp;sped up his app&#39;s startup time.&amp;nbsp;We&#39;ll&amp;nbsp;get the inside scoop from both those who designed the technology and those who use it in production. </description>
	<link></link>
	<language>en</language>
	<pubDate>Fri, 24 May 2013 00:15:16 GMT</pubDate>
	<lastBuildDate>Fri, 24 May 2013 00:15:16 GMT</lastBuildDate>
	<generator>Rev9</generator>
	<item>
		<title>Re: .NET 4.5 - Multicore JIT</title>
		<description>
			<![CDATA[Wow&#33; I would love to see this in Silverlight 6, too.<p>posted by Florian Maetschke</p>]]>
		</description>
		<link>http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634861630599904145</link>
		<pubDate>Thu, 18 Oct 2012 13:17:39 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634861630599904145</guid>
		<dc:creator>Florian Maetschke</dc:creator>
	</item>
	<item>
		<title>Re: .NET 4.5 - Multicore JIT</title>
		<description>
			<![CDATA[..why the &#42; we can&#39;t have full jit cache.. &#59;&#47;<p>posted by radioman</p>]]>
		</description>
		<link>http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634861748976358783</link>
		<pubDate>Thu, 18 Oct 2012 16:34:57 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634861748976358783</guid>
		<dc:creator>radioman</dc:creator>
	</item>
	<item>
		<title>Re: .NET 4.5 - Multicore JIT</title>
		<description>
			<![CDATA[<p>Rick Brewster's post:<br><a href="http://blog.getpaint.net/2012/09/08/using-multi-core-jit-from-net-4-0-if-net-4-5-is-installed/">http&#58;&#47;&#47;blog.getpaint.net&#47;2012&#47;09&#47;08&#47;using-multi-core-jit-from-net-4-0-if-net-4-5-is-installed&#47;</a></p><p>posted by felix9</p>]]>
		</description>
		<link>http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634861750834970948</link>
		<pubDate>Thu, 18 Oct 2012 16:38:03 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634861750834970948</guid>
		<dc:creator>felix9</dc:creator>
	</item>
	<item>
		<title>Re: .NET 4.5 - Multicore JIT</title>
		<description>
			<![CDATA[<p>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.</p><p>posted by felix9</p>]]>
		</description>
		<link>http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634863182874145829</link>
		<pubDate>Sat, 20 Oct 2012 08:24:47 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634863182874145829</guid>
		<dc:creator>felix9</dc:creator>
	</item>
	<item>
		<title>Re: .NET 4.5 - Multicore JIT</title>
		<description>
			<![CDATA[<p>I think they've got a slightly wrong/too damn conservative mindset here. &nbsp;Sure jitting methods when their not needed may be a &quot;waste&quot; 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...</p><p>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&nbsp;cache-lines&nbsp;and chunks at a time for faster speeds even tho the data in the memory&nbsp;isn't&nbsp;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&nbsp;one&nbsp;go, I think that Vance shouldn't be so picky on being 100%&nbsp;efficient&nbsp;as if it were kernel space or if this code was used for lunar launches &amp; 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?</p><p>posted by HeavensRevenge</p>]]>
		</description>
		<link>http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634863504328968529</link>
		<pubDate>Sat, 20 Oct 2012 17:20:32 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634863504328968529</guid>
		<dc:creator>HeavensRevenge</dc:creator>
	</item>
	<item>
		<title>Re: .NET 4.5 - Multicore JIT</title>
		<description>
			<![CDATA[<p>@Vance Morrison,</p><p>Could you please give us some ideas on how the performance of multicore .Net JIT compares to Java JIT on multicore? </p><p>Thanks,</p><p>Ivan</p><p>posted by ivan_</p>]]>
		</description>
		<link>http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634864249211477675</link>
		<pubDate>Sun, 21 Oct 2012 14:02:01 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634864249211477675</guid>
		<dc:creator>ivan_</dc:creator>
	</item>
	<item>
		<title>Re: .NET 4.5 - Multicore JIT</title>
		<description>
			<![CDATA[<p>The implementation of the feature is pretty odd. I would've implemented it a bit differently. Some alternatives:</p><ol><li>Collect startup profiles automatically for each and every application. </li><li>Run NGEN in the background when you launch a non-ngened app. </li></ol><p>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...</p><p>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.</p><p>It'd be great if you could elaborate more why you implemented the way it is.</p><p>posted by deiruch</p>]]>
		</description>
		<link>http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634864651811913750</link>
		<pubDate>Mon, 22 Oct 2012 01:13:01 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634864651811913750</guid>
		<dc:creator>deiruch</dc:creator>
	</item>
	<item>
		<title>Re: .NET 4.5 - Multicore JIT</title>
		<description>
			<![CDATA[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.<p>posted by ivan</p>]]>
		</description>
		<link>http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634864938911409868</link>
		<pubDate>Mon, 22 Oct 2012 09:11:31 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634864938911409868</guid>
		<dc:creator>ivan</dc:creator>
	</item>
	<item>
		<title>Re: .NET 4.5 - Multicore JIT</title>
		<description>
			<![CDATA[<p>@<a href="/posts/NET-45-Multicore-JIT#c634864938911409868">ivan</a>: I consider your comment offensive and not to the point. I didn't say &quot;code runs badly&quot;. I just want to know the performance difference between Java and .Net JIT .</p><p>&nbsp;</p><p>posted by ivan_</p>]]>
		</description>
		<link>http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634865186216260883</link>
		<pubDate>Mon, 22 Oct 2012 16:03:41 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634865186216260883</guid>
		<dc:creator>ivan_</dc:creator>
	</item>
	<item>
		<title>Re: .NET 4.5 - Multicore JIT</title>
		<description>
			<![CDATA[<p>Now, now... Keep it civil. Please don't be disrespectful of others, ivan... <br>C</p><p>posted by Charles</p>]]>
		</description>
		<link>http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634865249908115629</link>
		<pubDate>Mon, 22 Oct 2012 17:49:50 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634865249908115629</guid>
		<dc:creator>Charles</dc:creator>
	</item>
	<item>
		<title>Re: .NET 4.5 - Multicore JIT</title>
		<description>
			<![CDATA[Dapfor .Net Grid is a high-performance component based on WinForms technology for performance-sensitive applications. Supported CLRs&#58; 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<p>posted by jagvir</p>]]>
		</description>
		<link>http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634871794763442367</link>
		<pubDate>Tue, 30 Oct 2012 07:37:56 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/posts/NET-45-Multicore-JIT#c634871794763442367</guid>
		<dc:creator>jagvir</dc:creator>
	</item>
</channel>
</rss>