Re: gnome2/x11 slow after optimization!

From: Joseph S. Atkinson <jsatkinson_at_embarqmail.com>
Date: Thu, 21 Aug 2008 15:50:12 -0400
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)
Received on Thu Aug 21 2008 - 18:09:50 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:34 UTC