<?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: Greg Pfister looks at why now may be the right time for accelerators to stick</title>
	<atom:link href="http://insidehpc.com/2009/07/22/why-accelerators-may-stick-hpc-this-time/feed/" rel="self" type="application/rss+xml" />
	<link>http://insidehpc.com/2009/07/22/why-accelerators-may-stick-hpc-this-time/</link>
	<description>HPC News Without the Noise for Supercomputing Professionals &#124; insideHPC</description>
	<lastBuildDate>Sun, 09 Jun 2013 01:54:13 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.1</generator>
	<item>
		<title>By: Chris Heier</title>
		<link>http://insidehpc.com/2009/07/22/why-accelerators-may-stick-hpc-this-time/#comment-174373</link>
		<dc:creator>Chris Heier</dc:creator>
		<pubDate>Thu, 23 Jul 2009 06:48:49 +0000</pubDate>
		<guid isPermaLink="false">http://insidehpc.com/?p=6394#comment-174373</guid>
		<description>It is a great article.  I think with accelerators, there needs to be a focus on the long term road map really. Take the current trend with GPU.  They are already an add in card to begin with.  They may provide 10x to 100x improvements depending on the applications, but even as the general purpose commodity hardware increases to close the gap, the GPU industry is still improving.  With APIs like CUDA, you are pretty much certain that your application today will work on the GPUs tomorrow, and same with OpenCL.  Although with OpenCL, the expectation is that you will have a general framework that will allow access to numerous accelerator devices and their future incarnations.

ASIC is really where things may still be at issue, but as long as a developer has a roadmap with their product, they should be able to keep relevant, unless their future roadmap involves a product that will be beaten out by, like you say, more general purpose hardware over the next few years.

FPGAs though are a bit of an interesting bag of tricks.  I&#039;ve been looking at FPGA for years, and have worked with the implementation of an FPGA platform for high speed data acquisition and signal processing.  The problem you end up running into down the line is changes in pin counts, gates, registers, etc.  It can be difficult to have an upgrade path unless you are working from higher level interfaces that do all of the loop unrolling and population of logic for you. Even then, upgrade the hardware, upgrade the software to a new version number with a new bin for the updated FPGA board.  Non trivial, but not impossible to have an upgrade path to look towards.</description>
		<content:encoded><![CDATA[<p>It is a great article.  I think with accelerators, there needs to be a focus on the long term road map really. Take the current trend with GPU.  They are already an add in card to begin with.  They may provide 10x to 100x improvements depending on the applications, but even as the general purpose commodity hardware increases to close the gap, the GPU industry is still improving.  With APIs like CUDA, you are pretty much certain that your application today will work on the GPUs tomorrow, and same with OpenCL.  Although with OpenCL, the expectation is that you will have a general framework that will allow access to numerous accelerator devices and their future incarnations.</p>
<p>ASIC is really where things may still be at issue, but as long as a developer has a roadmap with their product, they should be able to keep relevant, unless their future roadmap involves a product that will be beaten out by, like you say, more general purpose hardware over the next few years.</p>
<p>FPGAs though are a bit of an interesting bag of tricks.  I&#8217;ve been looking at FPGA for years, and have worked with the implementation of an FPGA platform for high speed data acquisition and signal processing.  The problem you end up running into down the line is changes in pin counts, gates, registers, etc.  It can be difficult to have an upgrade path unless you are working from higher level interfaces that do all of the loop unrolling and population of logic for you. Even then, upgrade the hardware, upgrade the software to a new version number with a new bin for the updated FPGA board.  Non trivial, but not impossible to have an upgrade path to look towards.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
