<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: Concurrent idiocy</title>
	<atom:link href="http://bitpipe.wordpress.com/2008/01/14/concurrent-idiocy/feed/" rel="self" type="application/rss+xml" />
	<link>http://bitpipe.wordpress.com/2008/01/14/concurrent-idiocy/</link>
	<description>Whatever it is, I'm against it!</description>
	<pubDate>Thu, 28 Aug 2008 19:31:04 +0000</pubDate>
	<generator>http://wordpress.org/?v=MU</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Joachim</title>
		<link>http://bitpipe.wordpress.com/2008/01/14/concurrent-idiocy/#comment-152</link>
		<dc:creator>Joachim</dc:creator>
		<pubDate>Wed, 16 Jan 2008 10:34:23 +0000</pubDate>
		<guid isPermaLink="false">http://bitpipe.wordpress.com/2008/01/14/concurrent-idiocy/#comment-152</guid>
		<description>Aloha!

Also, the basic idea with multiple cores in desktop machines are not to get massive single thread speed, but having multiple threads - or more precisely - more programs running fast at the same time.

If you only run one program you don't get any benefit (unless the app is multithreaded and not I/O or memory bound), but the OS and other apps can be much snappier anyway.

The big reason for multicore is that it's basically the last way to get good use for the transistors we get with new process nodes. When on-chip caches are usint 90% of the die and any further IPC increases are diminished by the exponential complexity required to get another 10% more performance, instantiating more cores are the way to go.

But the SW side sucks. Big time.</description>
		<content:encoded><![CDATA[<p>Aloha!</p>
<p>Also, the basic idea with multiple cores in desktop machines are not to get massive single thread speed, but having multiple threads - or more precisely - more programs running fast at the same time.</p>
<p>If you only run one program you don&#8217;t get any benefit (unless the app is multithreaded and not I/O or memory bound), but the OS and other apps can be much snappier anyway.</p>
<p>The big reason for multicore is that it&#8217;s basically the last way to get good use for the transistors we get with new process nodes. When on-chip caches are usint 90% of the die and any further IPC increases are diminished by the exponential complexity required to get another 10% more performance, instantiating more cores are the way to go.</p>
<p>But the SW side sucks. Big time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mats Henricson</title>
		<link>http://bitpipe.wordpress.com/2008/01/14/concurrent-idiocy/#comment-149</link>
		<dc:creator>Mats Henricson</dc:creator>
		<pubDate>Tue, 15 Jan 2008 18:38:14 +0000</pubDate>
		<guid isPermaLink="false">http://bitpipe.wordpress.com/2008/01/14/concurrent-idiocy/#comment-149</guid>
		<description>You may be right, but you look at it from the wrong perspective. It is a fact that we're going to be drowning in cores. It is also a fact that concurrent programming is too hard unless you're an expert. This is where Scala and other possible languages comes in. It is simply the only solution if we want to use the dozens of cores we're facing in the future.</description>
		<content:encoded><![CDATA[<p>You may be right, but you look at it from the wrong perspective. It is a fact that we&#8217;re going to be drowning in cores. It is also a fact that concurrent programming is too hard unless you&#8217;re an expert. This is where Scala and other possible languages comes in. It is simply the only solution if we want to use the dozens of cores we&#8217;re facing in the future.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
