From: ptkwt@... (Phil Tomson) Date: 2005-09-05T14:36:27+09:00 Subject: Re: Ruby compilers (for DSP processors and alike) In article <431ACED1.5000204@skynet.be>, Bart Masschelein wrote: >Ok, let me explain a bit more what I am aiming for... I'll explain it >with the work I'm currently doing. The ultimate goal is to have MPEGs >latest video codec, SVC (Scalable Video Codec), running on a >multi-processor platform, with heterogenous processors for regular >kernels, like motion compensation, and dedicated hardware for >bit-mingling stuff, like the arithmetic coder. We start at the highest >level, taking the reference software from MPEG. The next step is running >this software through our in-house developed toolset, which analyses for >instance the number of accesses (reads, writes) to the arrays in the >program. This gives you information on where to reduce and reuse data >access, and hence accesses to memories, and hence the power consumption, >which enables you to watch video longer on a mobile device. These tools >also gives you a hint on memory hierarchy in the design, how much L1, L2 >and higher level memory you need, so you can reduce memory accesses to >big memories, as there are more energy consuming. The idea is that >production of data and consumption of data should be as close as >possible, avoiding storage of huge data sets, for instance complete >frames of a sequence. > >This worked out quite well, since all reference software until now was >written in C, and our toolset only allows C as input. But the reference >software of SVC is written in C++, so these tools were not usuable >anymore, so yours truly, and that is where the frustration comes from, >has to rewrite the complete codec into C, so our tools can support it. >The problem they have with having C++ as input is the dynamic behaviour >of the data, they analyses the data statically, not at run-time, so when >you instantiate an object from a class using new, they cannot analyse >that. Which sounds strange to me, they can as well do run-time analysis >in my opinion, but that is a discussion I will have to have with them. > >Anyway, so I thought Ruby might pop in here, because of the >metaprogramming concepts. I think that might solve a lot of their >problems. But I don't have any proofs yet, so I'm trying to figure these >things out now, with small examples. So just to understand: you need to be able to find out how many times various arrays in the SVC implementation are accessed (read or written to) during some specified time period and you think that if you had these algorithms in Ruby that would be easy (correct?). It probably would be easy as you could (for example) override the Array access operators ( [] and []=) to record this information. Couldn't you do something similar in C++ (yeah, it would be more difficult than in Ruby, but certainly doable): Create a class that stands in for the arrays (or vectors or whatever collection class that might be used from the STL) that monitors access to the data in the collections? Bascially, you could create an 'instrumented' version of your current C++ code for the SVC that, when run, would collect all of the statistics you're looking for. (or am I misunderstanding something?) Or to put it another way: Let's say the reference C++ code for the SVC algorithms uses an STL vector for the collection class. You could create a class called MonitoredVector that has-a STL vector as a member. All access operators in MontoredVector eventually call the same access operators (methods) in the STL vector, but first they record the statistics you're looking for somewhere and then make the calls to the delegate. You wouldn't even need to change your C++ SVC code very much - just change the std::vector declarations to monitoredVector declarations (or even use a typedef to make it really easy to switch back-and-forth between the two). > > >>If you develop algorithms then you can use Ruby to prototype a new algorithm >>(if it's not already way to slow even for this) but writting optimized >>algorithm for processing multimedia in ruby is the hugest possible mismatch >>of language and application domain i've seen so far. It's always my >>example that in this cases a ruby program is about 100-200 times >>slower then a c program. >> >> >I knew there was going to be a decrease in speed, but 100-200 times >more, that IS a lot... Isn't a plus one for Ruby... > >>If you only have a few optimized low level algorithms that are easy to >>interface you could write a c extension and use ruby as a scripting language. >> >> >I guess that could indeed be the approach to take then, start with a >high level, full implementation of the algorithm in Ruby, and when the >algorithm is optimized, rewriting kernels (intra-prediction, motion >estimation, ...) in C and use them as C extension. Or could you even take the C++ reference code you get and use Swig (http://www.swig.org) to wrap that code so that you can access the C++ classes from Ruby? > >>Maybe you could explain a little bit more what exactly you are looking >>for and what you want to do with a ruby -> c translater (what kinds of >>code should it translate ?). >> >> >I would not expect that ruby->C translator could translate a full SVC >application to C with a push of the button. That would be Utopia, but if >it could handle kernels, which are just a bunch of methods in a class, >eventually, that would be great. > >I will continue writing some test examples, thinking of how I can >replace some of their tools with a Ruby variant, and try to convince >them with the simplicity of such tools compared with their C >implementation. It will be a hard one, but a nice time-spending then >rewriting C++->C so their tools can support it. Question: After you analyze the algorithm and optimize it, will you be targetting hardware (like an FPGA using an HDL like VHDL or Verilog) or will it run on a DSP? Phil