>> IMO, a coprocessor executes the same instruction stream as the >> "primary" processor. > > I'm not so sure about that, the first thing I came across described as
hey! I said IMO, so technically you can't disagree! :) > a coprocessor was the "Tube" for the BBC Micro in the mid 1980's. It > was a Z80 in an external expansion unit that let you run CP/M (which > the hosts 6502 CPU couldn't of course). I think the two most prominent examples would be x87 and perhaps the array coprocessors that were attached to IBM mainframe. (I'm don't remember whether the latter really did sip from the same cup...) > The distinction between the two has come up on the hwloc-devel mailing > list where they pondering where new devices should sit in their > current GPU and co-processor categories, and wondering whether to call > them coprocessors or accelerators. for hwloc purposes, I would think the only salient issue is whether the device directly accesses host memory (that is, not over PCIe. the impression I get of upcoming HSA devices (and I would hope also analagous onces from Intel) is that they might have a PCIe presence (control registers), but they'll access host memory directly/coherently. > Personally I feel that accelerator is a superset that includes > co-processors. to me, "accelerator" strongly suggests a much looser connection: it's a device which speeds up some operation, but might not even be generally programmable. perhaps an FPGA widget that given an appropriate library, can ask to accelerate an fft or perhaps encrypt a block. I envision the host processor waiting on an interrupt or busy-wait on a memory flag while the accelerator does its thing. OTOH, this is close to a potato-potahto thing... regards, mark. _______________________________________________ Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
