Parallella Community

Interesting! SHMEM seems to be a good solution. Since I already have the MPI written, I think I will just stick w/ MPI + OpenSHMEM. Thank you for your insight (and code).

So, if I am understanding the 32KB of memory correctly, this means if I have an array of 57 byte structs, I could only have an array with roughly 574 items per core? If I am computing over a larger dataset I would need the 32MB of DRAM, resulting in a significant performance drop-off?

edit: Also, is this possible with Coprthr 1.6? The download link for Coprthr 2 is broken on the website.

This link is broken? http://www.browndeertechnology.com/code ... -2.0.1.tgz

Funny...it seems to work for me. Send me a PM with your email address if you would like me to email it to you.

COPRTHR 1.6 supported OpenCL/STDCL and none of the new COPRTHR device-level interface needed for more efficient execution on Parallella. You can read about the COPRTHR 2.0 improvements in

You should probably pad your 57-byte struct, otherwise you have misaligned accesses (I think the compiler should do this unless you give it the packed attribute). If you have any 64-bit struct elements, they should be 8-byte aligned. If your 57 byte struct is 64 bytes in memory, you could fit 512 if you didn't have any instructions or anything else in the core scratchpad memory. But since you probably want to compute, expect your instructions and stack to take up perhaps half of that (this depends on the application and could be less).

Awesome response sebraa. So, exchanging data between the ARM's memory and each individual eCore is faster than each eCore exchanging data with the shared 32MB?