Logan, et al, On Sat, Aug 15, 2015 at 10:33 AM, Logan Streondj <[email protected]> wrote:
> > > On Sat, Aug 15, 2015 at 12:54 PM, J. Andrew Rogers <[email protected]> > wrote: > >> >> The ability to design efficient parallel data flows between compute >>> elements is rather important for many classes of algorithm. Join >>> algorithms, for example, which are central to graph traversal. >>> >> >> With FPGAs you can design ANYTHING you can imagine. >> >> >> >> Sure, but many things are faster on commodity fixed silicon. >> > > I'm pretty sure ASIC's are faster for all static algorithms. > The reasons FPGA's are nice is for "dynamic" algorithms, or ones which > weren't predicted to be needed at time of computer construction. Any > algorithm which becomes thoroughly entrenched enough, or is often used in > FPGA it would make sense to migrate onto ASIC's. Though in terms of > evolving algorithms, and adapting to new conditions as an AGI would have > to, FPGA's are much better than pure software algorithms. > In my paper *The Itanium Effect* I discuss mixed-grain FPGA architectures, where this is a mix if big pieces like ALUs, medium-sized pieces like standard cells, and of course the usual tiny pieces - gates. This sort of mixed-grain approach has been used on every plugboard-wired machine ever made back in the unit-record era (from which apparently NO whole machines have survived, even in the Smithsonian), so I am just borrowing a tried and true solution from another era. This sort of approach should be almost as efficient as ASICs, while being almost as flexible as FPGAs, and will provide the ability to easily correct any design errors and upgrade performance on existing chips, as the technology continues to evolve. > > >> I have a friend who designs FPGA codes for high-performance computing >> applications and it is not a good market to be in. This market is getting >> seriously pinched by (1) increasingly rich ISAs in fixed silicon that >> adequately replace most of what an FPGA can do for much cheaper and (2) the >> large and growing percentage of codes that are bandwidth limited. >> >> On the first point, sophisticated vectorized BMI-type ISA extensions give >> you most of the building blocks that an FPGA would give you, and most of >> the inefficiencies of constructing algorithms this way versus an FPGA is >> made up for by the fact that you can run these instructions at 4GHz. And it >> is *much* easier and cheaper to design codes in this domain than to design >> circuits for an FPGA. Intel’s AVX-512 in particular adds a lot of >> functionality for constructing highly pipelined bit-parallel data flow >> algorithms, by design. >> >> IMHO, barrel processors are the most efficient modern computing >> architecture in the abstract. The problem is that there seem to be a dozen >> people in the world that know how to properly design codes for them. This >> is ironic because they are much easier to design for than GPUs or similar >> but no one wants to market them as not being CPU-like and they fake it well >> at first blush. >> > > So please enlighten us, as a member of the dozen. > I was around back when Cray was still at CDC making barrels. Their barrel architecture was COMPLETELY hidden. They looked to the programmer like several separate CPUs. No special programming ability was needed - beyond reading the Principles of Operation manual. At the time, this was just seen as a way to save gates by building slower peripheral processors out of the same fast hardware used in the associated supercomputer's CPU. After all, peripherals (back then) didn't run at (back then) supercomputer speeds. My how things have changed since then, as GPUs first emerged to keep up with peripherals (displays). Steve ================= > > If not map/reduce/expand then what design patterns do you use? > > > >> >> Also, idiomatic C/C++ etc has a CPU-targeted orthodoxy built into it and >> is all programmers know. C++ works fine for barrel processors but idiomatic >> code looks different than for CPUs and no one teaches idiomatic C/C++ for >> barrel processors. >> >> >> >> Long ago ~1982 I presented a paper (the closing presentation at the 1st >> NN conference in San Diego) showing that if you chopped a human brain up >> into many processors that communicated over a single bus, that the >> communications rate would be only ~10^9 brief messages/second. Of course >> this was inconceivably fast for that time, but probably doable now. >> >> >> >> We are not even close to that today, and probably never will be due to >> physics. Any communication system that large is inherently parallel. >> >> >> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now> >> <https://www.listbox.com/member/archive/rss/303/5037279-a88c7a6d> | >> Modify <https://www.listbox.com/member/?&;> Your Subscription >> <http://www.listbox.com> >> > > *AGI* | Archives <https://www.listbox.com/member/archive/303/=now> > <https://www.listbox.com/member/archive/rss/303/10443978-6f4c28ac> | > Modify > <https://www.listbox.com/member/?&;> > Your Subscription <http://www.listbox.com> > -- Full employment can be had with the stoke of a pen. Simply institute a six hour workday. That will easily create enough new jobs to bring back full employment. ------------------------------------------- AGI Archives: https://www.listbox.com/member/archive/303/=now RSS Feed: https://www.listbox.com/member/archive/rss/303/21088071-f452e424 Modify Your Subscription: https://www.listbox.com/member/?member_id=21088071&id_secret=21088071-58d57657 Powered by Listbox: http://www.listbox.com
