Using multicore CPUs in parallel tasks

[Marc Hoeppner]

Hi,

I've been reading around a bit but couldn't find a solution that worked,
so here goes:

I am running ruby 1.8 and want to make full use of a quad core CPU
(64bit, Ubuntu) in a task that lends itself to multithreading/multicore
use.

It's basically an array of objects that are each use in a fairly CPU
intensive job, so I figured I could have 4 of them run at the same time
, one on each CPU.

BUT...

The only reasonably understandably suggestion looked something like:

----
threads = 4
my_array = [something_here]

threads.times do
 Process.fork(a_method(my_array.shift))
end

my_array.each do |object|
 Process.wait(0)
 Process.fork(a_method(object))
end
---

But this still only used one CPU (and looks a bit ugly..). Is that some
limitation of ruby (v 1.8 specifically) or am I doing something wrong?

Cheers,

Marc
--
Posted via http://www.ruby-forum.com/.

[Rajinder Yadav-3]

On Thu, Oct 29, 2009 at 10:56 AM, Marc Hoeppner
<marc.hoeppner@...> wrote:

> Hi,
>
> I've been reading around a bit but couldn't find a solution that worked,
> so here goes:
>
> I am running ruby 1.8 and want to make full use of a quad core CPU
> (64bit, Ubuntu) in a task that lends itself to multithreading/multicore
> use.
>
> It's basically an array of objects that are each use in a fairly CPU
> intensive job, so I figured I could have 4 of them run at the same time
> , one on each CPU.

You might want to checkout Pure and Tiamat and talk to James Lawrence
(see links). He seems to have something you are asking for. I don't
know much about these 2 project, they came by my radar a few days ago
but I think it's cool what James is working on!

== Links

* Pure: http://purefunctional.rubyforge.org

* Documentation: http://tiamat.rubyforge.org
* Download: http://rubyforge.org/frs/?group_id=9145
* Rubyforge home: http://rubyforge.org/projects/tiamat
* Repository: http://github.com/quix/tiamat

== Author

* James M. Lawrence <quixoticsycophant@...>

> BUT...
>
> The only reasonably understandably suggestion looked something like:
>
> ----
> threads = 4
> my_array = [something_here]
>
> threads.times do
>  Process.fork(a_method(my_array.shift))
> end
>
> my_array.each do |object|
>  Process.wait(0)
>  Process.fork(a_method(object))
> end
> ---
>
> But this still only used one CPU (and looks a bit ugly..). Is that some
> limitation of ruby (v 1.8 specifically) or am I doing something wrong?
>
> Cheers,
>
> Marc
> --
> Posted via http://www.ruby-forum.com/.
>
>

--
Kind Regards,
Rajinder Yadav

http://DevMentor.org

Do Good! - Share Freely, Enrich and Empower people to Transform their lives.

[Glen Holcomb]

On Thu, Oct 29, 2009 at 8:56 AM, Marc Hoeppner
<marc.hoeppner@...>wrote:

> Hi,
>
> I've been reading around a bit but couldn't find a solution that worked,
> so here goes:
>
> I am running ruby 1.8 and want to make full use of a quad core CPU
> (64bit, Ubuntu) in a task that lends itself to multithreading/multicore
> use.
>
> It's basically an array of objects that are each use in a fairly CPU
> intensive job, so I figured I could have 4 of them run at the same time
> , one on each CPU.
>
> BUT...
>
> The only reasonably understandably suggestion looked something like:
>
> ----
> threads = 4
> my_array = [something_here]
>
> threads.times do
>  Process.fork(a_method(my_array.shift))
> end
>
> my_array.each do |object|
>  Process.wait(0)
>  Process.fork(a_method(object))
> end
> ---
>
> But this still only used one CPU (and looks a bit ugly..). Is that some
> limitation of ruby (v 1.8 specifically) or am I doing something wrong?
>
> Cheers,
>
> Marc
> --
> Posted via http://www.ruby-forum.com/.
>
>

