Wait, why developers?

[piotr5]

problem is: A) most programmers don't realize their program is really designed in a way it can handle multiple threads. B) since we have a serial communication it would be best if multiple cores could contribute to sending some data to its destination, much allike to torrent-software where low bandwidth of multiple nodes sums up into high-bandwidth transfer. I mean, quite naturally between 2 transfers there will be a gap, another core could take advantage of that and send some other data. in effect transfer can be quadrupled this way. not sure if that's also possible for ARM-Epiphany transfers -- the picture suggests the cores in the corner would get data twice as fast from the ARM, than the cores on the edge, because of having 2 instead of 1 connection to the outside...

of course analyzing a "program" gives overhead, some overhead also happens with administrative tasks like asking if the cores have finished. but since the compiler knows how a program works, maybe it could greatly reduce those overheads? often the same data is stored in many different places, maybe transfer isn't needed at all, maybe the data generated during compilation could be useful for the program itself, maybe some conditionals are not needed at all beccause of always being true/false. the intel-compiler has an interesting feature: run the compiled program to collect data about its behaviour, and then use that data for compiling a much faster version of that program. I think such profiling data would also be interesting when handling programs that run in parallel. afterall it isn't important to know if some program can have multiple threads according to the programmer, instead it is important to know if using multiple threads will actually speed up anything, or if the overhead is making things worse. and in solving that question one must also know how the dataflow is going to happen since the path the data takes contributes to the overhead. in effect this is a software problem because the hardware is not as easily adaptable as the software -- i.e. one can assume the hardware will always stay the same and use the hardware's predictability to adjust the software to the various circumstances. make the software aware of how the underlying hardware works!

[shodruk]

I think we should use only one thread per core on Epiphany for eliminating slicing overhead.
There are still 16 threads!!
64 threads on E64!!
1024 threads on E1024???

and, we are able to minimize the task sync overhead by maximizing the task grain size.
In many cases, the sync operation is only needed at the thread start and join point.