<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.11" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Processor Bifurcation</title>
	<link>http://www.linux-mag.com/id/6552/</link>
	<description>Open Source, Open Standards</description>
	<pubDate>Sun, 05 Jul 2009 01:59:21 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.11</generator>

	<item>
		<title>by: krishisthere</title>
		<link>http://www.linux-mag.com/id/6552/#comment-1352</link>
		<pubDate>Thu, 31 Jul 2008 10:31:39 +0000</pubDate>
		<guid>http://www.linux-mag.com/id/6552/#comment-1352</guid>
					<description>While considering High Performance Computing, there are a few factors that need consideration:

1.) Whether the application/software is freshly designed, keeping in mind the hardware/processor that it is going to run on, or whether it is a port of a legacy code or an enhancement of an existing code. Considering on how the software industry has evolved; and the amount of money poured in to the maintenance of an existing software product, it is not very likely that software giants will be very keen to re-develop. The emphasis is mostly on re-using the existing code and getting them to work on new platforms. The fact is that most of this code is nonconformist to the new multi-core processor (and are not thread aware) and is not able to exploit multiple processors either. Most of these codes will are light weight and do not need the performance of a multi-core system.

2.) Self modifying code will play an important role in the future of "intelligent" products and predictive computing, and they are still a handful to manage on single core processors. The introduction of multiple cores will further complicate the working of such code.

3.) The introduction of multiple cores (and multiple processors) on a server also introduces the problem of synchronizing different execution flows on different processors/cores, and the possibility of deadlocks. Greater the number of processors/cores, greater will be the time wasted by the individual processor for synchronization. Thus it is not necessary that the increase in the number of processors/cores will translate to increase in performance. Remember the old adage: "Too many cooks spoil the broth".

The need is to be able to segregate the utility of the server/computer. Gaming needs multiple cores and will have to take a separate path, but servers running normal applications can still work with a single core. The cost of maintaining a complex application is huge, and it is unlikely that the end user will be keen to bear it.</description>
		<content:encoded><![CDATA[<p>While considering High Performance Computing, there are a few factors that need consideration:</p>
<p>1.) Whether the application/software is freshly designed, keeping in mind the hardware/processor that it is going to run on, or whether it is a port of a legacy code or an enhancement of an existing code. Considering on how the software industry has evolved; and the amount of money poured in to the maintenance of an existing software product, it is not very likely that software giants will be very keen to re-develop. The emphasis is mostly on re-using the existing code and getting them to work on new platforms. The fact is that most of this code is nonconformist to the new multi-core processor (and are not thread aware) and is not able to exploit multiple processors either. Most of these codes will are light weight and do not need the performance of a multi-core system.</p>
<p>2.) Self modifying code will play an important role in the future of &#8220;intelligent&#8221; products and predictive computing, and they are still a handful to manage on single core processors. The introduction of multiple cores will further complicate the working of such code.</p>
<p>3.) The introduction of multiple cores (and multiple processors) on a server also introduces the problem of synchronizing different execution flows on different processors/cores, and the possibility of deadlocks. Greater the number of processors/cores, greater will be the time wasted by the individual processor for synchronization. Thus it is not necessary that the increase in the number of processors/cores will translate to increase in performance. Remember the old adage: &#8220;Too many cooks spoil the broth&#8221;.</p>
<p>The need is to be able to segregate the utility of the server/computer. Gaming needs multiple cores and will have to take a separate path, but servers running normal applications can still work with a single core. The cost of maintaining a complex application is huge, and it is unlikely that the end user will be keen to bear it.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Travis Miller</title>
		<link>http://www.linux-mag.com/id/6552/#comment-1351</link>
		<pubDate>Wed, 30 Jul 2008 22:41:56 +0000</pubDate>
		<guid>http://www.linux-mag.com/id/6552/#comment-1351</guid>
					<description>Azul?  that is amusing.  They are on the first floor of the building I work in (that should make it obvious who I work for if you know where Azul is located).  They have been losing money (did they ever make money in fact?) and little by little my company has been taking over their space and taking more of the spaces in the partking lot.  Niche hardware just doesn't make sense financially.  Your first paragraph is correct, but then your second paragraph seems to contradict that.</description>
		<content:encoded><![CDATA[<p>Azul?  that is amusing.  They are on the first floor of the building I work in (that should make it obvious who I work for if you know where Azul is located).  They have been losing money (did they ever make money in fact?) and little by little my company has been taking over their space and taking more of the spaces in the partking lot.  Niche hardware just doesn&#8217;t make sense financially.  Your first paragraph is correct, but then your second paragraph seems to contradict that.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: jamesf1085</title>
		<link>http://www.linux-mag.com/id/6552/#comment-1350</link>
		<pubDate>Wed, 30 Jul 2008 18:51:09 +0000</pubDate>
		<guid>http://www.linux-mag.com/id/6552/#comment-1350</guid>
					<description>Niche CPU's were never viable because of Moore's Law effect on single core performance.  If you spent a large amount money on research and development to make a processor that ran a specific group programs twice as fast it would be outdated by a general purpose CPU in 5 months.  Which isn't enough time to recover R&#38;D costs in a niche market.  

This means that nonparallel dependency ridden programs will start having niche hardware produced. You are starting to see this is places like Azul. Your right we are gonna start seeing a lot of interesting processors, and there will eventually be even more forks down this processor road.
JamesF
http://www.pervasivedatarush.com</description>
		<content:encoded><![CDATA[<p>Niche CPU&#8217;s were never viable because of Moore&#8217;s Law effect on single core performance.  If you spent a large amount money on research and development to make a processor that ran a specific group programs twice as fast it would be outdated by a general purpose CPU in 5 months.  Which isn&#8217;t enough time to recover R&amp;D costs in a niche market.  </p>
<p>This means that nonparallel dependency ridden programs will start having niche hardware produced. You are starting to see this is places like Azul. Your right we are gonna start seeing a lot of interesting processors, and there will eventually be even more forks down this processor road.<br />
JamesF<br />
<a href="http://www.pervasivedatarush.com" rel="nofollow">http://www.pervasivedatarush.com</a>
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Bryan Richard</title>
		<link>http://www.linux-mag.com/id/6552/#comment-1348</link>
		<pubDate>Tue, 29 Jul 2008 20:54:18 +0000</pubDate>
		<guid>http://www.linux-mag.com/id/6552/#comment-1348</guid>
					<description>&lt;em&gt;core-suck&lt;/em&gt; is my new favorite phrase. 

I'm sorry, Sunoco gas pumps? I'm only 35 so you might need to need to update your analogies a bit. ;-)</description>
		<content:encoded><![CDATA[<p><em>core-suck</em> is my new favorite phrase. </p>
<p>I&#8217;m sorry, Sunoco gas pumps? I&#8217;m only 35 so you might need to need to update your analogies a bit. ;-)
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