You are going to want Ruby 1.9 for this.  In 1.8 threads are "green",
basically they only exists as threads inside the VM so you still only hit
one core and any blocking system I/O will block all of your threads.

--
"Hey brother Christian with your high and mighty errand, Your actions speak
so loud, I can’t hear a word you’re saying."

-Greg Graffin (Bad Religion)

[Peter Booth-3]

Marc,

How long lived is each of these tasks? Are we talking seconds or weeks?
Is there a user-facing aspect to this or is throughput the variable  
that you're wanting to optimize?

When you say "fairly CPU intensive", doe sthis mean that when one of  
these tasks runs you see (from sar/mpstat) that one of your CPUs is  
pinned?

Peter


On Oct 29, 2009, at 10:56 AM, Marc Hoeppner wrote:

> Hi,
>
> I've been reading around a bit but couldn't find a solution that  
> worked,
> so here goes:
>
> I am running ruby 1.8 and want to make full use of a quad core CPU
> (64bit, Ubuntu) in a task that lends itself to multithreading/
> multicore
> use.
>
> It's basically an array of objects that are each use in a fairly CPU
> intensive job, so I figured I could have 4 of them run at the same  
> time
> , one on each CPU.
>
> BUT...
>
> The only reasonably understandably suggestion looked something like:
>
> ----
> threads = 4
> my_array = [something_here]
>
> threads.times do
> Process.fork(a_method(my_array.shift))
> end
>
> my_array.each do |object|
> Process.wait(0)
> Process.fork(a_method(object))
> end
> ---
>
> But this still only used one CPU (and looks a bit ugly..). Is that  
> some
> limitation of ruby (v 1.8 specifically) or am I doing something wrong?
>
> Cheers,
>
> Marc
> --
> Posted via http://www.ruby-forum.com/.
>

[Tony Arcieri]

On Thu, Oct 29, 2009 at 11:48 AM, Glen Holcomb <damnbigman@...> wrote:

> You are going to want Ruby 1.9 for this.  In 1.8 threads are "green",
> basically they only exists as threads inside the VM so you still only hit
> one core and any blocking system I/O will block all of your threads.
>

Ruby 1.9 isn't going to help you when using threads to distribute
computation across CPU cores.  The Global VM Lock ensures that simultaneous
computation is still limited to one core.

JRuby, on the other hand, does not have this limitation.  On MRI/1.9 I would
recommend using multiple processes.

--
Tony Arcieri
Medioh/Nagravision

[Glen Holcomb]

On Thu, Oct 29, 2009 at 2:04 PM, Tony Arcieri <tony@...> wrote:

> On Thu, Oct 29, 2009 at 11:48 AM, Glen Holcomb <damnbigman@...>
> wrote:
>
> > You are going to want Ruby 1.9 for this.  In 1.8 threads are "green",
> > basically they only exists as threads inside the VM so you still only hit
> > one core and any blocking system I/O will block all of your threads.
> >
>
> Ruby 1.9 isn't going to help you when using threads to distribute
> computation across CPU cores.  The Global VM Lock ensures that simultaneous
> computation is still limited to one core.
>
> JRuby, on the other hand, does not have this limitation.  On MRI/1.9 I
> would
> recommend using multiple processes.
>
> --
> Tony Arcieri
> Medioh/Nagravision
>

Ah, I did not know that.

--
"Hey brother Christian with your high and mighty errand, Your actions speak
so loud, I can’t hear a word you’re saying."

-Greg Graffin (Bad Religion)

[Robert Klemme-2]

On 10/29/2009 09:04 PM, Tony Arcieri wrote:

