by Tomo » Mon Dec 09, 2013 10:57 pm
I think the epiphany engine would need a kernel driver - which would be responsible for epiphany cores.
It could manage the loading of programs into cores - priority queues (latency sensitive, bandwith sensitive, insensitive) .. etc. And you would be able to load programs under your user and not only root. Only root could stop programs from other users, while users could only stop their own programs. The utilization could be higher if many users could use the cores in timesharing fashion.
Like Gravis mentioned in "manycore programming style and intercore communications" there is a need for abstraction.
I belive we will need a library to provide for some abstraction for accessing ram and intercommunication between cores, if we wish to have functionality like 3D Dram and external DRAM with QoS. Similar approach was given with "Hera-JVM: Abstracting Processor Heterogeneity Behind a Virtual Machine"- using Cell processors with 4 times the memory of epiphany core but very similar in function, it also uses migration of programs from main processor fo the APU-s and from APU core to the main processor where needed. If library can abstract away the memory allocation and the core on which it is running as well as intercommunication, it gives a possibility for migration of processes across cores and the main processors(ARM). Because you would want your group of processors which are running the same program and which are codependent to run as closely together as phisically possible and migration would help with that.
To run VM-s on epiphany cores transparently a lot will have to be done, but i think the library would be first step to go. You can alway make API-s for other languages.