[Rozw.] Dodatkowe opcje kompilatora gcc

Te, które nie mieszczą się w powyższych kategoriach, a mają coś wspólnego ze Slackware.

Moderatorzy: Moderatorzy, Administratorzy

vitos
Użytkownik
Posty: 104
Rejestracja: 2005-10-30, 09:13
Lokalizacja: Pszów

[Rozw.] Dodatkowe opcje kompilatora gcc

Post autor: vitos »

Chciałbym zapytać Szanownych Grupowiczów o pewne dodatkowe opcje kompilatora gcc. Czy należy ich używać, czy może kod wynikowy będzie mniej optymalny poprzez ich użycie.

Otóż kompiluję standardowe paczki Slackware current za pomocą zmodyfikowanych nieco pod kątem optymalizacji skryptów *.SlackBuild

Procesor to Pentium 4 2.4GHz HT Northwood i programy będą działać tylko na tym sprzęcie.

Kod: Zaznacz cały

cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 2.40GHz
stepping        : 9
cpu MHz         : 2394.289
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts sync_rdtsc cid xtpr
bogomips        : 4791.36
clflush size    : 64
Opcje, które później są przenoszone jako parametry dla gcc w skrypcie wyglądają następująco:

Kod: Zaznacz cały

SLKCFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer -m32 -mmmx -msse -msse2 -mfpmath=sse"
O2 - drugi od najwyższego stopień optymalizacji kodu

-march=pentium4 - optymalizacja dla Pentium4

-pipe - używanie przez assembler pipe'ów zamiast plików tymczasowych (opcja dopuszczona do używania przez Safe CFlags) - nie wiem, czy mam rację, ale wydaje mi się, że może przyspieszać sam proces kompilacji, proszę o ewentualne sprostowanie

-fomit-frame-pointer - opcja dopuszczona na Safe CFlags - jej opis jest tutaj, niestety nie za bardzo mam świadomość, czego dotyczy ;-(

Używam również pozostałych opcji,a mianowicie: -m32 -mmmx -msse -msse2 -mfpmath=sse
Tutaj pytanie, czy ma sens dołączanie ich, skoro używam -march=pentium4, czy może samo użycie -march=pentium4 implikuje optymalizację dla mmx, sse oraz sse2, a jeśli nie, to czy kolejność podawania tych flag ma jakieś znaczenie? Czy także jest sens podawanie -m32 skoro ma się wygenerować kod 32-bitowy? Nigdzie nie potrafiłem się doszukać wyczerpujących odpowiedzi na te pytania. Ponadto pozostaje jeszcze sprawa -mfpmath=sse. Ten przełącznik jest opisany tutaj . Z opisu wynika nie zagłębiając się w szczegóły techniczne, że niektóre programy mogą się nie kompilować z ustawionym mfpmath na sse. Domyślnie jest bodaj 387.

Bardzo proszę o komentarze i wyjaśnienie nurtujących mnie poruszonych powyżej kwestii.

Będę bardzo wdzięczny za pomoc w zrozumieniu problemu.

Pozdrawiam
Witek Tosta

[ Komentarz dodany przez: Zielony: 2008-03-16, 14:42 ]
"[Rozw.]"!
Ostatnio zmieniony 2008-03-16, 14:42 przez vitos, łącznie zmieniany 1 raz.
Awatar użytkownika
mina86
Moderator
Posty: 3343
Rejestracja: 2004-06-14, 21:58
Lokalizacja: Linux 5.x x86_64
Kontakt:

Re: [Rozw.] Dodatkowe opcje kompilatora gcc

Post autor: mina86 »

vitos pisze:O2 - drugi od najwyższego stopień optymalizacji kodu
Drugi od najniższego, a konkretnie: -O0 wyłącza optymalizację, -O1 włącza różne opcję, -O2 włącza dodatkowe opcje, -O3 włącza jeszcze więcej opcji[/b] i jest ejszcze -Os (czy tam -OS), który (o ile dobrze pamiętam) jest podobny do jednego z tych dwóch ostatnich, tylko nie włącza opcji powodujących zwiększenie kodu.
vitos pisze:-pipe
Tak, -pipe nie wpływa na wynik kompilacji.
vitos pisze:-fomit-frame-pointer
O ile dobrze pamiętam, powoduje że kompilator nie zapisuje rejestru ebp na stosie przy odpalaniu funkcji.
vitos pisze:-m32 -mmmx -msse -msse2
Prawdopodobnie możesz ich nie podawać i efekt będzie taki sam.
vitos pisze:-mfpmath=sse
Odnośnie tego poczytaj info gcc. Zresztą odnośnie wszystkich opcji poczytaj info gcc.

Ja jeszcze dodaje -s, żeby stripował pliki. -fno-align-loops]/b] i -fno-align-labels żeby nie wyrównywał etykiet i pętli (zmniejsza kod, może spowolnić, różnie bywa).
Zastrzegam sobie prawo nieanalizowania postów pisanych niepoprawną polszczyzną.
Post generated automatically by A.I. system code name ‘mina86’ in response to the previous one.
wmigda
Użytkownik
Posty: 2
Rejestracja: 2008-03-01, 22:47

