Actually I was refering to the case where one needs to do a couple of
heavy independent tasks, which could benefit from parallel execution.
Specfically I was thinking in a 3d simulator I have written that uses
physics + graphics + logics (the first two in C++, the later in Ruby),
and I think some tasks could be executed in parallel there.

Anyway, for the type of problems you mention (something like a big
problem that can be solved with divide & conquer) mpi-ruby seems
interesting and its good to know it exists.

Matt

On 12 dic, 16:34, Hedge Hog <hedgehogshia...@gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
>
>
> On Sun, Dec 13, 2009 at 2:26 AM, v01d  wrote:

> > Hi,
> > I'm a little interested in a possible future where Ruby could be used
> > for heavy processing stuff (but by means of calling computationally
> > heavy C code, and take advantage of multi-core processors by doing
> > several of these calls in parallel native threads) and I just found
> > out about Ruby's "rb_thread_blocking_region" C call.

>

> > What came to my mind is that maybe FFI could be used here to make
> > writing these type of parallelized Ruby extensions easier, by just
> > doing something like:

>

> > module RubyAPI
> >  extend FFI::Library
> >  attach_function :rb_thread_blocking_region,
> > [ :pointer, :pointer, :pointer ], :void
> > end

>

> > then maybe I'm wrapping a HeavyComputationLibrary:

>
> My 2c:
> Context: I take 'HeavyComputation' to mean 'saturates more than one machine'.
> In that case I think you'd be using somthing like this:http://github.com/abedra/mpi-ruby
>
> ffi-mpi-ruby would be interesting.
>
> My preference has been to _try_ avoid threading and any issues it
> causes.  I would rather just throw more instances of a ruby script
> (processes, somtimes processes>=processors/cores) at the problem -
> this does scale beyond one machine.  Threading doesn't.
> It has been a while since I used MPI and there may be threading buried
> in the library above.
>
> Of course 'HeavyComputation' might mean using only one machine.  Then
> scaling is not an issue and maybe threading is undisputably the best
> way to go?
> As I said, just my 2c.
>
> HH
>
>
>
>
>

> > module HeavyComputationLibrary
> >  extend FFI::Library
> >  attach_function :long_running_computation, [ :pointer ], :value
> >  attach_function :unblock_computation, [ :pointer ], :void
> > end

>

> > and then do something like:
> > RubyAPI.rb_thread_blocking_region
> > (HeavyComputationLibrary.long_running_computation, data_ptr,
> > HeavyComputationLibrary.unblock_computation)

>

> > Obviously there are a couple of non-existing things here (like passing
> > the function pointer of a C function (maybe there's already a way to
> > do that?), usage of :value), but I wanted to ask if this is feasible
> > or not.
> > I think that something like this could ease writing parallel-aware
> > Ruby extensions (maybe with some help of Ruby Inline) for existing C
> > libraries. Then again, I may be wrong.

>

> > Matt

>

> > PS: I'm obviously talking about Ruby 1.9 and the function call defined
> > here:http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/10252

>
> - --
> πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
> [The fox knows many things, but the hedgehog knows one big thing.]
>   Archilochus, Greek poet (c. 680 BC – c. 645 BC)http://wiki.hedgehogshiatus.com
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Use GnuPG with Firefox :http://getfiregpg.org(Version: 0.7.10)
>
> iEYEARECAAYFAksj8EYACgkQL/DTCig+NhfFWQCeKK5ohPsJzjieM2y1HSv7l4Dq
> 8gIAn1b97tMd/o4sBg1uPX+JJFRVDMf7
> =Mj85
> -----END PGP SIGNATURE-----