<?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 Total Cost of Parallelization</title>
	<atom:link href="http://www.linux-mag.com/id/5802/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.linux-mag.com/id/5802/</link>
	<description>Open Source, Open Standards</description>
	<lastBuildDate>Sat, 05 Oct 2013 13:48:18 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1</generator>
	<item>
		<title>By: eavedrop44</title>
		<link>http://www.linux-mag.com/id/5802/#comment-625205</link>
		<dc:creator>eavedrop44</dc:creator>
		<pubDate>Wed, 05 Dec 2012 13:36:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.linux-mag.com/id/5802/#comment-625205</guid>
		<description>I wonder, is this is a function of the audience that Cuban reaches with his blog or if open source startup and quick profitability just don’t go hand-in-hand? &lt;a href=&quot;http://www.multisportred.com&quot; rel=&quot;nofollow&quot;&gt;multisportred&lt;/a&gt;
&lt;a href=&quot;http://www.soulnsportventures.com&quot; rel=&quot;nofollow&quot;&gt;soulnsportventures&lt;/a&gt;
&lt;a href=&quot;http://www.sportahead.com&quot; rel=&quot;nofollow&quot;&gt;sportahead&lt;/a&gt;</description>
		<content:encoded><![CDATA[<p>I wonder, is this is a function of the audience that Cuban reaches with his blog or if open source startup and quick profitability just don’t go hand-in-hand? <a href="http://www.multisportred.com" rel="nofollow">multisportred</a><br />
<a href="http://www.soulnsportventures.com" rel="nofollow">soulnsportventures</a><br />
<a href="http://www.sportahead.com" rel="nofollow">sportahead</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ekerim</title>
		<link>http://www.linux-mag.com/id/5802/#comment-5294</link>
		<dc:creator>ekerim</dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.linux-mag.com/id/5802/#comment-5294</guid>
		<description>Congratulations! Within the constraints of the example you have now managed to pay approx $8.000 for an 8-core N Ghz machine that barely beats a $1.000 1 CPU N Ghz machine performing this one task. How&#039;s that for TCOP ?&lt;br /&gt;
&lt;br /&gt;
Your example has no base in reality and your reasoning/conclusions are flawed.&lt;br /&gt;
&lt;br /&gt;
You can not talk about scalability and use an example that assumes that only one task will ever be performed at the same time. In a real world scenario, the C app would run eight separate instances each bound to a sparate core and calculating using an efficiency loss off 20% for each core compared to an eight CPU system (or eight single CPU systems) it would complete 40 tasks in the same time it takes your hypothetical SL app to complete 8 tasks (one for each core). Yes, that&#039;s right, the speed factor is still 5 to 1 in favor of the C app.&lt;br /&gt;
&lt;br /&gt;
Off course the example is overly simplified, when programming in parallell there are other bottle necks but those are irrelevant to the example.&lt;br /&gt;
&lt;br /&gt;
Using statistically non-significant tests, I found that a single threaded app which uses 100% CPU on a single core and who&#039;s only possible bottle necks are memory access and the system bus, scales with an efficiency of ~99% on an 8 core machine.&lt;br /&gt;
&lt;br /&gt;
I totaly agree that something needs to be done to ease the task of programming in parallell, but the reasons has nothing to do with the efficiency of the programs code as you try to make it out to be.&lt;br /&gt;
&lt;br /&gt;
The real problem is the maintainability of the required complex code and the time to debug threading errors. This complexity and time must in real life be compared to the availability of programmers with expertice in C/C++/C# (pick your poison) contra the availability of programmers with expertice in hypothetical SL, an unproven language until it has been around for a couple of years. Hardly enough to try to coin a new expression over is it ?</description>
		<content:encoded><![CDATA[<p>Congratulations! Within the constraints of the example you have now managed to pay approx $8.000 for an 8-core N Ghz machine that barely beats a $1.000 1 CPU N Ghz machine performing this one task. How&#8217;s that for TCOP ?</p>
<p>Your example has no base in reality and your reasoning/conclusions are flawed.</p>
<p>You can not talk about scalability and use an example that assumes that only one task will ever be performed at the same time. In a real world scenario, the C app would run eight separate instances each bound to a sparate core and calculating using an efficiency loss off 20% for each core compared to an eight CPU system (or eight single CPU systems) it would complete 40 tasks in the same time it takes your hypothetical SL app to complete 8 tasks (one for each core). Yes, that&#8217;s right, the speed factor is still 5 to 1 in favor of the C app.</p>
<p>Off course the example is overly simplified, when programming in parallell there are other bottle necks but those are irrelevant to the example.</p>
<p>Using statistically non-significant tests, I found that a single threaded app which uses 100% CPU on a single core and who&#8217;s only possible bottle necks are memory access and the system bus, scales with an efficiency of ~99% on an 8 core machine.</p>
<p>I totaly agree that something needs to be done to ease the task of programming in parallell, but the reasons has nothing to do with the efficiency of the programs code as you try to make it out to be.</p>
<p>The real problem is the maintainability of the required complex code and the time to debug threading errors. This complexity and time must in real life be compared to the availability of programmers with expertice in C/C++/C# (pick your poison) contra the availability of programmers with expertice in hypothetical SL, an unproven language until it has been around for a couple of years. Hardly enough to try to coin a new expression over is it ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: spacemonkey</title>
		<link>http://www.linux-mag.com/id/5802/#comment-5295</link>
		<dc:creator>spacemonkey</dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.linux-mag.com/id/5802/#comment-5295</guid>
		<description>re: &quot;What gets more expensive every year? Right, people. ..&quot;&lt;br /&gt;
&lt;br /&gt;
I&#039;m not sure this premise is quite right. Companies are always looking at ways to cut the cost of people and off-shoring can significantly reduce the expense and generally produce the same results. One could argue that off-shoring is getting more expensive every year, but there&#039;s still a large (5-10x) differential in people costs between on-shore and off-shore. And there are always new cheaper off-shoring destinations to be &#039;discovered&#039; awaiting their turn to join the race.</description>
		<content:encoded><![CDATA[<p>re: &#8220;What gets more expensive every year? Right, people. ..&#8221;</p>
<p>I&#8217;m not sure this premise is quite right. Companies are always looking at ways to cut the cost of people and off-shoring can significantly reduce the expense and generally produce the same results. One could argue that off-shoring is getting more expensive every year, but there&#8217;s still a large (5-10x) differential in people costs between on-shore and off-shore. And there are always new cheaper off-shoring destinations to be &#8216;discovered&#8217; awaiting their turn to join the race.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tphillips</title>
		<link>http://www.linux-mag.com/id/5802/#comment-5296</link>
		<dc:creator>tphillips</dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.linux-mag.com/id/5802/#comment-5296</guid>
		<description>To spacemonkey:&lt;br /&gt;
&lt;br /&gt;
Same results with offshore developers?&lt;br /&gt;
&lt;br /&gt;
You must be a bean-counter.  Certainly you haven&#039;t been on the same projects I have.&lt;br /&gt;
&lt;br /&gt;
Always new, cheaper off-shoring destinations?&lt;br /&gt;
&lt;br /&gt;
Not unless the planet is expanding.  Even if, eventually, every nation on Earth develops the infrastructure for off-shoring, that&#039;s still a limited pool.</description>
		<content:encoded><![CDATA[<p>To spacemonkey:</p>
<p>Same results with offshore developers?</p>
<p>You must be a bean-counter.  Certainly you haven&#8217;t been on the same projects I have.</p>
<p>Always new, cheaper off-shoring destinations?</p>
<p>Not unless the planet is expanding.  Even if, eventually, every nation on Earth develops the infrastructure for off-shoring, that&#8217;s still a limited pool.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: spacemonkey</title>
		<link>http://www.linux-mag.com/id/5802/#comment-5297</link>
		<dc:creator>spacemonkey</dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.linux-mag.com/id/5802/#comment-5297</guid>
		<description>Hi tphillips,&lt;br /&gt;
just playing devil&#039;s advocate here, but off-shoring is a reality. re: &quot;Limited pool&quot; ? With developing nations coming &#039;on-line&#039; the pool is getting bigger all the time...</description>
		<content:encoded><![CDATA[<p>Hi tphillips,<br />
just playing devil&#8217;s advocate here, but off-shoring is a reality. re: &#8220;Limited pool&#8221; ? With developing nations coming &#8216;on-line&#8217; the pool is getting bigger all the time&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>