Re: Dodatkowe opcje kompilatora gcc

Post autor: wmigda »

http://www.gentoo.org/doc/en/gcc-optimization.xml
http://gentoo-wiki.com/Safe_Cflags
http://gentoo-wiki.com/CFLAGS
zbiorcza strona: http://www.freehackers.org/Gentoo_flags

ja posiadam P4 Northwood HT i moje flagi to (gentoo tested):

Kod: Zaznacz cały

CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer -msse2 -mfpmath=sse -s"
CXXFLAGS="-march=pentium4 -O2 -pipe -msse2 -mfpmath=sse -s"

Kod: Zaznacz cały

#cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 3.40GHz
stepping        : 9
cpu MHz         : 3400.000
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips        : 6966.55
clflush size    : 64

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 3.40GHz
stepping        : 9
cpu MHz         : 3400.000
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips        : 6963.21
clflush size    : 64
pozdr,[/code]
Ostatnio zmieniony 2008-03-15, 14:18 przez wmigda, łącznie zmieniany 3 razy.
vitos
Użytkownik
Posty: 104
Rejestracja: 2005-10-30, 09:13
Lokalizacja: Pszów

Re: [Rozw.] Dodatkowe opcje kompilatora gcc

Post autor: vitos »

wmigda pisze:-mfpmath=sse -s
Co oznacza dodatkowe -s w -mfpmath=sse?
-mfpmath=sse jest opisane w manualu gcc, opisanej opcji -s nigdzie nie znalazłem.

Dziękuję za odpowiedź.

Witek
Awatar użytkownika
difrost
Moderator
Posty: 2802
Rejestracja: 2006-03-11, 12:31
Lokalizacja: Wrocław
Kontakt:

Re: [Rozw.] Dodatkowe opcje kompilatora gcc

Post autor: difrost »

