Hi, is Ruby capableof making use of multiple CPUs?
Thanks, Ben
On Mar 1, 2006, at 8:03 AM, Ben Gun wrote:
Hi, is Ruby capableof making use of multiple CPUs?
Not really, no. It’s coming though, eventually…
James Edward G. II
On Wed, 1 Mar 2006, Ben Gun wrote:
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
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
The grandparent to my post mentioned DRb, or “Distributed Ruby”.
Here’s a link for the interested: http://chadfowler.com/ruby/drb.html
James
The grandparent to my post mentioned DRb, or “Distributed Ruby”.
Here’s a link for the interested: http://chadfowler.com/ruby/drb.html
James
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
On Mar 1, 2006, at 8:43 AM, Ben Gun wrote:
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.
–
Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
Eric H. wrote:
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?
On Thu, 2 Mar 2006, Joel VanderWerf wrote:
Eric H. wrote:
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?
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
On Thu, 2 Mar 2006, Joel VanderWerf wrote:
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.
something like this done in pure ruby would be amazing. i think there
is an
ocaml one too… ensemble? something like that.
regards.
-a
[email protected] wrote:
what are you trying to do? i think i’d be quite interested too. didn’t
romp
use udp?
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.