0004897: ruby 18 on sparc poorly optimized

(0009598)
bwalton (administrator)
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 (reporter)
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 (reporter)
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 (administrator)
2012-02-14 01:33

No, it was built with sun pro. I ship rbconfig.rb for both compilers though.

(0009602)
phil (reporter)
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 (reporter)
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 (reporter)
2012-02-14 01:54

Ours uses libm.so.2

csw uses libm.so.1 .. AND libm.so.2 ??

(0009605)
bwalton (administrator)
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 (reporter)
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 (administrator)
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 (reporter)
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 (manager)
2016-03-07 14:26

was show stopper to promote to testing.
If still a problem create a new bug please

Notes
(0009598) bwalton (administrator) 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 (reporter) 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 (reporter) 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 (administrator) 2012-02-14 01:33	No, it was built with sun pro. I ship rbconfig.rb for both compilers though.

(0009602) phil (reporter) 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 (reporter) 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 (reporter) 2012-02-14 01:54	Ours uses libm.so.2 csw uses libm.so.1 .. AND libm.so.2 ??

(0009605) bwalton (administrator) 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 (reporter) 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 (administrator) 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 (reporter) 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 (manager) 2016-03-07 14:26	was show stopper to promote to testing. If still a problem create a new bug please

Relationships

OpenCSW Bug Tracker