CFLAGS/CXXFLAGS

[Piecia]

Od pewnego czasu zastanawiam się dlaczego skrypt gcccpuopt zwraca inne wartości march. Np wcześniej miałem athlon-xp teraz athlon4, na innym komputerze wcześniej miałem prescot teraz pentium4. O co chodzi?
Apropo -march=native, co może być przyczyną, że na jednej maszynie nie mogę tego ustawić?
W domu mam:

Code: Select all

$ gcccpuopt 
Warning: Your compiler supports the -march=native option which you may prefer

$ gcc-config -l
 [1] i686-pc-linux-gnu-3.3.6
 [2] i686-pc-linux-gnu-4.1.2
 [3] i686-pc-linux-gnu-4.2.3 *

natomiast w pracy:

Code: Select all

$ gcccpuopt 
-march=pentium4 -mfpmath=sse

$ gcc-config -l
 [1] i686-pc-linux-gnu-4.1.2
 [2] i686-pc-linux-gnu-4.2.3 *

Flagi USE dla gcc tym się różnią, że w pracy mam dodatkowo fortran i gtk.

[SlashBeast]

athlon4 i athlon-xp to to samo, patrz man gcc.

[C1REX]

Apropo -march=native, co może być przyczyną, że na jednej maszynie nie mogę tego ustawić?

Miałem ten sam problem. Wszystko z -march=athlon64 się ładnie kompilowało, a z native pluło błędami.

Code: Select all

grep -r 86 /etc/env.d/

Zobacz, czy masz cokolwiek poza 686. Ja miałem nie wiadomo skąd ślady po 486.
Wyczyściłem system z błędnego chosta i działa. Potrzebna będzie jednak rekompilacja przynajmniej kluczowych pakietów.

[Piecia]

Miałem ten sam problem. Wszystko z -march=athlon64 się ładnie kompilowało, a z native pluło błędami.

Code: Select all

grep -r 86 /etc/env.d/

Zobacz, czy masz cokolwiek poza 686. Ja miałem nie wiadomo skąd ślady po 486.
Wyczyściłem system z błędnego chosta i działa. Potrzebna będzie jednak rekompilacja przynajmniej kluczowych pakietów.

Coś tam mam apropo 486, ale głównie tyczy się *PATH poza jednym przypadkiem(/etc/env.d/gcc/config-i486-pc-linux-gnu:CURRENT=i486-pc-linux-gnu-4.1.2). Ale na tym kompie -march=native działa.

@SlashBeast dzięki. Następnym razem przeczytam manula zanim zadam pytanie.

[C1REX]

Ale co znaczy, że nie możesz ustawić? Nic się nie kompiluje z native?

[Piecia]

Code: Select all

grep native /etc/paludis/bashrc 
ARCHITECTURA="-march=native"
paludis -I | grep march
        CXXFLAGS:              -O2 -march=prescott -momit-leaf-frame-pointer -s -pipe

Całość wygląda tak:

Code: Select all

CFLAGS="-march=native -O2 -s -pipe -mfpmath=sse -fomit-frame-pointer"
CXXFLAGS="-march=native -O2 -s -pipe -mfpmath=sse -momit-leaf-frame-pointer"

paludis -i1 mc
[...]
No i przekompilował. Kurcze nie wiem dlaczego wcześniej nie chciało działać. Nie zapisałem sobie jaki to był błąd. Sprawdzę dla @world, możliwe że tylko na niektórych pakietach się wywalało.
Na dzień dzisiejszy koniec spekulacji, zrobię rsynca, przekompiluję @world i sprawdzę co było nie tak. Może to wina paludisa? Odwołuję chwilowo alarm

[Lord_Raven]

czy native włącza jakies flagi niewyszczegolnione tu: http://gentoo-wiki.com/Safe_Cflags
albo inaczej, jest jakas mozliwość na podejrzenie tego co włącza native?

[C1REX]

Niemal na bank inaczej kompiluje, bo jak miałem lekko namieszane w systemie z CHOSTem, to mi na native się nie kompilowało poprawnie wiele programów, które na tych z linku normalnie się kompilowały (czyt. cały system miałem tak postawiony).

Z drugiej strony jednak, to dzięki temu wykryłem ten błąd i się szybko pozbyłem.

Jak zwykle zadziałało placebo i mam wrażenie, że na system przekompilowany na native działa szybciej : )
Działa, czy nie, to przyjemnie w to wierzyć : )

[C1REX]

Przetestowałem zużycie Ramu systemu skompilowanewgo na -O2 i tego samego na -Os.

Po odpaleniu kilku aplikacji (KDE, FireFox, Amarok, Kadu, K3b) różnica wyniosła ok. 10-15MB.
Zauważalnie szybciej też nic się nie odpala. Moim zdaniem nie ma sensu kombinować i ryzykować.

[C1REX]

Czy jeśli skompiluje się program pod 386 bez żadnych dodatkowych funkcji procesora, to binarka będzie mniejsza od wersji skompilowanej pod core duo ze wszystkimi funkcjami, jakie obsługuje ten procesor?

Nie. Instrukcje procesora nie są zdefiniowane w plikach wykonywalnych.

Code: Select all

[mtj@camus]$ gcc -o sort sort.c -O2
[mtj@camus]$ size sort
   text    data     bss     dec     hex filename
    842     252       4    1098     44a sort
[mtj@camus]$ gcc -o sort sort.c -O2 -march=pentium2
[mtj@camus]$ size sort
   text    data     bss     dec     hex filename
    870     252       4    1126     466 sort
[mtj@camus]$

i komentarz autora:

