[Beowulf] Quasi-Non-Von-Neumann hardware in a Beowulf cluster.

[Omri Schwarz]

On Thu, 10 Mar 2005, Robert G. Brown wrote:

> On Thu, 10 Mar 2005, Joe Landman wrote:
>
> Problems with coprocessing solutions include:
>
>   a) Cost -- sometimes they are expensive, although they >>can<< yield
> commensurate benefits for some code as you point out.
>

The COTS variants of coprocessor products are driven by market
demand for making Lara Croft look more like Angelina Jolie.
For us, that's good. It means the price might be right.

>   b) Availability -- I don't just mean whether or not vendors can get
> them; I mean COTS vs non-COTS.  They are frequently on-of-a-kind beasts
> with a single manufacturer.

Alas, the same market interaction above is driving prices down but
puts pressure on these products having proprietary interfaces.

Electronic Arts, Inc (17 days without a fatal case of karoshi!)
would certainly like it that way.

>   c) Usability.  They typically require "special tools" to use them at
> all.  Cross-compilers, special libraries, code instrumentation.  All of
> these things require fairly major programming effort to implement in
> your code to realize the speedup, and tend to decrease the
> general-purpose portability of the result, tying you even more tightly
> (after investing all this effort) with the (probably one) manufacturer
> of the add-on.

But! If you're not an overly bespoke Beowulf user,
i.e. you use linear algebra packages, DSP, or so on and so forth,
and you devote the time to implement a library on such hardware,
you instantly have a community of people with similar needs,
an ability to help you, and your vendor now has a market that
might be worth paying attention to.
SGI seems to think so as far as GPUs go.