Bug #1560: multi core operations are slower on trunk (possible regression)

• Status: Rejected
• Assignee: -
• ruby -v: ruby 1.9.2dev (2009-06-01 trunk 23616) [i686-linux]

[dcu (David Cuadrado)]

=begin
following an article[1] I found that ruby 1.9.0(and 1.9.1) is faster than the trunk performing multi core operations, the benchmarks:

$ ruby1.9 -v
ruby 1.9.2dev (2009-06-01 trunk 23616) [i686-linux]
$ ruby1.9 multi-core.rb
Total number of insane floating point divisions in 15 seconds is 743108

$ ruby1.8 -v
ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux]
$ ruby1.8 multi-core.rb
Total number of insane floating point divisions in 15 seconds is 3156218

$ /usr/bin/ruby1.9 -v
ruby 1.9.0 (2008-06-20 revision 17482) [i486-linux]
$ /usr/bin/ruby1.9 multi-core.rb
Total number of insane floating point divisions in 15 seconds is 3952439

[1] http://letsgetdugg.com/2009/04/28/ruby-scaling-up-to-multiple-cpus/
[2] code: http://pastie.org/461592
=end

[rogerdpack (Roger Pack)]

=begin
interesting.

for me it's

ruby 1.9.1p376 (2009-12-07 revision 26041) [i386-mingw32]
Total number of insane floating point divisions in 10 seconds is 4_441_876

ruby 1.9.2dev (2010-01-25 trunk 26409) [i386-mingw32]
Total number of insane floating point divisions in 10 seconds is 1_556_498

so indeed much slower for 1.9.2 than 1.9.1...wonder why...

-r
=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:27872] [Bug #1560] multi core operations are slower on trunk (possible regression)"
on Wed, 27 Jan 2010 09:49:38 +0900, Roger Pack [e-mail] writes:

|ruby 1.9.1p376 (2009-12-07 revision 26041) [i386-mingw32]
| Total number of insane floating point divisions in 10 seconds is 4_441_876
|
|ruby 1.9.2dev (2010-01-25 trunk 26409) [i386-mingw32]
| Total number of insane floating point divisions in 10 seconds is 1_556_498
|
|so indeed much slower for 1.9.2 than 1.9.1...wonder why...

It's not caused by float operations, nor multi core support, but
caused by time calculation. We have relaxed time limitation in 1.9.2,
so that we would have 2038 problem no longer. But it is slower than
previous. Probably we need to tune up time routines.

						matz.

=end

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Rejected

=begin

=end

[rogerdpack (Roger Pack)]

=begin
I think it would be nice for this to be fixed before 1.9.2 is released.
Any objections to reopening this or should I open a new ticket?

$ time ~/installs/ruby_trunk_installed/bin/ruby -v floats.rb
ruby 1.9.2dev (2010-03-15 trunk 26942) [i686-linux]
Total number of insane floating point divisions in 10 seconds is 1_716_186

real 0m10.049s
$ time ruby -v floats.rb
ruby 1.9.1p243 (2009-07-16 revision 24175) [i686-linux]
Total number of insane floating point divisions in 10 seconds is 5_798_735

real 0m10.175s

This type of performance drop scares me.
Thanks!
-rp
=end

[mame (Yusuke Endoh)]

=begin
Hi,

I think it would be nice for this to be fixed before 1.9.2 is released.
Any objections to reopening this or should I open a new ticket?

Sorry for late response, but I object.

We should not call Time.new in busy loop if performance is needed.
In this case, you want to use timeout. It can run much faster
(about 15-20 times), even if you use 1.9.1:

+------------+----------+---------+
| | 1.9.1 | trunk |
+------------+----------+---------+
|original.rb | 3711882 | 3572907|
|timeout.rb | 59852485 | 76665074|
+------------+----------+---------+

timeout.rb

require 'thread'
require 'timeout'
threads = []
counter = 0
mutex = Mutex.new

4.times do
threads << Thread.new {
x=0
y=0
time=Time.new

   begin
     Timeout.timeout(10) do
       while true do
         x=1.00/24000000000.001
         y+=1
       end
     end
   rescue Timeout::Error
   end
   mutex.synchronize { counter+=y.to_i }
 }

end
threads.each { |t| t.join }

puts "Total number of insane floating point divisions in 10 seconds is "+counter.to_s

--
Yusuke Endoh [e-mail]
=end

[rogerdpack (Roger Pack)]

=begin

We should not call Time.new in busy loop if performance is needed.

Oh ok so the actual problem was that Time.new is slower now (which is expected, it appears?)

Ok.

I did note that it is currently "hard" for busy threads to be interrupted. Don't know if that is expected:

ex:

require 'timeout'
start = Time.now
threads = []
4.times {
threads <<Thread.new {
begin
Timeout.timeout(1) do
while true do
end
end
rescue Timeout::Error
end

  }}
  threads.each(&:join)

puts Time.now - start

(should output about 1.0, outputs about 1.2 with 1.9.1 and 1.9.3dev)

Is that worthy of a ticket?
If so let me know.
Thanks.
-rp
=end