To jest tak naprawdę opcja linkera (man ld). Wymusza stripowianie przy linkowaniu (praktycznie to samo co -Os, z tym, że w tym przypadku stripowanie następuje przy kompilacji).
[url=http://bdtk.sourceforge.net][img]http://pin.if.uz.zgora.pl/~beton/bdt-ready.png[/img][/url] #337142
--------------------------------------------
"I had a letter in the post today. It said 'Gas Bill'. It sounds a tempting offer." -- Alan Cox
"Users have been trained that when a computer bluescreens and losing all of their data, it's either (a) just the way things are, or (b) it's microsoft's fault." -- Theodore Tso
Awatar użytkownika
mina86
Moderator
Posty: 3343
Rejestracja: 2004-06-14, 21:58
Lokalizacja: Linux 5.x x86_64
Kontakt:

Re: [Rozw.] Dodatkowe opcje kompilatora gcc

Post autor: mina86 »

difrost pisze:(praktycznie to samo co -Os, z tym, że w tym przypadku stripowanie następuje przy kompilacji)
Raczej zupełnie co innego. -Os powoduje, że opcje zwiększające kod nie są włączone (w stosunku do -O2), a -s usuwa niepotrzebne symbole czy coś tam.
Zastrzegam sobie prawo nieanalizowania postów pisanych niepoprawną polszczyzną.
Post generated automatically by A.I. system code name ‘mina86’ in response to the previous one.
Awatar użytkownika
difrost
Moderator
Posty: 2802
Rejestracja: 2006-03-11, 12:31
Lokalizacja: Wrocław
Kontakt:

Re: [Rozw.] Dodatkowe opcje kompilatora gcc

Post autor: difrost »

OK, zgadza się, aczkolwiek efekt jest taki sam ;) -Os wyłącza: -falign-functions -falign-jumps -falign-loops -falign-labels -freorder-blocks -freorder-blocks-and-partition -fprefetch-loop-arrays -ftree-vect-loop-version

Ma to wpływ na optymalizację, bo opcje -falign-functions, -falign-jumps, -falign-loops -fprefetch-loop-arrays -ftree-vect-loop-version potrafią być bardzo efektywne (zwłaszcza wektoryzacja). Ja zasadniczo preferuję -O2 i stripowanie ,,ręczne'', tj. przy użyciu strip.

Moje flagi to:

Kod: Zaznacz cały

BETON_OPT=prescott

BETON_OPTFLAG=march

# CFLAGS defaults
BETON_CFLAGS="-Wall -O2 -pipe -msse3"

# CXXFLAGS defaults
BETON_CXXFLAGS="-Wall -O2 -pipe -msse3"
Procesor:

Kod: Zaznacz cały

vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 CPU         T5500  @ 1.66GHz
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm
vitos
Użytkownik
Posty: 104
Rejestracja: 2005-10-30, 09:13
Lokalizacja: Pszów

Niuanse crosskompilacji

Post autor: vitos »

Po niecałym roku od napisania tego posta i otrzymaniu wyczerpujących odpowiedzi od Szanownych Kolegów chciałbym zapytać o jeszcze jeden niuans cross kompilacji.

Mianowicie, posiadając taki procesor,:

Kod: Zaznacz cały

vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 2.40GHz
stepping        : 9
cpu MHz         : 2394.155
cache size      : 512 KB
fpu_exception   : yes
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts cid xtpr
bogomips        : 4788.31
clflush size    : 64
power management:
mający architekturę x86, popularnie nazywany Pentium 4 Northwood 2,4GHz HT, posiada on następujące rozszerzenia, które może wykorzystać kompilator: mmx, sse, sse2 ustawiając optymalizację na -march=pentium4.
Mój system operacyjny to Slackware 12.2, gdzie są zainstalowane:
- gcc 4.3.2
- libtool 1.5.26
- make 3.81
- binutils 2.19.50
- autoconf 2.63
oraz wszystkie standardowe pakiety z grup a/ ap/ d/ kde/ kdei/ l/ n/ x/ xap/

Moje pytanie jest następujące. Czy będzie miała sens i czy wogóle wyjdzie poprawnie kompilacja dla -march=core2 lub -march=athlon-mp na moim procesorze ?

Dlaczego pytam? Procesor core2 ma znacznie więcej rozszerzeń niż mój leciwy Pentium4, na którym kompiluję, a ponadto na przykład Athlon-MP posiada rozszerzenia 3DNow!, których procesory intelowskie nie posiadają. A ja między innymi posiadam maszynę AMD, dla której również chciałbym przygotować paczki na moim "stanowisku kompilacyjnym" wyposażonym w Intel Pentium 4.

