gnome2/x11 slow after optimization!
Joseph S. Atkinson
jsatkinson at embarqmail.com
Thu Aug 21 20:09:50 UTC 2008
On Thu, Aug 21, 2008 at 08:03:27PM +0200, Kris Kennaway wrote:
> Rohit Tripathi wrote:
>> I have a core2duo laptop on which out of curiosity I decided to
>> recompile x11 and gnome2. After a few hours when it was ready, I found
>> gnome crawling painfully slow. I'd click a menu and it'll take 2
>> seconds to appear, I try running terminal, and it take 10 seconds to
>> come up, try typing and keyboard lags by 5-6 seconds.....what I find
>> is really cool is that the ports installed by FreeBSD release are
>> waaaay faster....here's my make.conf: (do you see a culprit?)
>> ARCH=core2 #nocona
>> MACHINE=core2 #nocona
>> MACHINE_ARCH=core2 #nocona
>> CFLAGS= -O3 -pipe -mtune=core2 -m128bit-long-double -mfpmath=sse
>> -ftree-vectorize
>> CXXFLAGS+= -fconserve-space
>> COPTFLAGS = -O -pipe -mtune=core2 -m128bit-long-double
> -mfpmath=sse
>
> Revert all this rampant craziness, you broke something.
CPUTYPE sets -march=, which is also an implicit -mtune=. The purpose of
-march= is largely to tell gcc what cpu features are available so that
it doesn't do things like scheduling and sse3 on platforms that can't
support it. Of course, this means nothing at all unless you also tell
gcc to use those features with -msse3 and the like.
There are places where such features are not desired and CPUTYPE is
overridden when allowed (CPUTYPE?=), but otherwise just breaks stuff
when forced (CUPTYPE=).
Another clue, is that -Werror is normally set for a reason. Reverting
this may reveal some breakage.
I would personally suggest scrapping all of it, setting nothing more
'CPUTYPE?=native' to start ("core2" doesn't appear to be a valid value
for gcc 4.2.1), adding optimizations a little at a time while reading
the gcc manual at every step. This way you can easily find what broke it.
Try stating with the gcc manual page here:
http://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc/i386-and-x86_002d64-Options.html
Finally, I will give the standard disclaimer that it's probably not wise
to use any optimization at all, since even if it seems to work, there
can be subtle breakage that isn't immediately traceable. (Google for
firefox with ffast-math for an example)
More information about the freebsd-current
mailing list