From: Bryan Richardson <btricha@...>
Date: 2008-10-16T06:58:25+09:00
Subject: Re: Multiple Processors on Windows 64-bit

Hi Robert,

I didn't really know what to expect... I'm not a low-level OS guy so I
don't really understand how all that stuff works -- hence my
questions.  I figured it was worth a shot, tried it, and commented on
my results.

I should have put the word smart in quotes before -- it was meant as
sarcasm.  I don't think that would be the smart way to go, but I have
no clue how Ruby is implemented on Windows.  I understand Ruby uses
green threads, but I'm not sure if that's from process to process or
machine-wide.  Looks like it's from process to process based on your
answer of 'no' below.

I apologize for disclosing information piecemeal.  It wasn't
intentional -- I just failed to think about the other application when
asking my question originally.  As for the example you gave me to try
earlier... I have not tried it yet (I tried the easy one first).  I'll
shut my trap now until I've heeded your advice.

--
Bryan

On Wed, Oct 15, 2008 at 3:14 PM, Robert Klemme
<shortcutter@googlemail.com> wrote:
> On 15.10.2008 18:29, Bryan Richardson wrote:
>>
>> Well, I'm not sure the 'start /affinity' approach is fixing my problem
>> either... the applications still seem to trade off computing time.
>
> Well, what did you expect?  Even if you set affinity, OS scheduling still
> takes place.  With other processes running you might actually negatively
> impact the whole system by restricting processor affinity.
>
>> This might be for a couple of reasons:
>>
>> 1) Does Ruby try to be *smart* and consolidate all Ruby processes in one
>> thread?
>
> No.  Why should that be smart anyway (keep in mind that Ruby uses green
> threads)?
>
>> 2) My Ruby applications are starting up and making calls to a Windows
>> application via an OLE interface, so maybe the referenced Windows
>> applications are running on the same processor.
>
> You disclose details about your application piecemeal.  It's difficult to
> analyze this remotely anyway but it's impossible when you do not know what
> other facts are missing.
>
>> Suggestions?
>
> Keep on looking.  Did you try how your OS scheduling works with the example
> I gave you earlier?
>
> Kind regards
>
>        robert
>
>