by piotr5 » Sat Mar 07, 2015 7:48 am
I agree with Andreas, but Mike suggests something alike to bytecode and a scripting-language.
i.e. the program generates messages for other cores, and this "team" then executes the script piped there.
this is a completely different approach than directly sending compiled assembler-instructions.
if you create the script at run-time, a lot of overhead is generated, for example to calculate number of cores needed.
additionally this asynchronous approach can't use the "host" core for joining into the calculations.
instead I think people like mike would be happier with a meta-programming approach:
create the program to be executed in parallell inside a seperate file.
through some preprocessor magic this file then becomes an epiphany program.
to make things smoother, that file could be generated during compilation.
some parser would seek out such p_programs transform the sources, and create those p-source-files.
but ideally I'd just put the code to be executed in parallell into some header-file.
then some generic epiphany-sources could include that header and become the sourcecode.
at the same time the caller would also include the same code so that it becomes blocking again.
this way the number of needed cores would be calculated at compile-time.
actually, if you do this approach, maybe take a peek at the program "octave" and its syntax?
many matlab users would be happy if pal-syntax would offer the same command-set.
I suspect this would then need c++ though. i.e. make use of operator+ instead of p_add.
and if people still need the scripting-approach, just port octave itself, to parallella and epiphany...