Computer Vision using Ruby and libJIT19 Nov 2009
Ruby originated in Japan, the country which is world-leading in robotic research. It suggests itself to put the two together and to start using Ruby as a language to program robots. However at the moment the performance of available Ruby interpreters is not sufficient. It is hard to achieve performance comparable to compiled C++-code since manipulation of Ruby-integers and Ruby-arrays requires frequent bounds-checking. It can be shown that universal bounds-check elimination is actually impossible.
This talk presents HornetsEye which is a Ruby-extension facilitating the development of real-time machine vision algorithms for future robotic applications. HornetsEye offers I/O facilities to capture and display videos. HornetsEye also can be integrated into GUI-applications developed with Qt4-QtRuby. Furthermore there is a set of Ruby classes which provides the means to compose native datatypes and specify operations on them. The libJIT just-in-time compiler is used to achieve real-time performance. The project was inspired by NArray and ruby-libjit.
The software is called HornetsEye and it is available under the terms and conditions of the GPL.
Feel free to leave comments below.
Future work on HornetsEye could be about using lazy computation to avoid the creation of intermediate results when doing array operations. Here’s a small prototype implementation. Let me know if you have any suggestions.
Using the following code one can use reflection to interpret Ruby code in order to for example translate it to machine code later.
Unfortunately Ruby reflection does not capture creation of variables, assignment of values, and control structures such as while or if-then-else.
One could use “monkey patching” to add GPU support (using OpenCL) in a transparent way. Furthermore it would be desirable to make use of multi-core computers. Ruby 1.9 supports native threads but there is a global interpreter lock on extension calls. So multi-threading has to be implemented explicitely if it is to be used in such a Ruby extension.
It was suggested to me to
- make the array classes available separately
- to use Rubygems for packaging the software and Gemcutter for publishing the software
- to use Git for version control and to host the repositories on Github
- to use ffi so that the extension works with different Ruby VMs (JRuby, Rubinius, …)