有沒有人要試試?好像滿有趣的...There are a few hitches. I think that profiling info can only - on the compiler side - be used on essentaly one ebuild with one set of CFLAGS and one set of relevant USE flags.
Could be very interesting ... what do you think?
CFLAGS Central
Moderator: Forums Team
-
coollinuxer
- Posts: 109
- Joined: Sun Mar 16, 2003 4:42 pm
- Contact:
CFLAGS Central
http://forums.gentoo.org/viewtopic.php?t=5717&start=375
Open,Based on Free!
Free,Powerd by Opening!
Free,Powerd by Opening!
-
swallowman
- Posts: 138
- Joined: Sat Apr 05, 2003 12:04 am
- Location: taichung
- Contact:
CFLAGS="-O3 -mcpu=athlon-xp -march=athlon-xp -m3dnow -msse -mfpmath=sse -mmmx -pipe -fforce-addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4"
我ㄉ CFLAGS 這樣應該還好吧.
我總覺得使用 -maccumulate-outgoing-args 反而會讓系統 lag = = 會停格停格這樣.
我ㄉ CFLAGS 這樣應該還好吧.
我總覺得使用 -maccumulate-outgoing-args 反而會讓系統 lag = = 會停格停格這樣.
「從麻雀之城回來的時候,被問到『你要大的藤箱還是小的藤箱?』為此煩惱不已。大家都有過這種煩惱吧?」
「是啊是啊!大的藤箱可以放很多東西覺得很划算,小的藤箱小小的裡面也許放著很不錯的東西,真的很難取捨阿!」
「靠這個就能告別這種煩惱『中型的藤箱』!」
「好厲害!」
「不要再煩惱大小的問題了,現在還贈送可以煮出鐵質,增進健康的鐵銼刀。」
「這是一定要買的!」
「我要一個!」
「是啊是啊!大的藤箱可以放很多東西覺得很划算,小的藤箱小小的裡面也許放著很不錯的東西,真的很難取捨阿!」
「靠這個就能告別這種煩惱『中型的藤箱』!」
「好厲害!」
「不要再煩惱大小的問題了,現在還贈送可以煮出鐵質,增進健康的鐵銼刀。」
「這是一定要買的!」
「我要一個!」
-
coollinuxer
- Posts: 109
- Joined: Sun Mar 16, 2003 4:42 pm
- Contact:
http://forums.gentoo.org/viewtopic.php?t=5717&start=375
上面有人說
上面有人說
Though maybe you should have tried -O2 with -finline-functions, and so not use the -frename-registers of -O3, which I've been told is not so good on machines with not many registers, as is the x86 architecture.
Big difference is however that the mozilla ebuild does not want the optimizations, I had to tweak the ebuid, and mozilla still ran fine, but faster now
-O3 only adds two extra options (-finline-functions and -frename-registers) compared to -O2. The following article is worth looking add if you are interested in seeing what each -O value does:
http://freshmeat.net/articles/view/730/
The cause of huge binaries using -O3 is -finline-functions in particular though
-O2 : It enables all -O3 optimizations except inline-functions (which I included later) and rename-registers. rename-registers is only good for architectures with a lot of registers: the x86 isn't one of these. -Os would be good if the Athlon didn't have so much L1 cache.
-finline-functions : The Athlon has 64Kb of L1 code cache - use it! (Well ... AMD recomends function inlining).
-falign-jumps=5 -falign-loops=5 -falign-functions=64: The Athlon's cache lines are 64 bytes wide. This makes sure that you will always have these at the start of a cache line. Since it (I believe) is going to fetch the whole line anyway, might as well get the most bang for your buck (and you're also easing pressure on memory and getting good cache usage) - in addition, you don't want a loop starting on a line boundary each time it executes as I beleive there is a decoding penalty for this.
-funroll-loops : Again 64kb L1 code cache. AMD recomends unrolling loops of a sane size, so this should do just that.
-mfpmath=sse : faster math with floats. Athlons can interleave execution of x87 / MMX / SSE code, so this might help you get better utilization of your FP units.
-mmmx -msse -m3dnow : No reason not to .... these just let people use MMX / SSE / 3DNow wrappers in gcc.
I haven't had any problems so far except for 'top' displayng incorrect numbers on startup (this goes away after the first polling). GIMP is noticibly faster than with RedHat.
[/code](I should know 64=2^6 not 2^5 ... doh!)
After talking with some other people about this, The alignments should be this instead:
-falign-jumps=4
-falign-loops=4
Aligning these to 64 byte bonderies should help you get longer bursts from memory ... and thus decrese code loading time the first time ... however, after about 25-50 loop iterations, this would be a moot point anyway, since the code would be in cache - and what realy matter are the loops that execute many thousands of times. The Athlon's instruction decoders like the code to be 16 byte aligned, so 4 is a better number for those two.
As far as -falign-functions=64, all functons that are very small (small enough to fit in one cache line) will be inlined by -finline-functions, so the whole cache line will have useful information. This is so inital fetches from memory will be more beneficial (it grabs a 64 byte cache line from memory regaurdless of where the function is). The Larger functions that haven't been inlined will probably not be called as often, so it won't hurt to align them like this. This does waste some cache space, but since the functions are larger, it should not be all that much.
To whoeve asked ... I got some info from AMD, some info from http://www.arstechnica.com/, and the rest from various other sources that I no longer remember.
This should give pretty good performance, but as always, your milage may vary.
Open,Based on Free!
Free,Powerd by Opening!
Free,Powerd by Opening!
-
coollinuxer
- Posts: 109
- Joined: Sun Mar 16, 2003 4:42 pm
- Contact:
關於Athlon XP浮點運算的部分...
Did some testing on mfpmath= settings on an Athlon-Xp, using Lame to encode mp3's from wav's. As I understand it, Lame relies heavily on floating point functions, so we can expect to see the most difference this can make in a real-world situation.
I'm using Lame 3.91.1, with encoder option --preset fast standard
my gcc compiler options are, apart from the -mfpmath setting:
The tracks used are from the Live - The Distance to HereCode: Select all
CFLAGS="-O3 -mcpu=athlon-xp -march=athlon-xp -fforce-addr -fomit-frame-pointer funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4 -msse -mmmx -m3dnow -pipe
I've encoded track 01 and 04 twice for each setting, and compared the play/cpu time, which is an indication of how much faster than real-time the encoder is encoding the track.
encoding speed with -mfpmath=sse
track01: 12.384 12.367
track04: 12.471 12.547
-mfpmath=sse,387
track01: 11.835 11.974
track04: 12.317 12.442
-mfpmath=387
track01: 12.597 12.609
track04: 12.767 12.695
And in a search for the fastest compile options, I tried -ffast-math and -masm=intel. With the -masm set, it wouldn't compile (it gave syntax errors)
Without that option
-mfpmath=387 -ffast-math
track01: 12.798 12.835
track04: 12.896 12.927
And the track sounded exactly the same and had the same bit-rate for every setting used.
Conclusions:
The effect is very small, in the order of 5% for the fastest vs. the slowest mfpmath setting, and -ffast-math adds another 1-2% without it adversely affecting Lame. The fastest for an Athlon-XP is -mfpmath-387 -ffast-math
Note: this is a very small test, with only one program, on one system, and with only a limited amount of samples.
Open,Based on Free!
Free,Powerd by Opening!
Free,Powerd by Opening!
-
coollinuxer
- Posts: 109
- Joined: Sun Mar 16, 2003 4:42 pm
- Contact:
關於-O3
I used to compile my system with -O3, but my memory usage was always 95%-100% on my system with 384MB RAM. Also, about 100MB of swap space was being used. I decided to tried -Os on a few programs to see what the difference was.
My binary for gaim went from 3MB to ~700KB.
Abiword went from ~10MB to 5MB.
I then went ahead and recompiled most of my system with -Os. My memory usage is now in the 70% - 90% range with about 20MB of the swap file in use. I don't have any official timed benchmarks, but my system does feel mroe responsive with -Os. There no doubt that my Gnome Terminals load faster now. Mozilla is the same, but i noticed that mozilla ignores whatever flags I set in /etc/make.conf.
I included my memory and swap usage data becuase I think conclusions can be drawn from them: The #1 thing that'll kill your performance is lack of memory, forcing the OS to go out to the swap file on the disk to get data. Processors work on the order of nanoseconds. Harddrives work on the order of milliseconds, a million times slower.
I dont think a 3% increase in speed from going to -O3 isint going to be beneficial if at all if it causes all your libraries and programs to be 2x as large, eat up all your memory, and force you to swap out to the hard disk.
Open,Based on Free!
Free,Powerd by Opening!
Free,Powerd by Opening!
-
coollinuxer
- Posts: 109
- Joined: Sun Mar 16, 2003 4:42 pm
- Contact:
在 mozilla的ebuild裡
把這行註解掉
就可以使用自己在make.conf裡面設定的CFLAGS了
但是要注意他上面有說明
我的CFLAGS
目前正常使用中
但是...我怎麼沒有感覺效能有提昇.....
把這行註解掉
Code: Select all
strip-flags但是要注意他上面有說明
Code: Select all
# Recently there has been a lot of stability problem in Gentoo-land. Many
# things can be the cause to this, but I believe that it is due to gcc3
# still having issues with optimizations, or with it not filtering bad
# combinations (protecting the user maybe from himeself) yet.
#
# This can clearly be seen in large builds like glibc, where too aggressive
# CFLAGS cause the tests to fail miserbly.
#
# Quote from Nick Jones <carpaski@gentoo.org>, who in my opinion
# knows what he is talking about:
#
# People really shouldn't force code-specific options on... It's a
# bad idea. The -march options aren't just to look pretty. They enable
# options that are sensible (and include sse,mmx,3dnow when apropriate).
## The next command strips CFLAGS and CXXFLAGS from nearly all flags. If
# you do not like it, comment it, but do not bugreport if you run into
# problems.
#
# <azarah@gentoo.org> (13 Oct 2002)
Code: Select all
CFLAGS="-march=athlon-xp -m3dnow -msse -mfpmath=387 -O2 -finline-functions -fomit-frame-pointer-pipe -fprefetch-loop-arrays -funroll-loops -falign-jumps=4 -falign-loops=4 -falign-functions =64 -fforce-addr -ffast-math"但是...我怎麼沒有感覺效能有提昇.....
Open,Based on Free!
Free,Powerd by Opening!
Free,Powerd by Opening!
-
coollinuxer
- Posts: 109
- Joined: Sun Mar 16, 2003 4:42 pm
- Contact:
-
coollinuxer
- Posts: 109
- Joined: Sun Mar 16, 2003 4:42 pm
- Contact:
在OpenOffice的ebuild裡也有這一行
它還有
我把這幾行行註解掉
目前正在emerge中
下禮拜回家再來看結果...
Code: Select all
strip-flagsCode: Select all
filter-flags跟ALLOWS目前正在emerge中
下禮拜回家再來看結果...
Open,Based on Free!
Free,Powerd by Opening!
Free,Powerd by Opening!
之前使用
再編核心的時候make menuconfig 總是可以一下子就進入編核心的畫面
現在重新安裝一個系統 換了CFLAGS
現在下make menuconfig 出現done 之後就不動了
這個參數再satge1 的時候 emerge glibc 有出出現error 不過再次emerge 就沒問題了
改了CFLAGS 是不是會影響到編核心?
Code: Select all
CFLAGS="-march=pentium2 -O3 -pipe -fomit-frame-pointer" 現在重新安裝一個系統 換了CFLAGS
Code: Select all
CFLAGS="-O9 -mcpu=pentium2 -march=pentium2 -pipe -mmmx -fomit-frame-pointer -frerun-cse-after-loop -frerun-loop-opt -fexpensive-optimizations -falign-functions=4 -ffast-math -msse -fpmath=sse,387"這個參數再satge1 的時候 emerge glibc 有出出現error 不過再次emerge 就沒問題了
改了CFLAGS 是不是會影響到編核心?
mm 那就要
emerge -U sys-kernel/gentoo-sources
再emerge sys-kernel/gentoo-sources一次囉?
剛剛出門前索性把make menuconfig 丟著
回來的時候就出現一些錯誤訊息
make menuconfig
這個Illegal instruction
chroot 之後 執行nano 也會出現Illegal instruction
好像某些程式會有這樣子的訊息 top 也會
還沒有chroot 之前都是可以用的
emerge -U sys-kernel/gentoo-sources
再emerge sys-kernel/gentoo-sources一次囉?
剛剛出門前索性把make menuconfig 丟著
回來的時候就出現一些錯誤訊息
make menuconfig
Code: Select all
前面略
Preoaring scripts:functions,parsing..................done.
scripts/Menuconfig:line 1476:26445 Illegal instruction
$DIALOG --backtitle "$backtitle" --yesno "Do you wish to save your new kernel configuration?" 5 60chroot 之後 執行nano 也會出現Illegal instruction
好像某些程式會有這樣子的訊息 top 也會
還沒有chroot 之前都是可以用的
這是我自己在用的...make.conf wrote: CFLAGS="-march=pentium4 -mcpu=pentium4 -O3 -m32
-pipe -fforce-addr -falign-functions=4
-fprefetch-loop-arrays -fomit-frame-pointer
-fpmath=sse,387"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j2"
LDFLAGS="${CFLAGS}"
不跑xwindow 所以沒有-mmmx -msse
有需要的可以自己加上去
ps. 我自己有去改kernel的makefile...
沒使用genkernel @_@