Re: MySQL on T2000

Am 28.01.2014 18:17 schrieb "Patrick Baggett" <baggett.patrick@gmail.com>:

Well, if you get time (and have a recentish version of gcc), try:

CFLAGS = "-O2 -mcpu=niagra -mtune=niagra -flto"
CXXFLAGS = CFLAGS
LDFLAGS = "-flto"

I would try with gcc-4.8 or something.

You can always test to see if your CFLAGS are being completely ignored by adding "--break-my-build" or something that causes gcc to error out. Of course, this won't help if the command line looks like "-O2 -mcpu=niagra -mtune=niagra -flto -O0 -g", i.e. someone appends their own options that override yours. A lot of older benchmarks suggest that Sun/Oracle's C/C++ compiler produces the best code, but that may be moot now-a-days.

Patrick

On Tue, Jan 28, 2014 at 11:04 AM, Chris Lawrence <chris@nrsys.org> wrote:

The only CFLAGS set are '-mtune=niagara' (though I did make an attempt
adding -O3 just to see if a difference, there was not). Appears to
not be any LDFLAGS set either (CXXFLAGS is null as well).

I am only 60-70% sure I am gathering that information correctly
however (looking in the CMakeCache.txt file, and looking at
environment variables), I generally don't do a lot of compiling, at
least not in the past 8-10 years so I'm a bit rusty.

On Tue, Jan 28, 2014 at 10:58 AM, Patrick Baggett
<baggett.patrick@gmail.com> wrote:
> Chris, would you mind posting your C/CXXFLAGS and LDFLAGS?
>
> Patrick
>
>
> On Tue, Jan 28, 2014 at 10:55 AM, Chris Lawrence <chris@nrsys.org> wrote:
>>
>> Greetings:
>>
>> Based on some of the discussion so far in this thread
>> (which thank you all by the way for your input!) has led me down some
>> holes I was afraid to go down (building from source). I'm not averse
>> to it for technical reasons, just.. its a time consumer. :) In any case
>> I did run some tests on the box, building MySQL from source with a
>> variety of -mtune attempts (niagara, niagara2/3, etc), and
>> interestingly enough all of those attempts yielded a system that
>> actually was _slower_ than the 'stock' binaries distributed with
>> Debian SPARC (Wheezy).
>>
>> I am currently attempting a MariaDB build on the machine, but have
>> been running into some compile-time errors (I'm not very experienced
>> in porting to different architectures), as I was unable to find any
>> binaries of MariaDB (hoping its claims of faster/better would apply
>> here).
>>
>> I'll drop a reply if I ever get Maria built and see a difference.
>> Thanks again for all the input, much appreciated!
>>
>> Regards,
>>
>> Chris
>>
>> On Tue, Jan 28, 2014 at 4:19 AM, Rainer Herbst
>> <rainer.herbst@uni-potsdam.de> wrote:
>> > Single thread performance of the T2000 is definatly lower than of x86
>> > hardware, but a factor of 30 is to high. I would have expected factor
>> > 3-4,
>> > maybe 10.
>> >
>> > We use a T2000 for LDAP and MySQL server in Solaris 10 LDOMs, and the
>> > system
>> > perform reasonably well.
>> >
>> >
>> >
>> > Mit freundlichen Grüßen,
>> >
>> > Rainer Herbst
>> > Zentrale Einrichtung für Informations-
>> > verarbeitung und Kommunikation (ZEIK)
>> > Universität Potsdam
>> > Am Neuen Palais 10, Haus 8, Zimmer 0.70a
>> > 14469 Potsdam
>> > Tel. 0331 - 977 1039
>> >
>> >
>> > Quoting Patrick Baggett <baggett.patrick@gmail.com>:
>> >
>> >> Just from reading others' questions and answers over the web, I
>> >> wouldn't
>> >> be
>> >> surprised if that was the case, especially if you are doing anything
>> >> that
>> >> needs an FPU in there. Also IIRC, they are in-order CPUs, which means
>> >> having proper compiler flags will make a difference. Stock MySQL from
>> >> Debian probably doesn't have any special flags applied, whereas you'd
>> >> probably want "-mtune=niagara".
>> >>
>> >> I'm interested in finding out the answer as well -- I've considering
>> >> picking up a used T2-based, which has similar characteristics, since
>> >> they
>> >> are down to a few hundred dollars.
>> >>
>> >> Patrick
>> >>
>> >>
>> >>
>> >>
>> >> On Mon, Jan 27, 2014 at 1:35 PM, Chris Lawrence <chris@nrsys.org>
>> >> wrote:
>> >>
>> >>> Greetings:
>> >>>
>> >>> I have been gifted a Sun T2000 from my employer as a hand-me-down
>> >>> piece of hardware. I have had plenty of experience using it as a
>> >>> Solaris 10 box, and we generally ran Oracle and our in-house products
>> >>> on the hardware with good results.
>> >>>
>> >>> After getting the hardware, without a Sun contract I went with Debian,
>> >>> which was fine as my expertise/background is more heavily Linux than
>> >>> Solaris anyways.
>> >>>
>> >>> After a lot of tinkering I got the system as I liked it, prepared to
>> >>> host several LXC containers, separated as database and web servers for
>> >>> a project for my friend's gaming website. All went well, until I
>> >>> started working with MySQL. I started noticing significant
>> >>> differences in performance, and, I went down the rabbit hole to find
>> >>> plenty of articles talking about how MySQL doesn't run well on The
>> >>> T2000's due to single threadedness sort of reasons.
>> >>>
>> >>> I've done a good amount of fine tuning of the database, but I'm
>> >>> finding any query of complexity taking sometimes as much as 30x longer
>> >>> to execute than on same-era x86 hardware running Debian.
>> >>>
>> >>> I am really just trying to figure out if I'm wasting my time by trying
>> >>> to 'fix' this, or if its a reality of the hardware platform. Even
>> >>> simple 'select BENCHMARK' queries are returning back after 25-30
>> >>> seconds, whereas on the x86 box it comes back in 1-2 seconds.
>> >>>
>> >>> Is MySQL on this hardware platform a lost cause, or am I missing
>> >>> something obvious?
>> >>>
>> >>> Thanks in advance!
>> >>>
>> >>> Regards,
>> >>>
>> >>> Chris
>> >>>
>> >>>
>> >>> --
>> >>> To UNSUBSCRIBE, email to debian-sparc-REQUEST@lists.debian.org
>> >>> with a subject of "unsubscribe". Trouble? Contact
>> >>> listmaster@lists.debian.org
>> >>> Archive:
>> >>>
>> >>>
>> >>> [🔎] CAOUEZgJVmYJpMpOWTpJvaFmPY0unEExT3PcTWXypaNapDLVHjA@mail.gmail.com" target="_blank">http://lists.debian.org/[🔎] CAOUEZgJVmYJpMpOWTpJvaFmPY0unEExT3PcTWXypaNapDLVHjA@mail.gmail.com
>> >>>
>> >>>
>> >>
>> >
>> >
>>
>>
>> --
>> To UNSUBSCRIBE, email to debian-sparc-REQUEST@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact
>> listmaster@lists.debian.org
>> Archive:
>> [🔎] CAOUEZgKKvFeo_6wOCjhmTwt0NoTs3hhq-BPJKdzmVFMvQtgwtA@mail.gmail.com" target="_blank">http://lists.debian.org/[🔎] CAOUEZgKKvFeo_6wOCjhmTwt0NoTs3hhq-BPJKdzmVFMvQtgwtA@mail.gmail.com
>>
>