Parallella, Raspberry Pi, FPGA & All That Stuff

OK, it's here ( my coloring ) :

Quote:

On every clock cycle, the following operations can occur:
- 64 bits of instructions can be fetched from memory to the program sequencer.
- 64 bits of data can be passed between the local memory and the CPU’s register file.
- 64 bits can be written into the local memory from the network interface.
- 64 bits can be transferred from the local memory to the network using the local DMA

Oh, I see. But being able to perform one such action per cycle only gives you the throughput. It doesn't tell you how long it will take to finish these actions, i.e. the latency. From you other post:

Quote:

Every router in the mesh is connected to the north, east, west, south, and to a mesh node. Write transactions move through the network, with a latency of 1.5 clock cycles per routing hop. A transaction traversing from the left edge to right edge of a 64- core chip would thus take 12 clock cycles.

That's what I was getting at: the latency to finish that write depends on the distance between the chip and can be much more than 5 clocks (still fast, though!). I hope we didn't just talk about different "how long"s all the time: "How long does it take the sender to send the write?" versus "How long does it take for the write to arrive?". Actually.. your initial statement was "I can write into the memory (or was it register?) of another core in 5 cycles". So it's actually the total latency to finish the write.

Quote:

In theory at least, one might 'unroll' a loop to perform the same essential calculations on several cores, with each core doing what might have been done for a single loop iteration ie. accounting for different values of whatever loop variable(s) would have otherwise been updated per round of the loop.

That's what I'm occasionally using in MATLAB with a parfor loop. The overhead there is significant, though, in that individual loops have to exceed 10's or better 100's of ms of runtime for this to provide any benefit. Which greatly limits its applicability.. so I'm a bit jealous about what you could do at a low level. On the other hand I'm not all that keen on spending the time to hand-tweak such details ;)

Quote:

A subtle bit here is we are using RISC processors which by definition will/may/could have an expanded code memory footprint for a given task(s) c/w their CISC cousins ( but not necessarily ).

Considering Parallela is starting from scratch here and that the individual cores are fairly simple, I'd actually expect their instruction footprint to be less than x86. Especially if 16 bit instructions can sometimes be used.

MrS

Quote:

Quote:

Sorry for the lack of communication!! We have been in a pretty delicate position (nothing related to the board or the chips). Hopefully some day I can tell everyone the whole horrific story...

my guess is that they've been occupied at a business, not technical, level with a potential big backer or contract or somesuch that didn't go as well as .

I suspect a challenge on their intellectual property.

On the other hand I'm not all that keen on spending the time to hand-tweak such details ;)