<?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: The Multicore Challenge</title>
	<atom:link href="http://www.cccblog.org/2008/08/26/the-multicore-challenge/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.cccblog.org/2008/08/26/the-multicore-challenge/</link>
	<description>The Computing Community Consortium</description>
	<lastBuildDate>Tue, 02 Mar 2010 18:21:20 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Stuff &#187; Blog Archive &#187; The computing revolution no one knows about</title>
		<link>http://www.cccblog.org/2008/08/26/the-multicore-challenge/comment-page-1/#comment-918</link>
		<dc:creator>Stuff &#187; Blog Archive &#187; The computing revolution no one knows about</dc:creator>
		<pubDate>Fri, 24 Jul 2009 16:30:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.cccblog.org/?p=20#comment-918</guid>
		<description>[...] http://www.cccblog.org/2008/08/26/the-multicore-challenge/ [...]</description>
		<content:encoded><![CDATA[<p>[...] <a href="http://www.cccblog.org/2008/08/26/the-multicore-challenge/" rel="nofollow">http://www.cccblog.org/2008/08/26/the-multicore-challenge/</a> [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Colin Warwick</title>
		<link>http://www.cccblog.org/2008/08/26/the-multicore-challenge/comment-page-1/#comment-212</link>
		<dc:creator>Colin Warwick</dc:creator>
		<pubDate>Thu, 30 Oct 2008 21:13:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.cccblog.org/?p=20#comment-212</guid>
		<description>I think the key think is cost per compute power, and volume drives cost down. The one place parallism has really won is in graphics for gamer, a high volume application that demands a low price point. (The customer is millions of teenagers, not one or two DARPA folks). All sorts of non-graphics apps are now jumping on GPU bandwagon.</description>
		<content:encoded><![CDATA[<p>I think the key think is cost per compute power, and volume drives cost down. The one place parallism has really won is in graphics for gamer, a high volume application that demands a low price point. (The customer is millions of teenagers, not one or two DARPA folks). All sorts of non-graphics apps are now jumping on GPU bandwagon.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Computing Community Consortium</title>
		<link>http://www.cccblog.org/2008/08/26/the-multicore-challenge/comment-page-1/#comment-153</link>
		<dc:creator>Computing Community Consortium</dc:creator>
		<pubDate>Tue, 23 Sep 2008 18:28:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.cccblog.org/?p=20#comment-153</guid>
		<description>[...] The Multicore Challenge  [...]</description>
		<content:encoded><![CDATA[<p>[...] The Multicore Challenge  [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Philip Machanick</title>
		<link>http://www.cccblog.org/2008/08/26/the-multicore-challenge/comment-page-1/#comment-130</link>
		<dc:creator>Philip Machanick</dc:creator>
		<pubDate>Thu, 04 Sep 2008 09:29:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.cccblog.org/?p=20#comment-130</guid>
		<description>Wolf, what you are describing sounds like multitasking. Within limits, that is one of the better uses of multicore systems but the operating system can become a bottleneck.</description>
		<content:encoded><![CDATA[<p>Wolf, what you are describing sounds like multitasking. Within limits, that is one of the better uses of multicore systems but the operating system can become a bottleneck.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Wolf Halton</title>
		<link>http://www.cccblog.org/2008/08/26/the-multicore-challenge/comment-page-1/#comment-127</link>
		<dc:creator>Wolf Halton</dc:creator>
		<pubDate>Sat, 30 Aug 2008 19:11:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.cccblog.org/?p=20#comment-127</guid>
		<description>Would it be easier, do you think, to program applications to specifically address a specific core, so several processes that may not be connected, could really use the multicore throughput potential? Timeslice in two dimensions?</description>
		<content:encoded><![CDATA[<p>Would it be easier, do you think, to program applications to specifically address a specific core, so several processes that may not be connected, could really use the multicore throughput potential? Timeslice in two dimensions?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: marvin</title>
		<link>http://www.cccblog.org/2008/08/26/the-multicore-challenge/comment-page-1/#comment-126</link>
		<dc:creator>marvin</dc:creator>
		<pubDate>Fri, 29 Aug 2008 08:08:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.cccblog.org/?p=20#comment-126</guid>
		<description>Another thing to note is that many of the approaches that address the multicore problem are applicable to the related problem of grid computing.  The benefit of a shift in how applications are developed could be twofold, both allowing actual USE of multicore chips AND (locally or globally) distributed computers.</description>
		<content:encoded><![CDATA[<p>Another thing to note is that many of the approaches that address the multicore problem are applicable to the related problem of grid computing.  The benefit of a shift in how applications are developed could be twofold, both allowing actual USE of multicore chips AND (locally or globally) distributed computers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: JamesF</title>
		<link>http://www.cccblog.org/2008/08/26/the-multicore-challenge/comment-page-1/#comment-125</link>
		<dc:creator>JamesF</dc:creator>
		<pubDate>Thu, 28 Aug 2008 21:24:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.cccblog.org/?p=20#comment-125</guid>
		<description>&quot;Rather, even our rosiest forecasts are that a dozen or two Great Ideas will work together and/or apply in different domains to make a real difference.&quot;

I definitely agree with Dan on this one.  Here at Pervasive we are adding our egg to the dozen, DataRush.  A flow based or actor oriented java solution which works really well with problems that focus on large amounts of data manipulation.
JamesF
PervasiveDataRush</description>
		<content:encoded><![CDATA[<p>&#8220;Rather, even our rosiest forecasts are that a dozen or two Great Ideas will work together and/or apply in different domains to make a real difference.&#8221;</p>
<p>I definitely agree with Dan on this one.  Here at Pervasive we are adding our egg to the dozen, DataRush.  A flow based or actor oriented java solution which works really well with problems that focus on large amounts of data manipulation.<br />
JamesF<br />
PervasiveDataRush</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Philip Machanick</title>
		<link>http://www.cccblog.org/2008/08/26/the-multicore-challenge/comment-page-1/#comment-124</link>
		<dc:creator>Philip Machanick</dc:creator>
		<pubDate>Thu, 28 Aug 2008 07:15:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.cccblog.org/?p=20#comment-124</guid>
		<description>It&#039;s my experience that every decade or so, a packaging breakthrough allows some previously forgotten or abandoned approach to be resurrected at a lower price point, and all the previous lessons are forgotten.

Here are a few of those lessons:
1. parallel programming is inherently hard, and tools and techniques claiming to avoid the problems never work as advertised
2. heterogeneous and asymmetric architectures are much harder to program effectively than homogeneous symmetric architectures
3. Programmer-managed memory is much harder to use than system-managed (whether OS or hardware)
4. Specialist instruction sets are much harder to use effectively than general-purpose ones

I nearly fell out of my chair laughing when the Cell was launched. It contained all 4 of these errors in one design. Despite the commercial advantages in bringing out a game that fully exploited its features, as I recall, only 1 game available when the Playstation 3 was launched came close.

I hereby announce Machanick&#039;s corollory to Moore&#039;s Law: any rate of improvement in the number of transistors you can buy for your money will be matched by erroneous expectations that programmers will become smarter.

Unfortunately there is no Moore&#039;s Law for IQ.

The only real practical advantage of multicore over discrete chip multiprocessors (aside from the packaging and cost advantages) is a significant reduction of interprocess communication costs -- provided IPC is core-to-core, i.e., if you communicate through shared memory, you&#039;d better make sure that the data is cached before the communication occurs. That makes the programming problem harder, not easier (see Lesson 3 above).

Good luck with transactional memories and all the other cool new ideas. Ask yourself one question: do they make parallel programming easier, or do they add one more wrinkle for programmers to take care of -- that may be different in the next generation or on a rival design?

Putting huge numbers of cores on-chip is a losing game. The more you add, the smaller the fraction of the problem space you are addressing, and the harder you make programming. I would much rather up the size of on-chip caches to the extent that they effectively become the main memory, with off-chip accesses becoming page faults. Whether you go multicore or aggressive uniprocessor, off-chip memory is a major bottleneck.

As Seymour Cray taught us, the thing to aim for is not peak throughput, but average throughput. 100 cores each running at 1% of its full speed because or programming inefficiencies, inherent nonparallelism of the workload and bottlenecks in the memory system is hardly an advance on 2 to 4 cores each running at at least 50% of its full speed.

In any case all of this misses the real excitement in the computing world: turn Moore&#039;s Law on its head, and contemplate when something that cost $1,000,000 will cost $1. That&#039;s the point where you can do something really exciting on a small, almost free device.</description>
		<content:encoded><![CDATA[<p>It&#8217;s my experience that every decade or so, a packaging breakthrough allows some previously forgotten or abandoned approach to be resurrected at a lower price point, and all the previous lessons are forgotten.</p>
<p>Here are a few of those lessons:<br />
1. parallel programming is inherently hard, and tools and techniques claiming to avoid the problems never work as advertised<br />
2. heterogeneous and asymmetric architectures are much harder to program effectively than homogeneous symmetric architectures<br />
3. Programmer-managed memory is much harder to use than system-managed (whether OS or hardware)<br />
4. Specialist instruction sets are much harder to use effectively than general-purpose ones</p>
<p>I nearly fell out of my chair laughing when the Cell was launched. It contained all 4 of these errors in one design. Despite the commercial advantages in bringing out a game that fully exploited its features, as I recall, only 1 game available when the Playstation 3 was launched came close.</p>
<p>I hereby announce Machanick&#8217;s corollory to Moore&#8217;s Law: any rate of improvement in the number of transistors you can buy for your money will be matched by erroneous expectations that programmers will become smarter.</p>
<p>Unfortunately there is no Moore&#8217;s Law for IQ.</p>
<p>The only real practical advantage of multicore over discrete chip multiprocessors (aside from the packaging and cost advantages) is a significant reduction of interprocess communication costs &#8212; provided IPC is core-to-core, i.e., if you communicate through shared memory, you&#8217;d better make sure that the data is cached before the communication occurs. That makes the programming problem harder, not easier (see Lesson 3 above).</p>
<p>Good luck with transactional memories and all the other cool new ideas. Ask yourself one question: do they make parallel programming easier, or do they add one more wrinkle for programmers to take care of &#8212; that may be different in the next generation or on a rival design?</p>
<p>Putting huge numbers of cores on-chip is a losing game. The more you add, the smaller the fraction of the problem space you are addressing, and the harder you make programming. I would much rather up the size of on-chip caches to the extent that they effectively become the main memory, with off-chip accesses becoming page faults. Whether you go multicore or aggressive uniprocessor, off-chip memory is a major bottleneck.</p>
<p>As Seymour Cray taught us, the thing to aim for is not peak throughput, but average throughput. 100 cores each running at 1% of its full speed because or programming inefficiencies, inherent nonparallelism of the workload and bottlenecks in the memory system is hardly an advance on 2 to 4 cores each running at at least 50% of its full speed.</p>
<p>In any case all of this misses the real excitement in the computing world: turn Moore&#8217;s Law on its head, and contemplate when something that cost $1,000,000 will cost $1. That&#8217;s the point where you can do something really exciting on a small, almost free device.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Patterson Calls for a Manhattan Project in Parallel Computing &#124; CSDiary</title>
		<link>http://www.cccblog.org/2008/08/26/the-multicore-challenge/comment-page-1/#comment-123</link>
		<dc:creator>Patterson Calls for a Manhattan Project in Parallel Computing &#124; CSDiary</dc:creator>
		<pubDate>Wed, 27 Aug 2008 16:12:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.cccblog.org/?p=20#comment-123</guid>
		<description>[...] weblog of the Computing Community Consortium has an opinion piece by Berkeley&#8217;s Dave Patterson, on the need for a major, government-sponsored attack on the so-called multicore challenge. You can [...]</description>
		<content:encoded><![CDATA[<p>[...] weblog of the Computing Community Consortium has an opinion piece by Berkeley&#8217;s Dave Patterson, on the need for a major, government-sponsored attack on the so-called multicore challenge. You can [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Patterson on the multicore challenge &#124; insideHPC</title>
		<link>http://www.cccblog.org/2008/08/26/the-multicore-challenge/comment-page-1/#comment-122</link>
		<dc:creator>Patterson on the multicore challenge &#124; insideHPC</dc:creator>
		<pubDate>Wed, 27 Aug 2008 14:05:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.cccblog.org/?p=20#comment-122</guid>
		<description>[...] You can read it here. [...]</description>
		<content:encoded><![CDATA[<p>[...] You can read it here. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jerry Callen</title>
		<link>http://www.cccblog.org/2008/08/26/the-multicore-challenge/comment-page-1/#comment-121</link>
		<dc:creator>Jerry Callen</dc:creator>
		<pubDate>Wed, 27 Aug 2008 13:21:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.cccblog.org/?p=20#comment-121</guid>
		<description>I&#039;m a former employee of several members of the Dead Parallel Computing Society. I don&#039;t believe we died from lack of programming tools; rather, Moore&#039;s Law rendered the performance improvements too ephemeral. As I type I&#039;m looking at a CM-5 sandwich board; its performance was matched by a standard PC just 5 or 6 years after this board was SOTA - for WAY less money. 

Now we&#039;re at a point where sequential processors can&#039;t easily be made faster - really! - so parallelism actually, honestly matters. Many, many commercially interesting problems can be solved by data parallelism, and we have a growing set of data parallel tools available commercially. I&#039;m still toiling away in the fields of commercial parallel processing, and I don&#039;t see the need for any massive government investment here.</description>
		<content:encoded><![CDATA[<p>I&#8217;m a former employee of several members of the Dead Parallel Computing Society. I don&#8217;t believe we died from lack of programming tools; rather, Moore&#8217;s Law rendered the performance improvements too ephemeral. As I type I&#8217;m looking at a CM-5 sandwich board; its performance was matched by a standard PC just 5 or 6 years after this board was SOTA &#8211; for WAY less money. </p>
<p>Now we&#8217;re at a point where sequential processors can&#8217;t easily be made faster &#8211; really! &#8211; so parallelism actually, honestly matters. Many, many commercially interesting problems can be solved by data parallelism, and we have a growing set of data parallel tools available commercially. I&#8217;m still toiling away in the fields of commercial parallel processing, and I don&#8217;t see the need for any massive government investment here.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: The Multicore Challenge: Thoughts of David Patterson</title>
		<link>http://www.cccblog.org/2008/08/26/the-multicore-challenge/comment-page-1/#comment-120</link>
		<dc:creator>The Multicore Challenge: Thoughts of David Patterson</dc:creator>
		<pubDate>Wed, 27 Aug 2008 12:08:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.cccblog.org/?p=20#comment-120</guid>
		<description>[...] Full Story [...]</description>
		<content:encoded><![CDATA[<p>[...] Full Story [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alwyn Goodloe</title>
		<link>http://www.cccblog.org/2008/08/26/the-multicore-challenge/comment-page-1/#comment-119</link>
		<dc:creator>Alwyn Goodloe</dc:creator>
		<pubDate>Wed, 27 Aug 2008 00:23:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.cccblog.org/?p=20#comment-119</guid>
		<description>I too remember those cool computers of lore.
Heck I&#039;ve even programmed a few of them back in the day. Hypercubes sure were cool
as was the programming language OCCAM.
Unfortunately, almost no one was 
willing to write code for the new
machines.  I think Hennessy&#039;s statement about  &quot;ease of use&quot; is really key in the effort. I worked for fourteen years in the IT industry and most CIOs will probably say that recompiling the ole dusty deck is as 
much as they are willing to do. We probably need to say exactly what we mean by ease of use.


I&#039;m going to say that I cringe every time
I hear an academic arguing for a new
Manhattan project for his particular area. 
Suppose DARPA or some other DOD agency  did do a   Manhattan Project. First lets make one thing clear. It was a TOP SECRET project. No clearances no work. Working on the Manhattan project was an interruption of one&#039;s academic career to support the war. I believe it was Wheeler who  received a letter by his brother serving in the European theater of operations saying &quot;Hurry UP&quot;. His brother would be killed a few days latter. Had the War Dept not viewed the effort as supporting combat operations they wouldn&#039;t have gotten the resources to do it. Today, a huge effort directing a large part of the scientific community to say detecting IEDs would be a better analogy and it too would be top secret. So folks, lets put that one to rest for good and pick a better analogy.</description>
		<content:encoded><![CDATA[<p>I too remember those cool computers of lore.<br />
Heck I&#8217;ve even programmed a few of them back in the day. Hypercubes sure were cool<br />
as was the programming language OCCAM.<br />
Unfortunately, almost no one was<br />
willing to write code for the new<br />
machines.  I think Hennessy&#8217;s statement about  &#8220;ease of use&#8221; is really key in the effort. I worked for fourteen years in the IT industry and most CIOs will probably say that recompiling the ole dusty deck is as<br />
much as they are willing to do. We probably need to say exactly what we mean by ease of use.</p>
<p>I&#8217;m going to say that I cringe every time<br />
I hear an academic arguing for a new<br />
Manhattan project for his particular area.<br />
Suppose DARPA or some other DOD agency  did do a   Manhattan Project. First lets make one thing clear. It was a TOP SECRET project. No clearances no work. Working on the Manhattan project was an interruption of one&#8217;s academic career to support the war. I believe it was Wheeler who  received a letter by his brother serving in the European theater of operations saying &#8220;Hurry UP&#8221;. His brother would be killed a few days latter. Had the War Dept not viewed the effort as supporting combat operations they wouldn&#8217;t have gotten the resources to do it. Today, a huge effort directing a large part of the scientific community to say detecting IEDs would be a better analogy and it too would be top secret. So folks, lets put that one to rest for good and pick a better analogy.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Grossman</title>
		<link>http://www.cccblog.org/2008/08/26/the-multicore-challenge/comment-page-1/#comment-118</link>
		<dc:creator>Dan Grossman</dc:creator>
		<pubDate>Tue, 26 Aug 2008 15:58:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.cccblog.org/?p=20#comment-118</guid>
		<description>I agree with all David&#039;s points and would add this complementary one: To my knowledge, none of the researchers addressing the parallel-computing software challenge believe there is going to be one single savior technology that we&#039;ve simply been overlooking.  Rather, even our rosiest forecasts are that a dozen or two Great Ideas will work together and/or apply in different domains to make a real difference.  That makes it even more important that we have the funding to support research in a variety of subfields, time horizons, geographic regions, etc.</description>
		<content:encoded><![CDATA[<p>I agree with all David&#8217;s points and would add this complementary one: To my knowledge, none of the researchers addressing the parallel-computing software challenge believe there is going to be one single savior technology that we&#8217;ve simply been overlooking.  Rather, even our rosiest forecasts are that a dozen or two Great Ideas will work together and/or apply in different domains to make a real difference.  That makes it even more important that we have the funding to support research in a variety of subfields, time horizons, geographic regions, etc.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