Czy oprogramowanie kompilujące poradzi sobie z problemem, kiedy na procesorze starszym kompiluje się programy ustawiając rozszerzenia procesorów nowszych (wymuszenie "wyższego" -march), których dany nie posiada, jak również rozszerzenia, które są niejako z innej architektury, w moim przypadku chęci kompilacji pod AMD na CPU Intela. Sytuacja odwrotna, w której na Pentium 4 będę kompilował dla Pentium 3, będzie dopuszczalna, ponieważ Pentium 4 posiada wszystkie rozszerzenia wcześniejszego Pentium 3. Bardzo proszę o ewentualne sprostowanie mojego rozumowania.

Oczywiście nie bierzemy pod uwagę cross kompilacji na zupełnie inne architektury niż x86 oraz nie będziemy używać opcji "niższe" -march wraz z "wyższym" -mtune, tylko "samo" -march.


Pozdrawiam i dziękuję za pomoc
Witek
Awatar użytkownika
mina86
Moderator
Posty: 3343
Rejestracja: 2004-06-14, 21:58
Lokalizacja: Linux 5.x x86_64
Kontakt:

Re: [Rozw.] Dodatkowe opcje kompilatora gcc

Post autor: mina86 »

difrost pisze:OK, zgadza się, aczkolwiek efekt jest taki sam ;)
No właśnie nie jest taki sam. -Os dotyczy sposobu kompilacji, tj. listy włączonych optymalizacji, a -s powoduje usunięcie z binarek niepotrzebnych symboli w momencie łączenia.

Na poniższym przykładzie

Kod: Zaznacz cały

$ cat hello.c
#include <stdio.h>

int main(void) {
        puts("hello, world");
        return 0;
}
$ cat a.sh; sh a.sh
for c in "" -c; do
        for s in "" -s; do
                for Os in "" "-Os"; do
                        gcc $c $s $Os -o hello"$c$s$Os" hello.c
                done
        done
done
$ cmp hello-c hello-c-s
$ cmp hello-c-s-Os hello-c-Os
$ cmp hello hello-s
hello hello-s differ: byte 33, line 1
$ cmp hello-Os hello-s-Os
hello-Os hello-s-Os differ: byte 33, line 1
widzimy, że opcja -s ma znaczenie jedynie przy linkowaniu i jeżeli jedynie kompilujemy dany plik to jej użycie nie ma żadnego znaczenia. Można zresztą sprawdzić czy program skompilowany z -Os posiada symbole, czy nie:

Kod: Zaznacz cały

$ objdump -t hello-Os hello-s

hello-Os:     file format elf32-i386