> On Thu, Oct 29, 2009 at 11:48 AM, Glen Holcomb <damnbigman@...> wrote:
>
>> You are going to want Ruby 1.9 for this.  In 1.8 threads are "green",
>> basically they only exists as threads inside the VM so you still only hit
>> one core and any blocking system I/O will block all of your threads.
>
> Ruby 1.9 isn't going to help you when using threads to distribute
> computation across CPU cores.  The Global VM Lock ensures that simultaneous
> computation is still limited to one core.

Are you saying that the global VM lock even extends to several
processes?  Because Marc did not want to use threads for distribution
but rather processes.

Kind regards

        robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[Robert Klemme-2]

On 10/29/2009 03:56 PM, Marc Hoeppner wrote:

> Hi,
>
> I've been reading around a bit but couldn't find a solution that worked,
> so here goes:
>
> I am running ruby 1.8 and want to make full use of a quad core CPU
> (64bit, Ubuntu) in a task that lends itself to multithreading/multicore
> use.
>
> It's basically an array of objects that are each use in a fairly CPU
> intensive job, so I figured I could have 4 of them run at the same time
> , one on each CPU.
>
> BUT...
>
> The only reasonably understandably suggestion looked something like:
>
> ----
> threads = 4
> my_array = [something_here]
>
> threads.times do
>  Process.fork(a_method(my_array.shift))
> end
>
> my_array.each do |object|
>  Process.wait(0)
>  Process.fork(a_method(object))
> end
> ---
>
> But this still only used one CPU (and looks a bit ugly..). Is that some
> limitation of ruby (v 1.8 specifically) or am I doing something wrong?

I believe you are not using Process.fork properly.  In fact, I am
surprised that you do not get an exception:

irb(main):001:0> Process.fork("foo")
ArgumentError: wrong number of arguments (1 for 0)
        from (irb):1:in `fork'
        from (irb):1
        from :0

Basically what you do is you do a calculation (a_method(object)) and
_then_ you create a process.  No surprise that only one CPU is busy.

Here's something else that you could do

processes = 4

my_array.each_slice my_array.size / processes do |tasks|
   fork do
     tasks.each do |task|
       a_method(task)
     end
   end
end

Process.waitall

Drawback is that one of those processes might accidentally get all the
easy tasks and you do not utilize CPUs optimally.  Here's another
solution that does not have that issue

processes = 4
count = 0

my_array.each do |task|
   if count == processes
     Process.wait
     count -= 1
   end

   fork do
     a_method(task)
   end
   count += 1
end

Process.waitall

You can see that it works with this example:

processes = 4
count = 0

10.times do |task|
   if count == processes
     Process.wait
     count -= 1
   end

   fork do
     printf "%-20s start %4d %4d\n", Time.now, $$, task
     sleep rand(5) + 2
     printf "%-20s end   %4d %4d\n", Time.now, $$, task
   end
   count += 1
end

Process.waitall


Kind regards

        robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[Tony Arcieri]

On Thu, Oct 29, 2009 at 4:05 PM, Robert Klemme
<shortcutter@...>wrote:

> On 10/29/2009 09:04 PM, Tony Arcieri wrote:
>
>> Ruby 1.9 isn't going to help you when using threads to distribute
>> computation across CPU cores.  The Global VM Lock ensures that
>> simultaneous
>> computation is still limited to one core.
>>
>
> Are you saying that the global VM lock even extends to several processes?
>  Because Marc did not want to use threads for distribution but rather
> processes.
>

No, if you look over my post again it specifically mentions the GVL applies
to threads and suggests using processes.

--
Tony Arcieri
Medioh/Nagravision

[Robert Klemme-2]

2009/10/29 Tony Arcieri <tony@...>:

> On Thu, Oct 29, 2009 at 4:05 PM, Robert Klemme
> <shortcutter@...>wrote:
>
>> On 10/29/2009 09:04 PM, Tony Arcieri wrote:
>>
>>> Ruby 1.9 isn't going to help you when using threads to distribute
>>> computation across CPU cores.  The Global VM Lock ensures that
>>> simultaneous
>>> computation is still limited to one core.
>>
>> Are you saying that the global VM lock even extends to several processes?
>>  Because Marc did not want to use threads for distribution but rather
>> processes.
>
> No, if you look over my post again it specifically mentions the GVL applies
> to threads and suggests using processes.

I figured as much.  The thread discussion does not help Marc, because
he explicitly wanted to use processes for core utilization.  Basically
Glen sent us in the wrong direction though. :-)

Cheers

robert


--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[Marc Hoeppner]

Robert Klemme wrote:

> I believe you are not using Process.fork properly.  In fact, I am
> surprised that you do not get an exception:
>
> irb(main):001:0> Process.fork("foo")
> ArgumentError: wrong number of arguments (1 for 0)
>   from (irb):1:in `fork'
>   from (irb):1
>   from :0

