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.
Statistics: Posted by shodruk — Fri Jun 07, 2013 12:11 pm
]]>
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!
Statistics: Posted by piotr5 — Fri Jun 07, 2013 10:35 am
]]>
You'r running some code that is supposed to do different math operations on different operators. You can push each math operation to a separate core (as they don't affect each other), but to do that you're going to need to:
1) Parse the application and recognize that parallelization is possible (overhead)
2) Send the data to EACH other core (overhead, especially considering that the Epiphany uses a serial protocol for communication)
3) Complete the operations on each core
4) Receive notice that each core has finished it's operation (overhead)
5) Get the results of each operation and pull it back into the application for further use (overhead)
In the Parallela, this is occurring with a dual-core ARM pushing data into an FPGA pushing data into the Epiphany. It's not so easy.
Dynamic multi-core optimization such as that on modern machines requires A) programs that can handle having multiple threads and B) some sort of supervisory unit that can manage all the data in and out of the system. To keep the speed up, this would probably need to be done in hardware (Zynq FPGA fabric, anyone?).
Anyway. It's a fascinating project and I can't wait to play around with the co-processor.
Statistics: Posted by jeinstei — Thu Jun 06, 2013 5:53 pm
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>