Re: MySQL on T2000

2014-01-31 Thread Patrick Baggett
I think you misunderstand the compiler option, which is fine, because it applies to Solaris. Because accessing unaligned memory raises a hardware error which forces a kernel context switch, you can mitigate the risk of this by assuming that any k-aligned object is actually only j-aligned, j < k, an

Re: MySQL on T2000

2014-01-31 Thread brian m. carlson
On Fri, Jan 31, 2014 at 03:50:37PM -0600, Patrick Baggett wrote: > Yes, it does [1], and so does Solaris using SunPro CC using -xmemalign [2] Okay, what's happening here is that someone is forcing the compiler to generate multiple aligned loads for pointers that are not properly aligned, so that a

Re: MySQL on T2000

2014-01-31 Thread Patrick Baggett
Yes, it does [1], and so does Solaris using SunPro CC using -xmemalign [2] [1] http://lists.freedesktop.org/archives/nouveau/2013-March/012435.html [2] https://blogs.oracle.com/d/entry/the_meaning_of_xmemalign On Fri, Jan 31, 2014 at 3:39 PM, brian m. carlson < sand...@crustytoothpaste.net> wr

Re: MySQL on T2000

2014-01-31 Thread brian m. carlson
On Thu, Jan 30, 2014 at 10:24:13PM +1100, Stewart Smith wrote: > What doesn't help is that unaligned memory accesses abound in the MySQL > server (I once switched the GCC flags for generating code to handle > unaligned access... urgh) It isn't clear to me what you mean by "handle unaligned access"

Re: MySQL on T2000

2014-01-31 Thread Stewart Smith
Chris Lawrence writes: > 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. MySQL query execution is single threaded (one query in one thread). The T20