Epiphany engine

[Tomo]

I was looking through the posts and many programming languages are facing the same problem - implementation of their language on epiphany cores. Some are starting to use OpenCl as a temporary solution, but still they are all facing the same problems.
One solution could be an engine which would abstract the memory management, garbage collection on epiphany cores, JIT compiling ... etc. There could be an API for the programming languages and the optimizations that would be made in the engine would be usable across several languages. Instead all those programming languages trying to solve the same problem alone, the process could be more centralized. The engine would be tailored to the specs of epiphany cores.
Ok no solution will solve all problems, but because resources are low, the idea of epiphany engine could speed up adopt
ion and speed up programming time of developers. Not all developers are willing to learn idiosyncrasies of the workings of epiphany cores.

[Gravis]

[Tomo]

[notzed]

This sounds like something HSAIL is trying to do. Depending on how much support that gets on other platforms it may be the 'easiest' solution?

I think even a parallella-wide solution isn't really going to garner enough resources to make much of a go of it because it's such a big task, whereas HSAIL is at least attempting to solve the same problem and will have more resources on it. I'm not up on all the details though, i think it's something like a llvm backend with maybe some other runtime stuff.

[shodruk]

Begin small, grow big.

[Gravis]

[over9000]

This is a complicated topic, and there isn't really a one-size-fits-all solution. It's not only scripted languages that have problems with mapping to the Epiphany CPU architecture, though: even Java and C/C++ have problems due to the non-shared memory architecture, which isn't even supported in most languages, unlike the regular thread/process level multitasking and inter-process communications primitives for shared-memory architectures.

Personally, I think that rather than looking at gcc and llvm backends, it'd be much more productive to come up with a new IDL-like ("Interface definition language") language (sorry for excessive recursive acronym syndrome there) that focuses on the common kinds of interactions we can have between host/device and between device nodes. Basically we're talking about either producer/consumer queues of one kind or another (eg, file is being read in on the ARM producer side and hashed in the device side, or generic "mailbox" type primitive built on top of the same producer/consumer queue abstraction) or software interrupts for IPC. By using a declarative language (ie, the IDL) and inserting the appropriate C code for the producer/consumer or interrupt handler parts, we can compile the language into plain C that has all the necessary data declarations and calls to the Epiphany SDK to transparently handle all the memory allocation, event loop, DMA transfers and so on. This would free the developer from having to dive into these things at a low level.

Besides queues, mailboxes and software interrupts, the language would probably also expose some other Epiphany-SDK-centric constructs like inter-core mutexes and synchronisation primitives (wall), although strictly speaking the developer can just assume they're available and put the appropriate calls into his stub C code since we'd be including all the appropriate SDK headers in the generated code. Another aspect of the platform that would have to be exposed in the language would be the physical layout of cores, so that we know what "modules" (programs) to run on which core and how they're "wired up" (communicate with each other).

Where I'm coming from on all of this is the idea of taking the most basic design patterns for multicore/accelerator style architecture (like PS3 and the Epiphany) and abstracting away all the most complicated or platform-dependent bits. There was a commercial rapid prototyping toolkit/language for the PS3 called (IIRC) Streams or something like that took the same approach.

Another idea from the PS3 development world was the (pdf) that was basically a C library for doing cooperative multitasking (via dynamic loading/overlays and a small kernel for handling the event loop and loading). I think that something like this could also be useful and might also end up being part of the same high-level language idea, so long as you don't mind your program looking more like a state machine than a traditional C program.

Of course, there's no reason why you have to invent a new high-level language for something like this. We can just use the SDK or convenience libraries (like the X-library someone posted a link to). The main advantage of a new language, though, are that all the grunt-work involved in carving up the "shared" memory areas and writing and debugging the queue/IPC mechanisms can be avoided. Since it would be compiled to C anyway, it can target the x-libs or SDK (or a MARS-like backend library) and you can modify the generated code by hand if it doesn't support some feature that you need (though improving the language would make it much more usable for other developers).

Well, that's my idea of how best to go about making the Epiphany more accessible for regular programmers...

[over9000]

[Tomo]

Gravis I agree with you that there is no reason for anger here. It seems there was some miscommunication here and if I have in any way offended you then I am sorry.

I know that compile time gives better speed than runtime execution, but i want to get a pie and eat it too. And yes I know it is not gonna be easy.
With the support of other languages the epiphany processors would get even a bigger interest in programming communities.
Erlang was also promised in kickstarter, so there is a question how will the virtual machine be implemented.
For java you could go with gcj, but development has stalled years ago and the support for java is even considered to be dropped from gcc, so the sumatra project is the best contender for java implementation.
If there were support for Java virtual machine on epiphany cores, then you could use Jython and JRuby and also Php (Quercus) on JVM. And maybe you could than use Hadoop, Swift ... etc.
The main reason is that when you get a critical mass of programmers on your side, you can move mountains (virtually you can).

Even if you never venture in the land of scripting languages, you do want them to come to epiphany cores, if you want parallella to succeed.

As I look at parallella I see that there could be a lot of potential in many different directions and I am happy that adapteva has implemented gcc for epiphany cores, but there could be even more ...

over9000 - There definitely needs to be some abstraction between average developer and the epiphany cores.
Some dynamic assignment to epiphany cores with some worker queue would be better than statically assigning their usage.
There is one more advantage of an IDL is it forces a programmer to think in a way it utilizes the hardware more optimally and at the same time it can even eliminate some usage that could be erroneous.

Epiphany core is like a raw diamond, which will have to be shaped and polished with lots and lots of good code. So we need a lot of good programmers.

[Gravis]