SYMBOL TABLE:
08048114 l    d  .interp        00000000              .interp
08048128 l    d  .note.ABI-tag  00000000              .note.ABI-tag
08048148 l    d  .hash  00000000              .hash
08048170 l    d  .dynsym        00000000              .dynsym
080481c0 l    d  .dynstr        00000000              .dynstr
0804820a l    d  .gnu.version   00000000              .gnu.version
08048214 l    d  .gnu.version_r 00000000              .gnu.version_r
08048234 l    d  .rel.dyn       00000000              .rel.dyn
0804823c l    d  .rel.plt       00000000              .rel.plt
08048254 l    d  .init  00000000              .init
08048284 l    d  .plt   00000000              .plt
080482d0 l    d  .text  00000000              .text
0804841c l    d  .fini  00000000              .fini
08048438 l    d  .rodata        00000000              .rodata
08048450 l    d  .eh_frame      00000000              .eh_frame
08049454 l    d  .ctors 00000000              .ctors
0804945c l    d  .dtors 00000000              .dtors
08049464 l    d  .jcr   00000000              .jcr
08049468 l    d  .dynamic       00000000              .dynamic
08049530 l    d  .got   00000000              .got
08049534 l    d  .got.plt       00000000              .got.plt
0804954c l    d  .data  00000000              .data
08049558 l    d  .bss   00000000              .bss
00000000 l    d  .comment       00000000              .comment
00000000 l    d  .debug_aranges 00000000              .debug_aranges
00000000 l    d  .debug_pubnames        00000000              .debug_pubnames
00000000 l    d  .debug_info    00000000              .debug_info
00000000 l    d  .debug_abbrev  00000000              .debug_abbrev
00000000 l    d  .debug_line    00000000              .debug_line
00000000 l    d  .debug_str     00000000              .debug_str
00000000 l    d  .debug_ranges  00000000              .debug_ranges
00000000 l    df *ABS*  00000000              init.c
00000000 l    df *ABS*  00000000              initfini.c
00000000 l    df *ABS*  00000000              crtstuff.c
08049454 l     O .ctors 00000000              __CTOR_LIST__
0804945c l     O .dtors 00000000              __DTOR_LIST__
08049464 l     O .jcr   00000000              __JCR_LIST__
08048300 l     F .text  00000000              __do_global_dtors_aux
08049558 l     O .bss   00000001              completed.5772
08049554 l     O .data  00000000              p.5770
08048330 l     F .text  00000000              frame_dummy
00000000 l    df *ABS*  00000000              crtstuff.c
08049458 l     O .ctors 00000000              __CTOR_END__
08049460 l     O .dtors 00000000              __DTOR_END__
08048450 l     O .eh_frame      00000000              __FRAME_END__
08049464 l     O .jcr   00000000              __JCR_END__
080483f0 l     F .text  00000000              __do_global_ctors_aux
00000000 l    df *ABS*  00000000              initfini.c
00000000 l    df *ABS*  00000000              hello.c
08049534 l     O .got.plt       00000000              .hidden _GLOBAL_OFFSET_TABLE_
08049454 l       .ctors 00000000              .hidden __init_array_end
08049454 l       .ctors 00000000              .hidden __init_array_start
08049468 l     O .dynamic       00000000              .hidden _DYNAMIC
0804954c  w      .data  00000000              data_start
08048380 g     F .text  00000005              __libc_csu_fini
080482d0 g     F .text  00000000              _start
00000000  w      *UND*  00000000              __gmon_start__
00000000  w      *UND*  00000000              _Jv_RegisterClasses
08048438 g     O .rodata        00000004              _fp_hw
0804841c g     F .fini  00000000              _fini
00000000       F *UND*  00000000              __libc_start_main@@GLIBC_2.0
0804843c g     O .rodata        00000004              _IO_stdin_used
0804954c g       .data  00000000              __data_start
08049550 g     O .data  00000000              .hidden __dso_handle
08048390 g     F .text  0000005a              __libc_csu_init
08049558 g       *ABS*  00000000              __bss_start
0804955c g       *ABS*  00000000              _end
00000000       F *UND*  00000000              puts@@GLIBC_2.0
08049558 g       *ABS*  00000000              _edata
080483ea g     F .text  00000000              .hidden __i686.get_pc_thunk.bx
08048354 g     F .text  00000025              main
08048254 g     F .init  00000000              _init



hello-s:     file format elf32-i386

SYMBOL TABLE:
no symbols


[ Dodano: 2009-01-17, 12:09 ]
vitos pisze:Czy będzie miała sens i czy wogóle wyjdzie poprawnie kompilacja dla -march=core2 lub -march=athlon-mp na moim procesorze ?
Podejrzewam, że możesz śmiało kompilować programy z takimi flagami bez wciągania w to wszystko magii cross-kompilacji (trochę nie wiem jak to przetłumaczyć). Nie oznacza to jednak, że tak skompilowany program będzie działał -- w rezultacie może on wykorzystywać rozszerzenia, których Twój procesor nie posiada. Oznacza to również, że teoretycznie program może się nie skompilować, choć jest to raczej wątpliwe.
vitos pisze:Czy oprogramowanie kompilujące poradzi sobie z problemem, kiedy na procesorze starszym kompiluje się programy ustawiając rozszerzenia procesorów nowszych
W tym przypadku tak -- na obu maszynach korzystasz z tego samego kompilatora w tej samej wersji więc kompilować możesz sobie jak chcesz, jednak kwestia jest nie tylko w samej kompilacji -- skrypty configure często tworzą sobie małe programiki, które potem uruchamiają, aby sprawdzić czy jakaś funkcjonalność jest dostępna. Tak jak napisałem, w praktyce wszystko powinno działać, bo takie małe programiki raczej nie będą korzystać z większości rozszerzeń.

