Parallella, Raspberry Pi, FPGA & All That Stuff

It wouldn't currently compete on performance anywhere near the existing GPU porting of E@H WU's, as their current arrays are too small for that ( Apteva's primary focus is on lowering price and power consumption ). But I envisage having an Epiphany array in a co-processor role, which could thus be handed off the stuff that it would be quite spectacular at eg. matrix manipulations, and thus delivering great performance on algorithms for which that is key ( Fast Fourier Transforms ). Their simplest offering is 4 x 4 for around $100 USD, however the design scales up to 64 x 64 ... I was most intrigued by their matrix multiplications using blocks within the matrix shifted synchronously b/w nodes, roughly speaking a two dimensional pipeline.

Cheers, Mike.

( edit ) The programming skill would largely be a matter of having a "parallel approach" and not language per se. For instance the address space within any given array is unprotected, meaning that any node/processor can read and write to any other's memory within a globally flat space, so the discipline required to prevent any incongruities arising from that would have to come from the program design and compilation. So you'd want to identify the elements in the problem space that could be simultaneously and independently executed, and if we have already written for GPU thread parallelism then that aspect is largely done.

( edit ) This also highlights an issue/query that arises here from time to time : why can't GPU's be used to speed up ? Answer : Algorithm X or the problem space it arises from may not have sufficiently parallel aspects for that to yield a gain over non-massively-parallel solutions.

There certainly is a lot to swallow ! :-)

Actually they have said they will consider developing an OpenCL facility for it. Now that's a clever move, these guys are forwards thinkers for sure.

Also each node ( RISC processor plus it's slab of local memory ) is connected to each of three independent data buses that constitutes the 'mesh', two for writing and one for reading, with no latency on the channel that does fast on-chip writes b/w nodes. That goes ~ 16 x faster than corresponding reads! That's quite an asymmetry and a processor can never stall using that type of write! That would imply a chunk of buffering by the network-on-chip system. Anyways I think the hint there is : if a node_B needs results from a node_A, it is far more efficient for node_A to execute the above fast write to node_B's local memory THAN node_B executing a much slower read from node_A's memory. ( Plus Node_A will know better when it's finished some computation step, as opposed to Node_B polling ). Given that said data transfer could also include flags/semaphores/etc to coordinate/validate any data state, then you have a real snappy mechanism in the hardware to satisfy most 'process/thread' cooperation paradigms. [ There is specifically a TESTSET command at hardware level which is an atomic "test-if-not-zero" followed by conditional write. This is the usual mechanism to prevent deadlocks/races and whatnot/troubles with semaphores et al ]

Cheers, Mike.

( edit ) Think of the Three Stooges trying to go through the same door at the same time : 'after you Larry' ... 'no, after you Curly' ... 'please, you first Moe' ... 'no I couldn't' ... 'I must insist' ... 'no, I couldn't possibly' ... eventually they jam in the doorway and fight.

( edit ) You may be thinking : how can one label a data bus as 'only for reading' or 'only for writing', that typically being a question of perspective or which end you're at ? Answer : the difference is the specification of the addressing, who is controlling the transaction, and buffering. A read request has a 'return to sender' address component that a write doesn't ( similiar to a stamped self-addressed envelope ). That propagates through the mesh going left/right along a row and then going up/down along a column until the target node is found, and ditto for the return leg. A write does simply the first phase, in fact a node receiving data from another node's write does not know who sent it ( well, not from the hardware at least ).

( edit ) Of course such an array of processors can be task dedicated without double duty, unlike GPU's which generally perform a system graphics role also. BTW currently either a USB or an Ethernet pathway is how to connect such a co-processor to some 'host' system. There is talk of other modes, say even digital video output. So one can attach it to all manner of devices via suitable I/O ports. The other slower write channel, called xMesh, is for such off-chip connections - which could well be another similiar chip, but may be anything with appropriate circuit level compatibility/buffering. As you can tell I am rather enthused ... :-)

Hey they've bumped up ~ $100K in the last day!! I'd given up hope ... so I've just gone up myself - the $199+ package ( 64 core Epiphany IV on the stretch ).

Cheers, Mike.