multi CPU machine

[Ben Gun]

Hi, is Ruby capableof making use of multiple CPUs?

Thanks, Ben

 

[James Edward Gray II]

Hi, is Ruby capableof making use of multiple CPUs?

Not really, no. It's coming though, eventually...

James Edward Gray II

 

[ara.t.howard]

Hi, is Ruby capableof making use of multiple CPUs?

Thanks, Ben

sure. just use multiple processes. with drb this is easier and safer than
threads - i've got 40 processes running on 20 machines as we speak.

regards.

-a

 

[James H.]

I thought Ruby threads all ran within the same process, which are
inherently restricted to running on a single processor? (i.e. many
processes can be on many CPUs, but any given process is restricted to
one CPU)

James

 

[James H.]

The grandparent to my post mentioned DRb, or "Distributed Ruby".
Here's a link for the interested: http://chadfowler.com/ruby/drb.html

James

 

[James H.]

The grandparent to my post mentioned DRb, or "Distributed Ruby".
Here's a link for the interested: http://chadfowler.com/ruby/drb.html

James

 

[Ben Gun]

Thanks Ara,
If I understand correctly, the methods are run on the server, so what
I want are servers (one on each CPU) and one client that connects to
these servers to dish out the work. Is that correct?

I understand drb uses TCP/IP. Can I leave the connections open once
established?

Another important question: How do I get the data transferred? Is
there a way to share data?

Regards, Ben

 

[Eric Hodel]

Thanks Ara,
If I understand correctly, the methods are run on the server, so what
I want are servers (one on each CPU) and one client that connects to
these servers to dish out the work. Is that correct?

It doesn't matter, DRb isn't client-server, its peer-to-peer wrapped
in the guise of client server. You can either have a controller that
tells work machines what to do or you can have work machines ask a
controller what to do.

I understand drb uses TCP/IP. Can I leave the connections open once
established?

DRb uses TCP by default. It can also use unix domain sockets, UDP,
or you could write your own protocol.

Another important question: How do I get the data transferred? Is
there a way to share data?

DRb makes that transparent. Just do it like you would in a regular
program.

 

[Joel VanderWerf]

DRb uses TCP by default. It can also use unix domain sockets, UDP, or
you could write your own protocol.

Does anyone know of a working example of drb over UDP sockets? There
doesn't seem to be any support in the 1.8.4 stdlib, but maybe there is
some other library you have to add?

 

[ara.t.howard]

Does anyone know of a working example of drb over UDP sockets? There
doesn't seem to be any support in the 1.8.4 stdlib, but maybe there is
some other library you have to add?

what are you trying to do? i think i'd be quite interested too. didn't romp
use udp?

http://raa.ruby-lang.org/project/romp/

-a

 

[Joel VanderWerf]

what are you trying to do? i think i'd be quite interested too. didn't
romp
use udp?

http://raa.ruby-lang.org/project/romp/

No particular use right now. A few years ago I read that it was
possible, and I *think* there were files in the stdlib to support it,
but I couldn't get them to work. Now I don't see anything in there
relevant to udp.

DRb over UDP might be useful for projects where I work. We already use
UDP heavily, for vehicle-to-infrastructure (and v2v) wireless, so time
in range is very constrained, especially at high vehicle speeds, or in
safety critical situations. Broadcast UDP beats UDP (no DHCP time) and
UDP beats TCP (no handshake). The channel is inherently unreliable, so
the extra cost of TCP doesn't buy much.

Even if DRb over UDP works, it would probably take some tweaking to get
it to work with broadcast UDP (using some kind of unique session key for
addressing, as we do now for our air protocols), in those cases where
static IP is not possible.

For most of our protocols, DRb simply won't be acceptable because it
would force ruby on everyone who wants to talk over the network. It
might be ok for some debugging/monitoring code, though.

 

[ara.t.howard]

No particular use right now. A few years ago I read that it was
possible, and I *think* there were files in the stdlib to support it,
but I couldn't get them to work. Now I don't see anything in there
relevant to udp.

DRb over UDP might be useful for projects where I work. We already use
UDP heavily, for vehicle-to-infrastructure (and v2v) wireless, so time
in range is very constrained, especially at high vehicle speeds, or in
safety critical situations. Broadcast UDP beats UDP (no DHCP time) and
UDP beats TCP (no handshake). The channel is inherently unreliable, so
the extra cost of TCP doesn't buy much.

Even if DRb over UDP works, it would probably take some tweaking to get
it to work with broadcast UDP (using some kind of unique session key for
addressing, as we do now for our air protocols), in those cases where
static IP is not possible.

For most of our protocols, DRb simply won't be acceptable because it
would force ruby on everyone who wants to talk over the network. It
might be ok for some debugging/monitoring code, though.

me thinks you want to be checking out spread. there are even ruby bindings.

http://spread.org/

something like this done in pure ruby would be amazing. i think there is an
ocaml one too... ensemble? something like that.

regards.

-a