Osobiście darowałbym sobie jednak całą zabawę i budował paczki dla P4, które byłyby używane na obu maszynach.
Zastrzegam sobie prawo nieanalizowania postów pisanych niepoprawną polszczyzną.
Post generated automatically by A.I. system code name ‘mina86’ in response to the previous one.
vitos
Użytkownik
Posty: 104
Rejestracja: 2005-10-30, 09:13
Lokalizacja: Pszów

Re: [Rozw.] Dodatkowe opcje kompilatora gcc

Post autor: vitos »

mina86 pisze:..., jednak kwestia jest nie tylko w samej kompilacji -- skrypty configure często tworzą sobie małe programiki, które potem uruchamiają, aby sprawdzić czy jakaś funkcjonalność jest dostępna. Tak jak napisałem, w praktyce wszystko powinno działać, bo takie małe programiki raczej nie będą korzystać z większości rozszerzeń.
Oczywiście cały czas chodziło mi, nie napisałem tego szczegółowo, o budowanie slackware'owskich paczek, gdzie skrypt SlackBuild zapuszcza sobie najpierw ./configure poprzedzone zmienną SLKCFLAGS w której podane są odpowiednie flagi dla kompilatora :-)

Chyba powoli zaczynam rozumieć jakie ogólnie rzecz biorąc znaczenie mają zadeklarowane flagi.

Jak sądzę, kod wynikowy w postaci programu, któremu podczas budowania zadeklarowaliśmy flagi kompilacyjne dla odpowiedniego procesora, podczas wykonywania go przez procesor, umożliwia procesorowi użycie pewnych dodatkowych możliwości (mmx, sse, 3dnow, itp.). Gdybyśmy jednak ten sam program zbudowali np. z użyciem flagi -march=i386 i uruchomili na np. na procesorze Pentium III, program oczywiście by się wykonał, tylko nie używał by dodatkowych rozszerzeń procesora, przez co prawdopodobnie działałby wolniej.

Pozdrawiam
Witek
Awatar użytkownika
mina86
Moderator
Posty: 3343
Rejestracja: 2004-06-14, 21:58
Lokalizacja: Linux 5.x x86_64
Kontakt:

Re: [Rozw.] Dodatkowe opcje kompilatora gcc

Post autor: mina86 »

Jak sądzę, kod wynikowy w postaci programu, któremu podczas budowania zadeklarowaliśmy flagi kompilacyjne dla odpowiedniego procesora, podczas wykonywania go przez procesor, umożliwia procesorowi użycie pewnych dodatkowych możliwości (mmx, sse, 3dnow, itp.). Gdybyśmy jednak ten sam program zbudowali np. z użyciem flagi -march=i386 i uruchomili na np. na procesorze Pentium III, program oczywiście by się wykonał, tylko nie używał by dodatkowych rozszerzeń procesora, przez co prawdopodobnie działałby wolniej.
Dokładnie tak, przy czym należy zwrócić uwagę, że różnica prędkości pomiędzy architekturami mało odległymi w czasie będzie w praktyce niezauważalna (chyba, że mowa o naprawdę jakimś specyficznym programie) dlatego jeżeli masz dwa komputery niewiele się różniące pod względem obsługiwanych rozszerzeń to zamiast budować dwie paczki lepiej zrobić paczkę dla "słabszego" i używać ją na obu komputerach.

