Parallella Community

Looking through the threads and also looking at the difficulties of adapting people to a minority architecture it seems to me that JITs are the way forward for maximising the usage of Parallella and the Epiphany processors.

Looking at the boards I see there has been some discussion about LLVM which is good but I would like to throw another into the ring: what about LuaJIT and DynASM? Given that most JITs/VMs take up more than 32kB I think it putting the JIT on the core itself isn't efficient, but if the JIT can do the dispatching of tasks, even generating the assembler then we would reduce the need for target specific skills around Epiphany.

Another one, and don't shoot me here, what about JavaScript? Obviously it is 2am here and I need some sleep but increasingly JS is doing interesting things (e.g. Node.JS) and in some cases getting as fast as compiled languages because of its self-optimising use of assembly. Could one of the existing assembly code generators be modified to output Epiphany ASM, because these JITs are actually able to measure and decide if an off-loaded ASM task is faster than the interpreted code. Given that Node.JS is non-blocking the parallel possibilities are quite good.

Now, I am off to bed.

In principle this would be a dream come true that a partial program function/loop running on host can be unfolded/optimized then transformed to co-processor machine code to run. And this process is transparent to the original program.

Yes, there is still a long way to go, I would say if LLVM is ready for ecore we should be try something like that in some particular case.

What you're describing is the same as the Java/lambda/sumatra stuff. And fits with the HSA processing model. And It's pretty much the only solution which will work outside of custom C code.

Rather than support a full independent runtime for each core, treat them as a hetereogenous processing resource which can be called upon for tasks which suit it's processing model (i.e. parallel, in-memory, non-i/o). Ultimately the goal is that the distinction between 'master' and 'slave' will blur and any cooperating processor will be able to utilise another as a resource if that suits some given part of the problem better.

Java 8 has the benefit of having explicit language features which can be transparently mapped to such a model. It's important that it is transparent because it provides a generic way to access these resources that are beneficial on ANY modern computer (even a single-core has SIMD units which this can utilise) and so general programs will start to use the features and not just stuff specifically written for parallella. A similar approach could be implemented for any scripting languages with extension capabilities. It's complicated a bit by not having an mmu on the epiphany (although it should be possible to put some level of one in the fpga) so you can't just directly share data pointers, but it isn't a deal-breaker since everything pretty much needs to be copied to LDS anyway.

Javascript has some design issues centred around it's dynamic nature which make it difficult to *ever* execute code very fast. ASM.js just isn't javascript anymore - except by syntax. And in reality it is just a political solution to a technical problem (i.e. a terrible one). It's trying to solve the problem of distributing byte-code to multiple browsers from competing companies that hate each other without a plugin - by abusing the one thing they have managed to sort-of cooperate on.