Project

General

Profile

Bug #1560

multi core operations are slower on trunk (possible regression)

Added by dcu (David Cuadrado) almost 10 years ago. Updated about 8 years ago.

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

Description

=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

History

#1

Updated by rogerdpack (Roger Pack) over 9 years ago

=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

#2

Updated by matz (Yukihiro Matsumoto) over 9 years ago

=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 redmine@ruby-lang.org 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

#3

Updated by nobu (Nobuyoshi Nakada) over 9 years ago

  • Status changed from Open to Rejected

=begin

=end

#4

Updated by rogerdpack (Roger Pack) about 9 years ago

=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

#5

Updated by mame (Yusuke Endoh) about 9 years ago

=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 mame@tsg.ne.jp
=end

#6

Updated by rogerdpack (Roger Pack) about 9 years ago

=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

Also available in: Atom PDF