Parallella Community

Hey all,

thanks again to 9600 and the other staff on the parallella-project. Great work so far what I have seen.

In case there is interest in having ruby to do multi- and many-core programming on a parallella board, this topic is right for ideas, thoughts and (technical) design questions.

I will update this post here with upcoming ideas, questions, ...

First some initial specifications/ideas
* The ruby implementation should offer the same features as the c/c++ implementation.
* should be possible to test via simulator

The Project should offer:
* a ruby gem (the product) as a wrapper for the epiphany sdk (cause rubygems are C Extensions for Ruby in many cases)
* a cli based project-tool. Like the way RubyOnRails or RubyMotion offer, so you can use an editor+terminal or eclipse/ide and use these build tools. Free for decision.

Questions so far:
* As I understand the Epiphany Architecture, we do not need to build ruby on top of Epiphany?! Is that right? So a comprehensive ruby lib which uses the c lib should do the trick?

Use Cases:
* The first use case that comes in mind is having easy access to epiphany with a ruby framework like sinatra or rails.

Thanks for reading,

Oli

Since nobody else has commented, I would like to register my interest in this topic. I've been a ruby developer for 6-7 years, but I've yet to write a C-wrapper, so not sure I'd be much help there - though if you have started a project, I will more than happily test it and tinker.

Given the host is simply an arm device that can run Ubuntu, ruby will already be available (both as binaries, and probably via something like RVM) and it will run a sinatra / rails app without breaking a sweat. The epiphany sdk gem will be the interesting part - something that mimics the standard Thread library would be pretty amazing. Not sure whether that would be feasible, or whether the memory available to each 'daughter' CPU would limit what Ruby would be able to do.

Another possibility is mruby - an MRB gem may solve some of the problems above.

Need to do more research, but yeah - full ruby support would be pretty epic!

Have just seen this: https://github.com/mattn/mruby-thread

Haven't got much time to tinker with it or see if it works, but if it works then it could be an excellent starting point for an epiphany version. This post is more for my future self's own benefit than anything, but if anyone wants to give this a go please let me know!

Ruby on the ARM CPU will be fairly trivial. Ruby on the Epiphany will be "interesting" to say the least. The best bet for the latter for now would be a tiny specialized bytecode VM and adapting the parsing and bytecode compiler for MRI (Matz Ruby implementation - the "standard") to do more of the work. Maybe expanding to JIT'ing subsets.

There are both some big challenges and opportunities: On one hand, executing Ruby is conceptually very simple: Pretty much everything is a method call (and optimizing away the method calls is hard). On the downside, pretty much everything is a method call. This means that even simple things like an addition potentially consists of dozens of instructions. Ruby also wastes lot of memory on meta-data about the objects and classes.

I'm working on a Ruby compiler, and would love to be able to get it to the point were generating code to run straight on Epiphany cores was realistic, but for now at least, the class hierarchy itself would exhaust the memory of a Epiphany core and force lots of access to off-core memory.

It might be better to provide Ruby on the host and focus on something similar to Ruby Inline to allow you to write Epiphany code in Ruby. E.g. start with a module to allow you to inline Epiphany assembly, and then layer convenience methods to built higher level code for it as a way to accelerate specific functionality.

interesting

thread in basic virtual machine i c ruby is still for one processor.