From: "Shot (Piotr Szotkowski)" <shot@...>
Date: 2007-01-20T03:17:36+09:00
Subject: Re: Intensive computing: Ruby? Ruby/C? Pure C++?

Thanks a lot for your reply, Ryan!

// Also, as to not pollute the list with separate mails: thanks to
// everybody else who commented in this thread! I learned more in the
// past two days than I hoped to learn 'till the end of January!
// Unfortunately, it might mean I'll come back with more questions... ;)

Ryan Davis:

> On Jan 17, 2007, at 2:00 AM, Shot (Piotr Szotkowski) wrote:

>> symbolic functional decomposition of FSMs for FPGA implementation

> Some work has been done in this area to some extent. Check
> out RHDL from Phil Tomson. I believe it is pure ruby only.

Thanks, again! I'm already eager to drill into his Ruby-interpretation
of an FSM, and it's not even weekend here yet... :)

>> my gut feeling is that pure Ruby will end up
>> being *way* too slow and memory-inefficient.

> Gut feelings are often wrong. Especially in this arena.

I hope this one is. Still, my supervisor's C++ classes are quite
optimised, and it's not rare for a decomposition to run for two days
straight; hopefully the benchmarks needed to prove the scientific value
of my thesis are of the less-time-consuming kind.

> You can also take advantage of very easy
> parallelism available through systems like rinda.

Thanks for pointing out Rinda, I'll definitely take a closer look.
Unfortunately, decomposition is a highly iterative process, so I doubt
it's at all paralellable (some parts of a single iteration might be,
though).

>> 2. Ruby with C extensions.

> This is the approach I choose most of the time. Just Do It.

I talked with my supervisor, and he said that if going with Ruby means
I'll show up with anything that actually works even just a bit sooner,
then he's all for it. :)

Thanks a lot for pointers to rubyprof and zenprofiler!

-- Shot, currently in the 'Ruby or Lua? Ruby or Lua?' mode...
-- 
I'm not much of a kernel hacker, but a quick (and not very efficient,
granted) fix could be to make the offset an extern variable, yes?
That would force the compiler to fall back on the basic "your gun,
your foot, your choice" memory model.                    -- jtv, LKML