[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

multi CPU machine

Ben Gun

3/1/2006 2:00:00 PM

Hi, is Ruby capableof making use of multiple CPUs?

Thanks, Ben
11 Answers

James Gray

3/1/2006 2:16:00 PM

0

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 Gray II

Ara.T.Howard

3/1/2006 3:19:00 PM

0

James Herdman

3/1/2006 3:50:00 PM

0

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 Herdman

3/1/2006 3:53:00 PM

0

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

James

James Herdman

3/1/2006 3:53:00 PM

0

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

James

Ben Gun

3/1/2006 4:36:00 PM

0

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 Thu, 2 Mar 2006 00:19:24 +0900, ara.t.howard@noaa.gov wrote:

>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

Eric Hodel

3/1/2006 9:07:00 PM

0

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 Hodel - drbrain@segment7.net - http://blog.se...
This implementation is HODEL-HASH-9600 compliant

http://trackmap.rob...

Joel VanderWerf

3/1/2006 11:57:00 PM

0

Eric Hodel 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?

--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

Ara.T.Howard

3/2/2006 1:31:00 AM

0

Joel VanderWerf

3/2/2006 3:47:00 AM

0

ara.t.howard@noaa.gov wrote:
> On Thu, 2 Mar 2006, Joel VanderWerf wrote:
>
>> Eric Hodel 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/pro...

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.

--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407