Yes, quite possible - I didn't really look up the exact code, just wrote
it down from memory, sorry about that..

>
> processes = 4
> count = 0
>
> my_array.each do |task|
>    if count == processes
>      Process.wait
>      count -= 1
>    end
>
>    fork do
>      a_method(task)
>    end
>    count += 1
> end
>
> Process.waitall
>

That works like a charm, thanks a lot!
--
Posted via http://www.ruby-forum.com/.

[James M. Lawrence-2]

Robert Klemme wrote:

> processes = 4
> count = 0
>
> my_array.each do |task|
>    if count == processes
>      Process.wait
>      count -= 1
>    end
>
>    fork do
>      a_method(task)
>    end
>    count += 1
> end
>
> Process.waitall

Another option,

Tiamat.open_local(4) {
  pure do
    fun_map :result => my_array do |elem|
      a_method(elem)
    end
  end.compute.result
}

This lets you distribute across N physical machines without a change to
the code.
--
Posted via http://www.ruby-forum.com/.

[James M. Lawrence-2]

Tony Arcieri wrote:
> Ruby 1.9 isn't going to help you when using threads to distribute
> computation across CPU cores.  The Global VM Lock ensures that
> simultaneous computation is still limited to one core.
>
> JRuby, on the other hand, does not have this limitation.  On MRI/1.9
> I would recommend using multiple processes.

I'm not so sure jruby does this effectively.

require 'tiamat/autoconfig'
require 'pure/dsl'
require 'benchmark'

mod = pure do
  def total(left, right)
    left + right
  end

  def left
    (1..5_000_000).inject(0) { |acc, n| acc + n }
  end

  def right
    (1..5_000_000).inject(0) { |acc, n| acc + n }
  end
end

Benchmark.bmbm { |bm|
  bm.report("1 thread, 1 interpreter") {
    mod.compute(1).total
  }
  bm.report("2 threads, 1 interpreter") {
    mod.compute(2).total
  }
  # this part removed for jruby bench
  bm.report("2 threads, 2 interpreters") {
    Tiamat.open_local(2) {
      mod.compute.total
    }
  }
}

== ruby 1.9.2dev (2009-10-18 trunk 25393) [i386-darwin9.8.0]
Rehearsal -------------------------------------------------------------
1 thread, 1 interpreter     4.370000   0.020000   4.390000 (  4.389990)
2 threads, 1 interpreter    4.360000   0.030000   4.390000 (  4.385111)
2 threads, 2 interpreters   0.010000   0.010000   4.700000 (  2.460661)
--------------------------------------------------- total: 13.480000sec

                                user     system      total        real
1 thread, 1 interpreter     4.360000   0.020000   4.380000 (  4.376050)
2 threads, 1 interpreter    4.360000   0.030000   4.390000 (  4.380982)
2 threads, 2 interpreters   0.010000   0.010000   4.710000 (  2.465925)


