Comments on: The Return of the Vector Processor http://www.linux-mag.com/id/7575/ Open Source, Open Standards Sat, 05 Oct 2013 13:48:18 +0000 hourly 1 http://wordpress.org/?v=3.1 By: lescoke http://www.linux-mag.com/id/7575/#comment-7156 lescoke Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7575/#comment-7156 <p>Ah, yes; the bit-sliced vector processor; The year was 1989, the desktop was evolving from 16-25 MHz 386\'s, to 33 MHz 486\'s. I could pipeline an array of data through an ALU and Multiplier-accumulator to apply a single threaded signal processing algorithm at a rate of one data element per clock cycle. The trick was staging the data flow from one processing element to another so that each had something to do on every clock cycle. Programming was done at the microcode level using a language very similar to assembly called register transfer language (RTL), each processing element control signal, register select, clock enable, etc,... were controlled from bits in a 200 bit instruction word.</p> <p>Many of the idea\'s used in that system have been showing up in DSP\'s and now GPU\'s; the processing power is available, the bottleneck still appears to be keeping them fed with outside data.</p> <p>Les </p> Ah, yes; the bit-sliced vector processor; The year was 1989, the desktop was evolving from 16-25 MHz 386\’s, to 33 MHz 486\’s. I could pipeline an array of data through an ALU and Multiplier-accumulator to apply a single threaded signal processing algorithm at a rate of one data element per clock cycle. The trick was staging the data flow from one processing element to another so that each had something to do on every clock cycle. Programming was done at the microcode level using a language very similar to assembly called register transfer language (RTL), each processing element control signal, register select, clock enable, etc,… were controlled from bits in a 200 bit instruction word.

Many of the idea\’s used in that system have been showing up in DSP\’s and now GPU\’s; the processing power is available, the bottleneck still appears to be keeping them fed with outside data.

Les

]]> By: userda http://www.linux-mag.com/id/7575/#comment-7157 userda Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7575/#comment-7157 <p>Typo: \"bare\" should be \"bear\".</p> <p>As renormalized quantum field theory tells us, fermions are clothed, neot bare. </p> Typo: \”bare\” should be \”bear\”.

As renormalized quantum field theory tells us, fermions are clothed, neot bare.

]]> By: kalloyd http://www.linux-mag.com/id/7575/#comment-7158 kalloyd Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7575/#comment-7158 <p>Les,</p> <p>Ah, yes. Memories (not all good, I\'m afraid).</p> <p>There are all sorts of new questions raised by the new Fermi architecture. First, does the new memory model solve some of the \"particulars\" (or not) in keeping the computational pipeline fed and flowing. I want to see how this works with the L2 cache config and the special function units (who waits on what).</p> <p>I also wonder how the performance of the new FMA compares to the old multadd (MAD). It obviously fixes some of the rounding/dropoff problems - especially welcome in iterative routines. </p> <p>The whole architecture is so radically different than the GT200, I think its going to take some experimentation to find how make best use of it. Lots of potential - now what can we do with that?</p> <p>Ken </p> Les,

Ah, yes. Memories (not all good, I\’m afraid).

There are all sorts of new questions raised by the new Fermi architecture. First, does the new memory model solve some of the \”particulars\” (or not) in keeping the computational pipeline fed and flowing. I want to see how this works with the L2 cache config and the special function units (who waits on what).

I also wonder how the performance of the new FMA compares to the old multadd (MAD). It obviously fixes some of the rounding/dropoff problems – especially welcome in iterative routines.

The whole architecture is so radically different than the GT200, I think its going to take some experimentation to find how make best use of it. Lots of potential – now what can we do with that?

Ken

]]>