From Listing 2, we can see that the instruction size (text section) of the image increased by 28 bytes. But in this example, it's a small price to pay for the speed benefit.

Czy z tego wynika, że program optymalizowany pod 386 może być mniejszy, od optymalizowanego z march=native na 686?
Tym samym zajmujący mniej Ramu i teoretycznie szybciej się odpalający?

[C1REX]

http://lists.apple.com/archives/Unix-po ... 00053.html

A tu link o -Os i Apple.
Apple kompiluje z -Os, bo taka optymalizacja daje najlepszą wydajność w rozumieniu Apple. Część programów kompilowana jest jednak z innymi optymalizacjami.

[Spaulding]

Code: Select all

CFLAGS="-O2 -march=prescott -pipe -funroll-loops -fomit-frame-pointer -mfpmath=sse"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,--hash-style=gnu"

Cały system na tym mi działa. Zero wodotryskow...

[SlashBeast]

Ja mam teraz każdy komputer na

Code: Select all

CFLAGS="-march=native -O2 -pipe"
CFLAGS="${CFLAGS} -funroll-loops -ftracer"
CXXFLAGS="${CFLAGS}"
CHOST="x86_64-pc-linux-gnu"
LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,--hash-style=gnu"

I wszystko działa ładnie, bardzo ładnie, jedynie ffmpeg musiałem zbudować bez ftracera. Po dodaniu LDFLAGS wszystko startuje szybciej...

[matiit]

LDFLAGS to jest swykła zmienna, tak? Jak tak to umieścić je w make.conf, albo /etc/profile albo czymkolwiek ładowanym przez basha?

[unK]

W make.conf najlepiej.

[matiit]

Ok dzięki
1008 pakietów

aa tak z ciekawości, jaka jest różnica że wczyta to z make.conf a nie np. z /root/.bashrc?

[C1REX]

I wszystko działa ładnie, bardzo ładnie, jedynie ffmpeg musiałem zbudować bez ftracera. Po dodaniu LDFLAGS wszystko startuje szybciej...

Z tymi flagami miałeś jakieś problemy z kompilacją, czy stabilnym działaniem czegokolwiek?
Osobiście mam KDE i na bezpiecznych flagach jest stabilne jak skała. Nigdy mi żadne okienko z błędem nie wyskoczyło.

Kiedyś jednak używałem mniej bezpiecznych flag i ze stabilnością bywało różnie.

[SlashBeast]

Ok dzięki
1008 pakietów

aa tak z ciekawości, jaka jest różnica że wczyta to z make.conf a nie np. z /root/.bashrc?

Żadna, ale to flaga do ld, więc w make.conf będzie jej najlepiej.

[Z tymi flagami miałeś jakieś problemy z kompilacją, czy stabilnym działaniem czegokolwiek?
Osobiście mam KDE i na bezpiecznych flagach jest stabilne jak skała. Nigdy mi żadne okienko z błędem nie wyskoczyło.

Kiedyś jednak używałem mniej bezpiecznych flag i ze stabilnością bywało różnie.

Wszystko gra i bucy. Zero problemów.

Dodam, że używam gcc 4.3.0, kiedyś miałem O3 potem O2 z ftree-vectorize ale teraz samo O2. Zabawne jest to, że w gcc 4.3.0 ftree-vectorize jest w O3 i gdy mialem xorg-server z O3 skompilowany działał ładnie, natomiast gdy miałem z O2 ftree-vectorize xorg-server się odrazu po starcie wywalał... magia.

[C1REX]

Dodam, że używam gcc 4.3.0, kiedyś miałem O3 potem O2 z ftree-vectorize ale teraz samo O2. Zabawne jest to, że w gcc 4.3.0 ftree-vectorize jest w O3 i gdy mialem xorg-server z O3 skompilowany działał ładnie, natomiast gdy miałem z O2 ftree-vectorize xorg-server się odrazu po starcie wywalał... magia.

Może filtrowana była flaga O3 dla xorg? Ewentualnie ftree-vectorize działa poprawnie dla xorg tylko z innymi flagami z o3?

Gdzieś w tym temacie była o tym dyskusja, że flagi z O3 dodane ręcznie do O2 w make.conf działają inaczej, niż samo O3.
Nie jestem pewny, ale może filtry odrzucają niektóre flagi z zestawów O2 i O3 i ich ręczne dodanie wymusza ich użycie?

BTW: Co ta flaga ftree-vectorize robi, wyjaśniając to na chłopski (ktoś kto nie ma bladego pojęcia o programowaniu) rozum?

[unK]

Dodam, że używam gcc 4.3.0, kiedyś miałem O3 potem O2 z ftree-vectorize ale teraz samo O2. Zabawne jest to, że w gcc 4.3.0 ftree-vectorize jest w O3 i gdy mialem xorg-server z O3 skompilowany działał ładnie, natomiast gdy miałem z O2 ftree-vectorize xorg-server się odrazu po starcie wywalał... magia.

Ja teraz rekompiluję world z flagami

Code: Select all

-O2 -march=native -pipe -fomit-frame-pointer -ftree-vectorize -fno-ident

z powodu tego, że gcc-4.3.1 dostał się do ~arch. Zobaczymy, co będzie z tym ftree-vectorize ;p

Co ta flaga ftree-vectorize robi, wyjaśniając to na chłopski (ktoś kto nie ma bladego pojęcia o programowaniu) rozum?

Loop vectorization would be an attempt to make use of SIMD (Single Instruction, Multiple Data) to optimize loops. In particular, if the calculation done in a given loop iteration is independant of the result from previous iterations, it may unroll the loop to a depth of, say, 4, and do the four unrolled copies in parallel via a set of SIMD instructions to a vector processor.