Mantis - ruby18
Viewing Issue Advanced Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4897 regular use major always 2012-02-13 20:49 2016-03-07 14:26
Reporter: phil Platform:  
Assigned To: jh OS:  
Priority: normal OS Version:  
Status: closed Product Version:  
Product Build: Resolution: suspended  
Projection: none      
ETA: none Fixed in Version:  
Summary: 0004897: ruby 18 on sparc poorly optimized
Description: On the same sparc machine, on solaris 10, running the same test
(http://www.thebuzzmedia.com/ruby-19-quick-speed-test/) [^]
takes 3 times as long as a locally compiled ruby.
Steps To Reproduce:
Additional Information: $ /opt/csw/bin/ruby --version
ruby 1.8.7 (2011-02-18 patchlevel 334) [sparc-solaris2.9]
$ /opt/csw/bin/ruby /tmp/speed.ruby 26
starting fibonacci
196418
Finding the fib of 26 took:
3.652563
seconds

$ /usr/local/bin/ruby --version
ruby 1.8.7 (2010-01-10 patchlevel 249) [sparc-solaris2.10]
$ /usr/local/bin/ruby /tmp/speed.ruby 26
starting fibonacci
196418
Finding the fib of 26 took:
1.07942
seconds
Relationships
Attached Files:
Issue History
Date Modified Username Field Change
2012-02-13 20:49 phil New Issue
2012-02-13 21:43 bwalton Note Added: 0009598
2012-02-13 21:43 bwalton Assigned To => bwalton
2012-02-13 21:43 bwalton Status new => feedback
2012-02-13 22:00 phil Note Added: 0009599
2012-02-13 22:04 phil Note Added: 0009600
2012-02-14 01:33 bwalton Note Added: 0009601
2012-02-14 01:48 phil Note Added: 0009602
2012-02-14 01:50 phil Note Added: 0009603
2012-02-14 01:52 phil Note Edited: 0009603
2012-02-14 01:54 phil Note Added: 0009604
2012-02-14 01:59 bwalton Note Added: 0009605
2012-02-14 02:55 phil Note Added: 0009606
2012-02-14 15:58 bwalton Note Added: 0009607
2012-02-14 16:30 phil Note Added: 0009608
2016-03-07 14:25 jh Status feedback => assigned
2016-03-07 14:25 jh Assigned To bwalton => jh
2016-03-07 14:26 jh Note Added: 0011102
2016-03-07 14:26 jh Status assigned => closed
2016-03-07 14:26 jh Resolution open => suspended

Notes
(0009598)
bwalton   
2012-02-13 21:43   
Hi Phil,

If you supplied your rbconfig.rb and/or the build flags you used, that would help. I can update the package to provide better optimization.

Thanks
-Ben
(0009599)
phil   
2012-02-13 22:00   
For security reasons, I cannot upload the raw data.
However, parsing out that part, there's not much special, looking at rbconfig.rb

  CONFIG["configure_args"] = " ' ... 'CC=cc' 'CFLAGS=-xnorunpath -xO2'"

I believe it was compiled with sunpro 12.0

So, I suppose the basic performance flaw of csw ruby sparc , is simply that it was compiled with gcc instead of sunpro cc
(0009600)
phil   
2012-02-13 22:04   
For what it's worth: ruby x86 is even worse. A factor of 4.

8+ second for csw ruby, vs 1.9 seconds for local.

(i used argument of 30, rather than 26, to compare that one, given the faster cpus)
(0009601)
bwalton   
2012-02-14 01:33   
No, it was built with sun pro. I ship rbconfig.rb for both compilers though.
(0009602)
phil   
2012-02-14 01:48   
oh. well, the default deploy is for gcc, anyways.

I guess the only difference I see on my side looking at configs, etc. is v8 vs v8plus.

But that doesnt explain the x86 performance difference.

then again...
-xarch=386 (and SOS11)

vs just regular xO2.. and SOS12?
But both x86 executables are type
ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked
(0009603)
phil   
2012-02-14 01:50   
(edited on: 2012-02-14 01:52)
csw ruby, according to ldd, loads in libruby.so

our local ruby does not.

nor does ours load in libpthread.so.1
(0009604)
phil   
2012-02-14 01:54   
Ours uses libm.so.2

csw uses libm.so.1 .. AND libm.so.2 ??
(0009605)
bwalton   
2012-02-14 01:59   
Looks like libm.so.1 pulls in libm.so.2:

   object=/lib/libm.so.1; filter for libm.so.2

   find object=libm.so.2; required by /lib/libm.so.1
    search path=/lib:/usr/lib (configuration default - /var/ld/ld.config)
    trying path=/lib/libm.so.2
        libm.so.2 => /lib/libm.so.2

I'm going to rebuild with O2 and sos12. We'll see if that speeds things up.

Not sure if your gcc deploy comment is indicating that you're locally targetting gcc or that the default rbconfig.rb targets gcc. The intent of the package is to target sunpro unless ruby18_gcc is installed. If that package is installed, the alternative for rbconfig.rb.gcc4 is of higher precedence than .sos as people that install that package most likely want to build gems without sos.
(0009606)
phil   
2012-02-14 02:55   
The default csw rbconfig.rb is for gcc.
It turns out that CSWruby18_gcc IS installed. though I have no idea why.

I decided to test out on an older sparc cpu.
running solaris 9.

Umm.. wow.

csw: 13 sec
local: 2 sec.

cpu type UltraAX-i2

This is an executable specifically compiled on sol9 though.
ruby --version
ruby 1.8.7 (2010-01-10 patchlevel 249) [sparc-solaris2.9]
again, no libruby.so.
But this one is just libm.so.1. Not surprising, i think only sol10 triggers libm.so.2 ?
But also may have been compiled with sos11. cant be sure.

My prior results tests was compiled on sol10, running on 10.
(0009607)
bwalton   
2012-02-14 15:58   
Are you sure it's loading libruby.so or is it getting libruby18.so? It should be linked against libruby18.so and that's what I see on my systems. There is a libruby.so, but that was left in place in the event people had built local gems against it after switching to suffixed file names. See CSWlibruby1 vs CSWlibruby18-1.

I still expect to find that the optimization flags are the real slowdown here, but it's good to know that we're not chasing a different problem.
(0009608)
phil   
2012-02-14 16:30   
yes libruby18 i was typing shorthand.
I'm thinking maybe the pthread is an issue as well. I seem to remember that php was slower when linked with pthread, at one time in its existence. or maybe it was perl.
or both.
(0011102)
jh   
2016-03-07 14:26   
was show stopper to promote to testing.
If still a problem create a new bug please