== jruby 1.4.0RC3 (ruby 1.8.7 patchlevel 174) (2009-10-30 1d7de2d) (Java
HotSpot(TM) Client VM 1.5.0_20) [i386-java]
Rehearsal ------------------------------------------------------------
1 thread, 1 interpreter    6.060000   0.000000   6.060000 (  6.060000)
2 threads, 1 interpreter   7.629000   0.000000   7.629000 (  7.629000)
-------------------------------------------------- total: 13.689000sec

                               user     system      total        real
1 thread, 1 interpreter    6.080000   0.000000   6.080000 (  6.080000)
2 threads, 1 interpreter   7.288000   0.000000   7.288000 (  7.288000)


--
Posted via http://www.ruby-forum.com/.

[Rajinder Yadav-3]

On Fri, Oct 30, 2009 at 11:07 AM, James M. Lawrence
<quixoticsycophant@...> wrote:

> Robert Klemme wrote:
>> processes = 4
>> count = 0
>>
>> my_array.each do |task|
>>    if count == processes
>>      Process.wait
>>      count -= 1
>>    end
>>
>>    fork do
>>      a_method(task)
>>    end
>>    count += 1
>> end
>>
>> Process.waitall
>
> Another option,
>
> Tiamat.open_local(4) {
>  pure do
>    fun_map :result => my_array do |elem|
>      a_method(elem)
>    end
>  end.compute.result
> }
>
> This lets you distribute across N physical machines without a change to
> the code.

This is just elegant =) ... it's funny how I observer something then
more of what I observer comes in to the fold! Was hoping you would
reply to the thread ;)
> --
> Posted via http://www.ruby-forum.com/.
>
>

--
Kind Regards,
Rajinder Yadav

http://DevMentor.org

Do Good! - Share Freely, Enrich and Empower people to Transform their lives.

[Glen Holcomb]

On Fri, Oct 30, 2009 at 2:06 AM, Robert Klemme
<shortcutter@...>wrote:

>
>
>
> I figured as much.  The thread discussion does not help Marc, because
> he explicitly wanted to use processes for core utilization.  Basically
> Glen sent us in the wrong direction though. :-)
>
>
I've always worked best as a diversion.

--
"Hey brother Christian with your high and mighty errand, Your actions speak
so loud, I can’t hear a word you’re saying."

-Greg Graffin (Bad Religion)

[Charles Oliver Nutter-4]

On Fri, Oct 30, 2009 at 10:14 AM, James M. Lawrence
<quixoticsycophant@...> wrote:

> == ruby 1.9.2dev (2009-10-18 trunk 25393) [i386-darwin9.8.0]
> Rehearsal -------------------------------------------------------------
> 1 thread, 1 interpreter     4.370000   0.020000   4.390000 (  4.389990)
> 2 threads, 1 interpreter    4.360000   0.030000   4.390000 (  4.385111)
> 2 threads, 2 interpreters   0.010000   0.010000   4.700000 (  2.460661)
> --------------------------------------------------- total: 13.480000sec
>
>                                user     system      total        real
> 1 thread, 1 interpreter     4.360000   0.020000   4.380000 (  4.376050)
> 2 threads, 1 interpreter    4.360000   0.030000   4.390000 (  4.380982)
> 2 threads, 2 interpreters   0.010000   0.010000   4.710000 (  2.465925)
>
>
> == jruby 1.4.0RC3 (ruby 1.8.7 patchlevel 174) (2009-10-30 1d7de2d) (Java
> HotSpot(TM) Client VM 1.5.0_20) [i386-java]
> Rehearsal ------------------------------------------------------------
> 1 thread, 1 interpreter    6.060000   0.000000   6.060000 (  6.060000)
> 2 threads, 1 interpreter   7.629000   0.000000   7.629000 (  7.629000)
> -------------------------------------------------- total: 13.689000sec
>
>                               user     system      total        real
> 1 thread, 1 interpreter    6.080000   0.000000   6.080000 (  6.080000)
> 2 threads, 1 interpreter   7.288000   0.000000   7.288000 (  7.288000)

JRuby benchmarking:

