to actually get 0.16ms transferrate for each 32k core, you would need to attach the fpga to the north and south eLink. and then you would need to program it...
finally, you should consider where data is sent when, so data isn't stalled because of other cores doing a transfer at the same time. especially if you actually get input from 3 connections...
Statistics: Posted by piotr5 — Mon Feb 23, 2015 9:55 am
]]>
]]>
]]>
]]>
]]>
The idea is to stuff code directly into the Epiphany by using e_write, rather than e_load. Epiphany code simply increments r1 in an endless loop; host code reports back contents of r1 for each core, once per second.
Is this the correct way to point to the start of code? 0x0 is a vector?
edit: I think I've made some fundamental mistake with reading r1 from the core, because using e_write to set r1, then reading it back, doesn't return that value I've set.
<code deleted - see next msg>
Statistics: Posted by rowan194 — Thu Jan 29, 2015 10:29 pm
]]>
It should be possible to roll your own startup code without the newlib. This reduces code size a lot. Oh, and your test main() function should contain an endless loop: On embedded systems, main() should never end.
Statistics: Posted by sebraa — Thu Jan 29, 2015 2:07 pm
]]>
I should make it clear that each candidate program is executed multiple times (one for each item of training/validation data), and the multiple runs can all be done on-core, independent of the host. So it's more like transfer from host, run, run, run, run, run, run (etc) rather than transfer, run, transfer, run. The latter would be very inefficient as the Parallella would spend half the time just shifting data between the two chips.
I think I may have a good read of the Ephiphany datasheet, and a peek at the SDK internals, to see if I can roll my own from first principles. Even a 'blank' program int main() {}; ends up as a 6428 byte SREC file. Because the cores are running a simple program that reads input data, does some calculations and conditional branches, then exits, there's no need to use any C library functions.
Anyway, sorry for rambling, it's really just thinking aloud. I'd be curious to know if anyone has bypassed the SREC/e_load() system.
Statistics: Posted by rowan194 — Thu Jan 29, 2015 10:37 am
]]>
let only 15 cores fight it out, and a write-protected 16th core serves the changes?
then the only data on host will be just intermediate results and maybe some rng-seeds...
Statistics: Posted by piotr5 — Thu Jan 29, 2015 10:07 am
]]>
Statistics: Posted by rowan194 — Thu Jan 29, 2015 7:02 am
]]>
That way, you can get around the SREC files. Since you'll probably call some kind of linker, you might still have intermediate files - it might be worth keeping them on a ram disk on the host.
Statistics: Posted by sebraa — Wed Jan 28, 2015 11:19 pm
]]>
The trouble is that e_load() wants a filename, but it's going to be very inefficient to have to create a new file each time, especially since it's not just a flat bin file. Imagine having to write out 500 SREC files each generation?
Can I roll my own to load (from the host memory) and execute a program (on the Epiphany), using something like e_write then e_start? Or does e_load do a lot more?
(One option may be to e_load a 'blank' program, then in a loop use e_read to save the core, including code/data/IVT, modify machine code in host memory, then e_write back?)
Statistics: Posted by rowan194 — Wed Jan 28, 2015 9:06 pm
]]>