Ruby on Solaris 10 performance problems

Discussion in 'Ruby' started by Colin Mackenzie, Jan 28, 2009.

  1. We just installed ruby on a
    Sun T1000, 6 core UltraSPARC T1 cpu, 4G memory , Solaris 10

    Right now Windows is out performing an Ultra SPARC by 25 seconds! Does
    anyone know why this would be the case. I have downloaded ruby and
    compiled it on the hardware, i have tried the binaries from sunfreeware
    and the results are the same. Actually, the results from my compile were
    a second or two worse than the binaries from SUN!


    This is the program ran for the bench mark. I called it t.rb

    require 'benchmark'

    array = (1..1000000).map { rand }

    Benchmark.bmbm do |x|
    x.report("sort!") { array.dup.sort! } #this sorts the array.
    x.report("sort") { array.dup.sort } #this makes a copy of the
    array and sorts it.
    end


    ###########################################

    Solaris v10
    # ruby t.rb
    Rehearsal -----------------------------------------
    sort! 29.450000 0.020000 29.470000 ( 29.458899)
    sort 29.760000 0.010000 29.770000 ( 29.772163)
    ------------------------------- total: 59.240000 sec

    user system total real
    sort! 29.060000 0.010000 29.070000 ( 29.064410)
    sort 29.070000 0.000000 29.070000 ( 29.076217)
    #

    Windows

    Microsoft Windows XP [Version 5.1.2600]
    (C) Copyright 1985-2001 Microsoft Corp.

    C:\Documents and Settings\cmackenzie>ruby t.rb
    Rehearsal -----------------------------------------
    sort! 4.735000 0.000000 4.735000 ( 4.813000)
    sort 4.359000 0.000000 4.359000 ( 4.390000)
    -------------------------------- total: 9.094000 sec
    user system total real
    sort! 4.313000 0.000000 4.313000 ( 4.375000)
    sort 4.297000 0.015000 4.312000 ( 4.422000)

    C:\Documents and Settings\cmackenzie>

    Ubuntu Linux

    colmac@sideshowbob: ruby t.rb
    Rehearsal -----------------------------------------
    sort! 3.310000 0.010000 3.320000 ( 3.317860)
    sort 3.250000 0.020000 3.270000 ( 3.270037)
    -------------------------------- total: 6.5890000 sec

    user system total real
    sort! 3.280000 0.030000 3.10000 ( 3.318575)
    sort 3.250000 0.020000 3.270000 ( 3.269284)
    colmac@sideshowbob:
    --
    Posted via http://www.ruby-forum.com/.
    Colin Mackenzie, Jan 28, 2009
    #1
    1. Advertising

  2. On Jan 28, 12:36=A0pm, Colin Mackenzie <> wrote:
    > We just installed ruby on a
    > Sun T1000, 6 core UltraSPARC T1 cpu, 4G memory =A0, Solaris 10
    >
    > Right now Windows is out performing an Ultra SPARC by 25 seconds! Does
    > anyone know why this would be the case.


    <snip>

    What version of Ruby?
    Which compiler?
    What flags did you build with?
    Have you seen http://tinyurl.com/dln99p ?

    Regards,

    Dan
    Daniel Berger, Jan 28, 2009
    #2
    1. Advertising


  3. > What version of Ruby?

    ruby 1.8.7 (2008-08-11 patchlevel 72) [sparc-solaris2.10]

    > Which compiler?

    gcc (GCC) 3.4.6

    > What flags did you build with?

    I ran configure , what ever default flags it used.

    > Have you seen http://tinyurl.com/dln99p ?

    no I will check it out.

    # uname -a
    SunOS tk3 5.10 Generic_137137-09 sun4v sparc SUNW,Sun-Fire-T1000

    btw, downloaded binaries from blastwave.org and the results are even
    worse..
    #./ruby --version
    ruby 1.8.7 (2008-06-20 patchlevel 22) [sparc-solaris2.8]uname
    # ./ruby t.rb
    Rehearsal -----------------------------------------
    sort! 34.080000 0.020000 34.100000 ( 34.098341)
    sort 33.430000 0.010000 33.440000 ( 33.443781)
    ------------------------------- total: 67.540000sec
    --
    Posted via http://www.ruby-forum.com/.
    Colin Mackenzie, Jan 29, 2009
    #3
  4. 2009/1/28 Colin Mackenzie <>:
    > We just installed ruby on a
    > Sun T1000, 6 core UltraSPARC T1 cpu, 4G memory , Solaris 10
    >
    > Right now Windows is out performing an Ultra SPARC by 25 seconds! Does
    > anyone know why this would be the case.


    SPARC processors are slow, raw CPU speed is not among the strengths of
    those beasts - especially since Ruby does not use native threads.
    You're putting the load on a single core only (well, your test does
    not contain any concurrency anyway :) ).

    It's pretty easy to see why: RISC has fewer machine instructions which
    take one clock to execute. Nowadays CISC processors come close to
    taking one clock as well by using pipelining, branch prediction and
    what not. But CISC processor commands are more powerful, so you need
    multiple RISC commands to do the same amount of work. And since clock
    speeds slowly reach physical limits RISC cannot compensate with higher
    clock rates. That's why RISK is falling behind. IMHO it's a dead
    technology.

    Kind regards

    robert

    --
    remember.guy do |as, often| as.you_can - without end
    Robert Klemme, Jan 29, 2009
    #4
  5. Robert Klemme wrote:
    ...snip... IMHO it's a dead technology.

    Thanks, Robert, I had a bad feeling about that.

    --
    Posted via http://www.ruby-forum.com/.
    Colin Mackenzie, Jan 29, 2009
    #5
  6. 2009/1/29 Colin Mackenzie <>:
    > Robert Klemme wrote:
    > ...snip... IMHO it's a dead technology.
    >
    > Thanks, Robert, I had a bad feeling about that.


    :)

    I don't say that Sparc machines or Solaris operating systems do not
    have their merits. It's just that raw CPU speed is not among them.

    Cheers

    robert

    --
    remember.guy do |as, often| as.you_can - without end
    Robert Klemme, Jan 29, 2009
    #6
  7. Colin Mackenzie

    Mark Thomas Guest

    On Jan 28, 2:36 pm, Colin Mackenzie <> wrote:
    > We just installed ruby on a
    > Sun T1000, 6 core UltraSPARC T1 cpu, 4G memory  , Solaris 10
    >
    > Right now Windows is out performing an Ultra SPARC by 25 seconds! Does
    > anyone know why this would be the case. I have downloaded ruby and
    > compiled it on the hardware, i have tried the binaries from sunfreeware
    > and the results are the same. Actually, the results from my compile were
    > a second or two worse than the binaries from SUN!


    I wonder what kind of performance you'd get if you used JRuby 1.1.6+
    Mark Thomas, Jan 29, 2009
    #7
  8. * Colin Mackenzie <> (2009-01-28) schrieb:

    What machine are

    > Microsoft Windows XP [Version 5.1.2600]


    and

    > Ubuntu Linux


    running on?

    mfg, simon .... l
    Simon Krahnke, Jan 30, 2009
    #8
  9. Mark Thomas wrote:
    > On Jan 28, 2:36�pm, Colin Mackenzie <> wrote:
    >> We just installed ruby on a
    >> Sun T1000, 6 core UltraSPARC T1 cpu, 4G memory �, Solaris 10
    >>
    >> Right now Windows is out performing an Ultra SPARC by 25 seconds! Does
    >> anyone know why this would be the case. I have downloaded ruby and
    >> compiled it on the hardware, i have tried the binaries from sunfreeware
    >> and the results are the same. Actually, the results from my compile were
    >> a second or two worse than the binaries from SUN!

    >
    > I wonder what kind of performance you'd get if you used JRuby 1.1.6+


    java runs 7 times slower on this RISC platform, just going to drop it.
    Every thing runs slow
    --
    Posted via http://www.ruby-forum.com/.
    Colin Mackenzie, Jan 30, 2009
    #9
  10. Simon Krahnke wrote:
    > * Colin Mackenzie <> (2009-01-28) schrieb:
    >
    > What machine are
    >
    >> Microsoft Windows XP [Version 5.1.2600]

    >
    > and
    >
    >> Ubuntu Linux

    >
    > running on?
    >
    > mfg, simon .... l


    at this point it does not matter. really the only question was why it is
    running so slow on Solaris platform. Robert gave me the answer. Thanks
    though.
    If you are interested
    Ubuntu is on an intel E4500@2.2GHz
    Windows is on a Dell LapTop D630
    --
    Posted via http://www.ruby-forum.com/.
    Colin Mackenzie, Jan 30, 2009
    #10
  11. Colin Mackenzie

    Peter Booth Guest

    [Note: parts of this message were removed to make it a legal post.]


    Colin,

    You have an answer, but it isn't the right answer.

    An Ultrasparc T1 processor is a little more powerful than either of
    the Core 2 Duo CPUs you tested. You can see this from the published
    results for the SPECjbb2005 or the specweb benchmarks.

    The confusion when using your application as a benchmark, you only
    make use of 5% of the CPU resources of the Sun box. The T1 processor
    only runs at a clock speed of 1GHz but, being both multithreaded and
    multi-core, it gives you a total of 24 threads to push work through.
    If you used a benchmark that ran 24 or more instances of your
    application you could expect to see greater throughput from the Sun
    host than the Intel hosts.

    This is a great example of the "End of Moore's Law" issue. We are at
    the cusp of a change in hardware technology that could force all
    developers to learn about concurrency and parallelizing workloads. The
    difference between these two architectures is that Sun embraced the
    issue a little earlier than Intel.

    I agree with Robert that RISC has had its day in the sun (pun not
    intended), but I disagree with the suggestion that this is due to
    technical inferiority. The reality is that Sun sat pretty earning
    great margins for their hardware for more than a decade. No longer
    commercially relevant its ironic that they are now, perhaps for the
    first time, competitive on a performance vs price basis. But it's too
    lae. It doesn't matter that Solaris on a Sun server is, in some ways,
    technically superior to a Linux on Intel platform.

    I would never choose Solaris today because it would be like buying a
    Beta VCR, or a NeXT cube in the 1980s. Its sad that a company
    responsible for so many technical innovations isn't succeeding
    economically but that's life. Linux on Intel is the safe corporate
    choice today. Funny to remember that installing Slackware on a 386 in
    1996 made me feel like a revolutionary.

    Peter

    On Jan 29, 2009, at 8:21 PM, Colin Mackenzie wrote:

    > Simon Krahnke wrote:
    >> * Colin Mackenzie <> (2009-01-28) schrieb:
    >>
    >> What machine are
    >>
    >>> Microsoft Windows XP [Version 5.1.2600]

    >>
    >> and
    >>
    >>> Ubuntu Linux

    >>
    >> running on?
    >>
    >> mfg, simon .... l

    >
    > at this point it does not matter. really the only question was why
    > it is
    > running so slow on Solaris platform. Robert gave me the answer. Thanks
    > though.
    > If you are interested
    > Ubuntu is on an intel E4500@2.2GHz
    > Windows is on a Dell LapTop D630
    > --
    > Posted via http://www.ruby-forum.com/.
    >
    Peter Booth, Jan 30, 2009
    #11
  12. Robert Klemme wrote:
    CISC processor commands are more powerful, so you need
    > multiple RISC commands to do the same amount of work.


    The original logic for RISC is it was better to use real estate for
    registers than rarely used instructions. However with the relentless
    march of Moore's law we've not only got to where you can have ocean of
    registers on an X86 chip; you can now have several more complete cores
    on the same die!

    That said, we note Solaris was acutually running on X86 so its' an OS
    thing.
    --
    Posted via http://www.ruby-forum.com/.
    Mike Stephens, Jan 30, 2009
    #12
  13. 2009/1/30 Peter Booth <>:

    > You have an answer, but it isn't the right answer.


    I am not sure I understand what you mean by that since you seem to
    rather reconfirm what I wrote:

    > An Ultrasparc T1 processor is a little more powerful than either of the
    > Core 2 Duo CPUs you tested. You can see this from the published results for
    > the SPECjbb2005 or the specweb benchmarks.


    Colin was not interested to learn how much potential a SPARC CPU has
    but he wanted to know why his SPARC was outperformed by an Intel box.

    > The confusion when using your application as a benchmark, you only make use
    > of 5% of the CPU resources of the Sun box. The T1 processor only runs at a
    > clock speed of 1GHz but, being both multithreaded and multi-core, it gives
    > you a total of 24 threads to push work through. If you used a benchmark that
    > ran 24 or more instances of your application you could expect to see
    > greater throughput from the Sun host than the Intel hosts.


    As I said, there was just a single thread in the benchmark and this is
    where SPARC processors fail miserably.

    > This is a great example of the "End of Moore's Law" issue. We are at the
    > cusp of a change in hardware technology that could force all developers to
    > learn about concurrency and parallelizing workloads. The difference between
    > these two architectures is that Sun embraced the issue a little earlier than
    > Intel.


    Frankly, I am not too optimistic that concurrency will be ubiquitous
    soon. There are several reasons for this: judging from what I read in
    public forums the concept seems to be difficult to grasp for many
    people. Especially testing a multithreaded application is
    significantly more complex than testing a single threaded application.
    And, lastly, there is a vast amount of software that does exist
    already and scarcely uses multithreading; in other words, efforts to
    convert this are very high.

    Side note: when I was at the university I picked a lecture about
    communication in parallel computational models because at that time my
    university (Paderborn, Germany) had one of the largest multiprocessor
    systems around and was recognized as strong in that area. I did not
    follow that path further on because it was easy to see that the theory
    was still immature, Big-O calculus had large constants (i.e. algorithm
    would be faster from a few million CPUs on) and network topologies had
    to be tailored to the algorithm.

    > I agree with Robert that RISC has had its day in the sun (pun not intended),
    > but I disagree with the suggestion that this is due to technical
    > inferiority. The reality is that Sun sat pretty earning great margins for
    > their hardware for more than a decade. No longer commercially relevant its
    > ironic that they are now, perhaps for the first time, competitive on a
    > performance vs price basis. But it's too lae. It doesn't matter that Solaris
    > on a Sun server is, in some ways, technically superior to a Linux on Intel
    > platform.


    IMHO Sun's good position is not attributed to fast CPU speeds but
    rather features that make Solaris systems good server systems:
    reliability, fault tolerance, IO performance etc. I guess in practice
    most applications that need to scale to large amounts of users require
    large IO bandwidth rather than CPU power (just think of typical web
    applications like online shops).

    > I would never choose Solaris today because it would be like buying a Beta
    > VCR, or a NeXT cube in the 1980s.


    Now you're getting more pessimistic about it than me. :)

    > Its sad that a company responsible for so
    > many technical innovations isn't succeeding economically but that's life.
    > Linux on Intel is the safe corporate choice today. Funny to remember that
    > installing Slackware on a 386 in 1996 made me feel like a revolutionary.


    Oh yes, I also remember those days when I copied Slackware on 50+
    floppy disks and installed it at home on my 386. Those are the days
    where the phrase about the largest text adventure application
    originated. :)

    Kind regards

    robert

    --
    remember.guy do |as, often| as.you_can - without end
    Robert Klemme, Jan 30, 2009
    #13
  14. Thanks Peter and Robert for all your insights about his subject. This
    whole thing came to light when I took one of our web based applications
    which is a Terminal management System and was going to port it to
    Solaris system which happen to be a RISC platform. It was originally
    written on a Ubuntu platform using an intel CPU and was going to be
    ported to Red Hat Linux Enterprise on a Dell Blade system. Then
    management changed and wanted it on Solaris. Long story there. When we
    finally got it running it was discovered it took 5 seconds to load a
    simple login page! It is a Ruby on Rails application and I found it was
    during a simple request to a controller to build a very simple page. The
    process used arrays to do "certain" things during the process of
    building the page. Hence, my simple ruby program to test. I simply cant
    see any reason to re-architect the application so it will run on a RISC
    platform. So in the end I am going to push for the original plan and put
    this on a blade system of some type. Thanks again and yeah I am old
    enough to remember those 50 floppies of Slackware except I was a
    Yggdrasil fan :)

    --
    Posted via http://www.ruby-forum.com/.
    Colin Mackenzie, Jan 30, 2009
    #14
  15. 2009/1/30 Colin Mackenzie <>:
    > Thanks Peter and Robert for all your insights about his subject. This
    > whole thing came to light when I took one of our web based applications
    > which is a Terminal management System and was going to port it to
    > Solaris system which happen to be a RISC platform. It was originally
    > written on a Ubuntu platform using an intel CPU and was going to be
    > ported to Red Hat Linux Enterprise on a Dell Blade system. Then
    > management changed and wanted it on Solaris. Long story there. When we
    > finally got it running it was discovered it took 5 seconds to load a
    > simple login page!


    That sounds extremely long. I'd dig into that issue. Do you have
    database indexes in place etc.? I also believe that Rails has some
    options that you can switch off because they are convenient during
    development but slow down production.

    > It is a Ruby on Rails application and I found it was
    > during a simple request to a controller to build a very simple page. The
    > process used arrays to do "certain" things during the process of
    > building the page.


    Talk about vague information... :)

    > Hence, my simple ruby program to test. I simply cant
    > see any reason to re-architect the application so it will run on a RISC
    > platform. So in the end I am going to push for the original plan and put
    > this on a blade system of some type. Thanks again and yeah I am old
    > enough to remember those 50 floppies of Slackware except I was a
    > Yggdrasil fan :)


    You either have a configuration issue or your app is slower than
    necessary on *any* platform. I'd say if you want scalability from this
    I would dig into the performance issue.

    Cheers

    robert


    --
    remember.guy do |as, often| as.you_can - without end
    Robert Klemme, Jan 30, 2009
    #15
  16. Colin Mackenzie wrote:
    > java runs 7 times slower on this RISC platform, just going to drop it.
    > Every thing runs slow


    7 times slower than what? Non-RISC?

    At least with JRuby you could parallelize easily in the same script,
    Even the fastest SPARCs are nowhere near the clock speed of typical x86
    chips, but they're smaller, use less power, and you can fit dozens of
    them in a machine.

    - Charlie
    Charles Oliver Nutter, Jan 30, 2009
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. krigare
    Replies:
    0
    Views:
    828
    krigare
    Dec 27, 2003
  2. thomhashi
    Replies:
    2
    Views:
    800
    Nils O. =?iso-8859-1?Q?Sel=E5sdal?=
    Oct 31, 2003
  3. Hf
    Replies:
    0
    Views:
    507
  4. bugbear
    Replies:
    4
    Views:
    2,888
    Arne Vajhøj
    Mar 28, 2008
  5. inaf
    Replies:
    10
    Views:
    1,058
    Antoine Pitrou
    Oct 17, 2009
Loading...

Share This Page