Announcing PAL: The Parallel Architectures Library

[mikebell]

[xilman]

[mikebell]

[mikebell]

[aolofsson]

[aolofsson]

[quote="mikebell"]Back to the core PAL library, question for Andreas:
Do you expect the p_math operations to be synchronous, or do you need to do something to be able to read the result array?
[/code]

Assumption was that library calls would all be blocking.

[mikebell]

What is your expectation of an average PAL program?

Mine is currently something like:
- Open up the device and define a team
- Maybe in a loop:
- Read in input arrays from somewhere (e.g. network)
- Execute 100s of p_xxx calls using the same team
- Output processed arrays to somewhere.

Under this assumption, my suggestion is a library user would prefer to get the performance benefits that async p_xxx calls might allow, as they have no need to read or write the arrays between most p_xxx ops.

I could well be wrong though - maybe it is naive to assume that most programs won't have to do a bunch of specialised work on the host between p_xxx calls (presuambly due to conditional processing). Even so, I guess I'd like to see the possibility of an async mode thought about in the API and left open in the implementation at least, even if it's not the focus for now.

On specifying number of cores on each p_xxx call - I don't see why a user would normally want to do this. I'd expect the library to just leave extra cores idle if it was faster to do a simple op using just a few of the team. To my mind having to provide both "all" and "team" arguments on every function call is just making the programmer do extra typing just for the benefit of possibly being able to make things go a bit faster if the library didn't do the right thing by default for their program.

[aolofsson]

Mike,

Thanks for explaining where you are coming from! Makes sense. If you are effectively thinking of this as a host-accelerator setup with thousands of kernels being sent out, then non-blocking might make sense...let's keep talking.

In my view, there is no host, only big cores and little cores...the sweet spot for the epiphany has always been real time signal processing (image processing from camera and wireless communication in particular). In those cases everything more or less becomes a pipeline that needs to be balanced and minimized. (really not trivial).

There is no default when it comes to parallelism. While we do have a lot of cores, they are still a precious resource and we should always use as few cores as possible. There is always a cost to communicating between cores. Running slowly on one core leaving all other cores shut down will be more efficient going forward. The control over how much parallelism there should be should be decided by the application/programmer/code generator or something else.

The library can't figure out how many or how few cores it should be using. This would be the equivalent of running some kind of compiler/synthesis while the code is running?

For traditional hosted-accelerator environments it would seem possible to add some kind of wrapper layer to save typing?

Andreas

[piotr5]

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...

[xilman]