* Use Java 6+

Java 6 is much faster than Java 5. Java 7 is faster still in many cases.

* Pass --server if -v output says "client" VM

The Hotspot JVM has two modes: "server" and "client". The "server" VM
does runtime-profiled optimizations and can be 2x or more faster than
the "client" VM.

Results on my system (core 2 duo 2.66GHz):

ruby 1.9.2dev (2009-07-23 trunk 24248) [i386-darwin9.7.1]
Rehearsal -------------------------------------------------------------
1 thread, 1 interpreter     3.370000   0.020000   3.390000 (  3.516261)
2 threads, 1 interpreter    3.330000   0.020000   3.350000 (  3.412460)
2 threads, 2 interpreters   0.010000   0.000000   3.590000 (  2.133313)
--------------------------------------------------- total: 10.330000sec

                                user     system      total        real
1 thread, 1 interpreter     3.350000   0.010000   3.360000 (  3.415410)
2 threads, 1 interpreter    3.350000   0.020000   3.370000 (  3.423560)
2 threads, 2 interpreters   0.000000   0.010000   3.630000 (  2.302965)

jruby 1.5.0.dev (ruby 1.8.7 patchlevel 174) (2009-10-30 eaa9e7f) (Java
HotSpot(TM) 64-Bit Server VM 1.6.0_15) [x86_64-java]
Rehearsal ------------------------------------------------------------
1 thread, 1 interpreter    2.373000   0.000000   2.373000 (  2.373000)
2 threads, 1 interpreter   1.733000   0.000000   1.733000 (  1.733000)
--------------------------------------------------- total: 4.106000sec

                               user     system      total        real
1 thread, 1 interpreter    2.145000   0.000000   2.145000 (  2.145000)
2 threads, 1 interpreter   1.840000   0.000000   1.840000 (  1.840000)

It would probably improve more with a longer run, but this is pretty good.

- Charlie

[James M. Lawrence-2]

Charles Nutter wrote:
>
> JRuby benchmarking:
>
> * Use Java 6+
>
> Java 6 is much faster than Java 5. Java 7 is faster still in many cases.
>
> * Pass --server if -v output says "client" VM

I didn't consider it because the behavior I showed looks wrong for
either Java 5 or Java 6 in either client or server mode.  Indeed I
obtained the same results with Java 6 Server VM.

A computation split into two parallel threads takes more time than the
same computation with one thread.  'top' reports 185% CPU and 100% CPU
respectively.

I was not concerned with comparing MRI and jruby.  MRI was a baseline
to demonstrate that Pure's parallelism was working in the first place.

I was unable to find your eaa9e7f commit so I grabbed the latest
master branch.

jruby 1.5.0.dev (ruby 1.8.7 patchlevel 174) (2009-11-02 55366a1) (Java
HotSpot(TM) 64-Bit Server VM 1.6.0_15) [x86_64-java]

Core 2 Duo 1.83GHz; all apps closed except Terminal; benchmarks made
without 'top' running.

Rehearsal ------------------------------------------------------------
1 thread, 1 interpreter    3.422000   0.000000   3.422000 (  3.422000)
2 threads, 1 interpreter   4.008000   0.000000   4.008000 (  4.008000)
--------------------------------------------------- total: 7.430000sec

                               user     system      total        real
1 thread, 1 interpreter    2.942000   0.000000   2.942000 (  2.942000)
2 threads, 1 interpreter   3.595000   0.000000   3.595000 (  3.595000)

Results are the same with Pure removed:

  require 'benchmark'

  def left
    (1..10_000_000).inject(0) { |acc, n| acc + n }
  end

  def right
    (1..10_000_000).inject(0) { |acc, n| acc + n }
  end

  Benchmark.bmbm { |bm|
    bm.report("1 thread") {
      Thread.new {
        [left, right]
      }.value
    }
    bm.report("2 threads") {
      [
        Thread.new { left },
        Thread.new { right },
      ].map { |t| t.value }
    }
  }