Jeszcze, aby nie pozostawiać niedomówień, flaga -mtune powoduje, że program będzie działał na komputerach takich jak zadeklarowano w -march jednak zostanie zoptymalizowany dla architektury innej. Przykładowo, procesory 386 raczej nie posiadały jakichś zaawansowanych technik przewidywania skoków ani przetwarzania wielopotokowego, które pojawiły się później. Gdyby chcieć kompilować programy działające na i386, ale korzystające z różnych technik optymalizacji dostępnych na nowszych architekturach należałoby skompilować z opcjami -march=i386 -mtune=i686 (lub podobnymi). Warto zauważyć, że program tak skompilowany może działać na 386 wolniej niż gdyby mtune nie zostało podane.
Zastrzegam sobie prawo nieanalizowania postów pisanych niepoprawną polszczyzną.
Post generated automatically by A.I. system code name ‘mina86’ in response to the previous one.
vitos
Użytkownik
Posty: 104
Rejestracja: 2005-10-30, 09:13
Lokalizacja: Pszów

Re: [Rozw.] Dodatkowe opcje kompilatora gcc

Post autor: vitos »

mina86 pisze:Jeszcze, aby nie pozostawiać niedomówień, flaga -mtune powoduje, że program będzie działał na komputerach takich jak zadeklarowano w -march jednak zostanie zoptymalizowany dla architektury innej. Przykładowo, procesory 386 raczej nie posiadały jakichś zaawansowanych technik przewidywania skoków ani przetwarzania wielopotokowego, które pojawiły się później. Gdyby chcieć kompilować programy działające na i386, ale korzystające z różnych technik optymalizacji dostępnych na nowszych architekturach należałoby skompilować z opcjami -march=i386 -mtune=i686 (lub podobnymi). Warto zauważyć, że program tak skompilowany może działać na 386 wolniej niż gdyby mtune nie zostało podane.
Zauważyłem dosyć ciekawą sprawę dotyczącą kompilacji pod inną maszynę, niż ta, na której przeprowadza się kompilację. Mianowicie. Kompilowałem sobie paczki na maszynie pentium4 (gcc 4.3.2) dla maszyny pentium3. Flagi w configure były takie:

Kod: Zaznacz cały

-march=pentium3 -pipe -fomit-frame-pointer -mfpmath=sse
Po zainstalowaniu tak skompilowanych paczek ze slackware'em 12.2 niektóre komendy nie działają i wylatują z komunikatem illegal instruction, a tak samo skompilowane paczki, tylko z -march=pentium4 na maszynie pentium4, działają poprawnie. Wniosek chyba z tego taki, że choć maszyna "wyższa" obsługuje wszystkie rozszerzenia maszyny niższej (w moim przypadku programy kompilowałem na pentium4, a już skompilowane uruchamiałem na pentium3), to nie zawsze taka croskompilacja będzie działać, choć architektury są tej samej firmy i w kontekście kompilatora gcc są mniej więcej zbliżone. Nie wiem, być może opcja -mfpmath=sse coś namieszała.

Wniosek jest taki, że jak kompilujemy na inny procesor niż jest na maszynie kompilującej, to bezpieczniej jest ustawić -march=i686 -mtune=maszyna_docelowa.

Witek
Ostatnio zmieniony 2009-01-27, 19:08 przez vitos, łącznie zmieniany 2 razy.
f1y
Użytkownik
Posty: 11
Rejestracja: 2008-12-14, 16:16
Lokalizacja: Gliwice

Re: [Rozw.] Dodatkowe opcje kompilatora gcc

Post autor: f1y »

Gcc od wersji 4.2 wspiera flagę native dla funkcji mtune/march, która umożliwia kompilację kodu dokładnie pod maszynę, na której kod jest kompilowany. Flaga powoduje automatyczne rozpoznanie procesora wraz z jego funkcjami oraz włącza obsługę tychże. Kod wynikowy będzie jednak działać tylko na maszynie z danym procesorem.
"Tylko dwie rzeczy są nieskończone: wszechświat oraz ludzka głupota, choć nie jestem pewien co do tej pierwszej", Albert Einstein.
ODPOWIEDZ