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 <[email protected]> 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 > <[email protected]> wrote: > > Chris, would you mind posting your C/CXXFLAGS and LDFLAGS? > > > > Patrick > > > > > > On Tue, Jan 28, 2014 at 10:55 AM, Chris Lawrence <[email protected]> > 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 > >> <[email protected]> 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 <[email protected]>: > >> > > >> >> 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 <[email protected]> > >> >> 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 [email protected] > >> >>> with a subject of "unsubscribe". Trouble? Contact > >> >>> [email protected] > >> >>> Archive: > >> >>> > >> >>> > >> >>> > http://lists.debian.org/caouezgjvmyjpmpowtpjvafmpy0uneext3pctwxypanapdlv...@mail.gmail.com > >> >>> > >> >>> > >> >> > >> > > >> > > >> > >> > >> -- > >> To UNSUBSCRIBE, email to [email protected] > >> with a subject of "unsubscribe". Trouble? Contact > >> [email protected] > >> Archive: > >> > http://lists.debian.org/caouezgkkvfeo_6wocjhmtwt0nots3hhq-bpjkdzmvfmvqtg...@mail.gmail.com > >> > > >