Rehearsal ---------------------------------------------
1 thread    6.726000   0.000000   6.726000 (  6.726000)
2 threads   7.478000   0.000000   7.478000 (  7.478000)
----------------------------------- total: 14.204000sec

                user     system      total        real
1 thread    6.636000   0.000000   6.636000 (  6.636000)
2 threads   8.196000   0.000000   8.196000 (  8.196000)

--
Posted via http://www.ruby-forum.com/.

[Charles Oliver Nutter-4]

On Mon, Nov 2, 2009 at 11:47 AM, James M. Lawrence
<quixoticsycophant@...> wrote:
> Rehearsal ------------------------------------------------------------
> 1 thread, 1 interpreter    3.422000   0.000000   3.422000 (  3.422000)
> 2 threads, 1 interpreter   4.008000   0.000000   4.008000 (  4.008000)
> --------------------------------------------------- total: 7.430000sec
>
>                               user     system      total        real
> 1 thread, 1 interpreter    2.942000   0.000000   2.942000 (  2.942000)
> 2 threads, 1 interpreter   3.595000   0.000000   3.595000 (  3.595000)

This does not match my results. Are you sure both cores are being used?

> Rehearsal ---------------------------------------------
> 1 thread    6.726000   0.000000   6.726000 (  6.726000)
> 2 threads   7.478000   0.000000   7.478000 (  7.478000)
> ----------------------------------- total: 14.204000sec
>
>                user     system      total        real
> 1 thread    6.636000   0.000000   6.636000 (  6.636000)
> 2 threads   8.196000   0.000000   8.196000 (  8.196000)

Also does not match my results:

Rehearsal ---------------------------------------------
1 thread    4.795000   0.000000   4.795000 (  4.739000)
2 threads   3.072000   0.000000   3.072000 (  3.072000)
------------------------------------ total: 7.867000sec

                user     system      total        real
1 thread    4.081000   0.000000   4.081000 (  4.081000)
2 threads   2.966000   0.000000   2.966000 (  2.966000)

I'd love to hear from others trying this benchmark, since the results
you've given don't match my results on any of the systems I'm testing.

- Charlie

[James M. Lawrence-2]

Charles Oliver Nutter:
> This does not match my results. Are you sure both cores are being used?

I am certain.  I tried to head off this question when I said: all
applications are closed save Terminal; top reports 0% CPU usage
beforehand; top reports java at 100% CPU during the 1-thread test;
185% CPU during the 2-thread test; top was not running during the
posted benchmarks.

I should also mention this is my mp3 player co-opted into a Mac dev
machine--a Mac Mini.  Maybe Java balks at the specs.  System Profiler:

  Model Name:  Mac mini
  Model Identifier:  Macmini2,1
  Processor Name:  Intel Core 2 Duo
  Processor Speed:  1.83 GHz
  Number Of Processors:  1
  Total Number Of Cores:  2
  L2 Cache:  2 MB
  Memory:  1 GB
  Bus Speed:  667 MHz

Darwin jl.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01
PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

It would be nice to match jruby versions.  Can you try master 55366a1
or push eaa9e7f to a remote branch?

[quoting the rest in full due to ruby-forum gateway breakage]

> Also does not match my results:
>
> Rehearsal ---------------------------------------------
> 1 thread    4.795000   0.000000   4.795000 (  4.739000)
> 2 threads   3.072000   0.000000   3.072000 (  3.072000)
> ------------------------------------ total: 7.867000sec
>
>                 user     system      total        real
> 1 thread    4.081000   0.000000   4.081000 (  4.081000)
> 2 threads   2.966000   0.000000   2.966000 (  2.966000)
>
> I'd love to hear from others trying this benchmark, since the results
> you've given don't match my results on any of the systems I'm testing.
>

--
Posted via http://www.ruby-forum.com/.