# CFLAGS, gcc i procesory

## Xywa

Witam wszytskich

Od prawie roku posiadam system z procesorem: Intel Core 2 Duo T5800 2 GHz Dual-Core

W ustawieniach CFLAGS mam "-march=nocona"

Myśle żeby przestawić na "-march=core2", ale nie jestem pewien czy z tym procesorem moge używać tej flagi? 

Tutaj jest tylko lista flag dla np. gcc 4.3.4:

http://gcc.gnu.org/onlinedocs/gcc-4.3.4/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options

Czy jest jakaś strona (komenda) żeby móc sprawdzić jaką flage (dla danego gcc) wybrać aby maksymalnie wykorzystać możliwości procesora?

Czy warto przejść np. na 4.4.2 zamiast 4.3.4? Czy są jakieś strony z testami i benchmarkami?

----------

## soban_

U mnie w make.conf wyglada to tak:

```
CHOST="x86_64-pc-linux-gnu"

CFLAGS="-O2 -march=core2 -O2 -pipe -fomit-frame-pointer -mssse3"

CXXFLAGS="${CFLAGS}"
```

Linka ktorego moge polecic to: http://en.gentoo-wiki.com/wiki/Safe_Cflags na dole masz wybor  :Wink:  wykonaj jeszcze:

```
cat /proc/cpuinfo
```

Co do gcc to uzywam 4.4.2 i nie widze zadnych problemow.

----------

## unK

 *Xywa wrote:*   

> Myśle żeby przestawić na "-march=core2", ale nie jestem pewien czy z tym procesorem moge używać tej flagi?

 

jak sama nazwa wskazuje, ta flaga jest dla procesosów Core Duo, więc owszem.

----------

## SlashBeast

 *unK wrote:*   

>  *Xywa wrote:*   Myśle żeby przestawić na "-march=core2", ale nie jestem pewien czy z tym procesorem moge używać tej flagi? 
> 
> jak sama nazwa wskazuje, ta flaga jest dla procesosów Core Duo, więc owszem.

 

Jak sama nazwa wskazuje, ta flaga jest dla procesorów Core2 (Solo/Duo/Quad), Core Duo _nie_ jest 64bitowy, a ta flaga jest dla 64bitowych procesorw Core2, jednak dla systemu z chostem x86 powinna dac rade rowniez na Core(1).

----------

## soban_

U mnie na lapku z Core Duo dawalo to rade  :Wink:  na (~)x86.

----------

## Xywa

Gento Wiki mówi też:

add +1 per extra core to MAKEFLAGS, i.e.: 

MAKEFLAGS="-j3"

for multi core CPUs

Cytat z:

http://wiki.archlinux.org/index.php/Safe_Cflags#Architecture_Autodetection

Czy gdy nie zrobię MAKEFLAGS="-j3" nie wykorzystam w pełni drugiego rdzenia?

Czy ktoś stosował flage autodetekcji CFLAGS="-march=native"?

Gdy zmienię flagę z nocona na core2, co muszę przekompilować aby zmiany odniosły skutek? Kernel(?) coś jeszcze?

----------

## unK

 *SlashBeast wrote:*   

>  *unK wrote:*    *Xywa wrote:*   Myśle żeby przestawić na "-march=core2", ale nie jestem pewien czy z tym procesorem moge używać tej flagi? 
> 
> jak sama nazwa wskazuje, ta flaga jest dla procesosów Core Duo, więc owszem. 
> 
> Jak sama nazwa wskazuje, ta flaga jest dla procesorów Core2 (Solo/Duo/Quad), Core Duo _nie_ jest 64bitowy, a ta flaga jest dla 64bitowych procesorw Core2, jednak dla systemu z chostem x86 powinna dac rade rowniez na Core(1).

 

no chodziło mi o Core 2 Duo, zapomniałem 2 napisać. Swoją drogą to nawet nie wiedziałem, że istnieje coś takiego jak Core Duo bez 2   :Wink: 

 *Quote:*   

> Gdy zmienię flagę z nocona na core2, co muszę przekompilować aby zmiany odniosły skutek? Kernel(?) coś jeszcze?

 

nic nie rekompiluj, nie ma sensu. no chyba, że lubisz ;p

----------

## soban_

Ponoc Core Duo jest o wiele mniej wydajne, od Core 2 Duo - ja szczerze az tak mocno tego nie odczulem.

----------

## SlashBeast

@Xywa: unK dobrze prawi, nie ma sensu przebudowac systemu, nie licz na wzrost wydajnosci, o ile bedzie, to bedzie tak maly, ze tego nie zauwazysz.  :Wink: 

Ja dla mojego core2 z serii T dalem CFLAGS="-march=core2 -mcx16 -msahf -O2 -pipe -mssse3"

-mcx16 i -msahf dodalem, gdyz march=native je wlacza, msse3 mam by wymusic wszystkie sse, sam nie wiem jak to do konca dziala, moze march jak cos dodaje to tego nie ma juz 'w testach' jako -mno-sse itp, dla pewnosci dodaje.

----------

## soban_

 *Xywa wrote:*   

> Gento Wiki mówi też:
> 
> add +1 per extra core to MAKEFLAGS, i.e.: 
> 
> MAKEFLAGS="-j3"
> ...

 

Ostatnio czytalem wlasnie wypowiedz jednego forumowicza, ze im wiecej -j tym szybciej dana paczka sie skompiluje (oczywiscie -j3 jesli sie ma 2 rdzenie wzor:[ilosc rdzeni + 1]) jednak ponoc jak sie ustawi -j20 to szybciej kompiluje - testowano to chyba na OO, ze ja nie testowalem to sie nie wypowiadam jednak mysle ze to dziala bardziej na zasadzie watkow niz ilosci uzywanych rdzeni. Ja mam wpisane -j5 i mi wystarcza tak samo jak kompiluje jadro (make -j5). 

Ja bym nic nie przekompilowywal po prostu od teraz bedziesz mogl z poprawnie ustawionym cflags szybciej kompilowac  :Smile: 

----------

## lazy_bum

 *Xywa wrote:*   

> Czy ktoś stosował flage autodetekcji CFLAGS="-march=native"?

 

Ja używam, ale nie zauważyłem jakiejś megawydajności (choć mój kernel kompiluje się 0,0001% szybciej! ;)

----------

## Xywa

Z tego co zauważyłem to...

[1] Po przejściu na core2, w opcjach jądra pojawiła mi się opcja już dedykowana dla Core2.

[2] Po dodaniu opcji smp w kerenelu i dodaniu flagi smp - aż 1 pakiet (gimp) zgłosił się że wykorzysta tą opcje  :Smile: 

----------

## soban_

Ile ustawiles w maku MAKEOPTS="-jx"?  :Smile:  - Zawsze to przyspieszy kompilacje.

----------

## dziadu

 *Xywa wrote:*   

> [1] Po przejściu na core2, w opcjach jądra pojawiła mi się opcja już dedykowana dla Core2.

 

Masz chłopie fantazję  :Smile:  A poznikały Ci opcje tyczące się procesorów AMD?

----------

## Garrappachc

Ja mam prescott. Jadę na -j2, bo na -j3 mi się krzaczy system nieprawdopodobnie. A i przy dwójce oba rdzenie mają po 100% przy kompilacji. Mam Core 2 Duo, ale to są 32 bity.

```
garrappachc][~] cat /proc/cpuinfo

processor   : 0

vendor_id   : GenuineIntel

cpu family   : 6

model      : 15

model name   : Intel(R) Core(TM)2 Duo CPU     E4500  @ 2.20GHz

stepping   : 13

cpu MHz      : 1200.000

cache size   : 2048 KB

physical id   : 0

siblings   : 2

core id      : 0

cpu cores   : 2

apicid      : 0

initial apicid   : 0

fdiv_bug   : no

hlt_bug      : no

f00f_bug   : no

coma_bug   : no

fpu      : yes

fpu_exception   : yes

cpuid level   : 10

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 nx lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm

bogomips   : 4421.25

clflush size   : 64

power management:

processor   : 1

vendor_id   : GenuineIntel

cpu family   : 6

model      : 15

model name   : Intel(R) Core(TM)2 Duo CPU     E4500  @ 2.20GHz

stepping   : 13

cpu MHz      : 1200.000

cache size   : 2048 KB

physical id   : 0

siblings   : 2

core id      : 1

cpu cores   : 2

apicid      : 1

initial apicid   : 1

fdiv_bug   : no

hlt_bug      : no

f00f_bug   : no

coma_bug   : no

fpu      : yes

fpu_exception   : yes

cpuid level   : 10

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 nx lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm

bogomips   : 4508.42

clflush size   : 64

power management:

```

----------

## soban_

U mnie w poszczegolnych przypadkach sie krzaczy - jednak wtedy maskuje MAKEOPTS, skompiluje dany pakiet i z powrotem MAKEOPTS odmaskowywuje - do tej pory sie spotaklem z jedna moze dwoma takimi paczkami.

----------

## Garrappachc

Jak kiedyś stawiałem (dwa razy nawet) na -j3, to w Gnomie programy się uruchamiały paręnaście minut (a procesor nic w tym czasie nie mielił, tak samo dysk...), a w KDE mi dźwięk trzeszczał co jakiś czas.

----------

## soban_

A to ciekawe, mi sie nie zdarzylo (pomijajac te wyszczegolnione przypadki) - moze rzeczywiscie cos w tym jest, a co inni na to? Jeszcze mam takie pytanko czy makeopts dziala na zasadzie bardziej watkow czy jest to rzeczywiste wykorzystywanie rdzeni procesora?

----------

## Aktyn

 *soban_ wrote:*   

> Jeszcze mam takie pytanko czy makeopts dziala na zasadzie bardziej watkow czy jest to rzeczywiste wykorzystywanie rdzeni procesora?

 

man make ?

Umiejętność wykorzystania wielu rdzeni procesora jest kwestią programu, a shedulera w kernelu, od ich zarządzania.

Zaraz może założe temat, tylko se musze dane przygotować, bo nie działa mi to coś jak powinno.

Ja mam ostatnio -j5 w make, ale z tego co widze sporo samo emerge zmienia na -j1.

----------

## soban_

Tak samo mam -j5 mimo ze mam 2 rdzenie. Jednak czy ma wplyw na to jak skompilujemy program? Tzn, pytannie brzmi nastepujaco czy gdy skompiluje program z makeopts=-j3 to bedzie on inaczej dzialac niz z -j2 jesli tak to z jakimi parametrami on bedzie szybciej chodzic? I jak to sie ma do szybkosci kompilacji?

----------

## Aktyn

Teoretycznie nie powinno   :Wink: 

W praktyce sam fakt że niektóre programy nie przejdą przez więcej jak -j1 świadczy że coś jest źle.

Więc jeśli ma wpływ, to raczej w wyniku błedu.   :Wink: 

Istnieje jednak możliwość, kiedy ma się TMP na tej samej partycji co system, że np. biblioteki zrobione mogą być pofragmentowane,

i wtedy odczytanie ich zajmie więcej czasu. Co może sie stać, choć raczej nie musi (a przy wolnej przestrzeni dyskowej może nawet nie powinno), przy równoległym zapisie kilku plików. Ale to tak tylko sobie dywaguje. Zależy też pewne od rodzaju fs

----------

## soban_

OK to jeszcze chce uslyszec jedno na temat legend dotyczacych Gentoo, czy kompilacja na wlasnym procesorze kazdej paczki przyspiesza jej dzialanie? Tutaj chce zaznaczyc ze nie chodzi mi o zwiazek z flagami, po prostu czy tlumaczenie dajmy na to z jezyka C/C++ programu na program binrarny przyspiesza jego dzialanie na tym wlasnie procesorze niz sciagniecie samych binarnych paczek? Bo tutaj musi zajsc translacja na jezyk asm danego procka wiec teoretycznie powinien program szybciej chodzic, czy to kolejna legenda?

----------

## SlashBeast

 *soban_ wrote:*   

> OK to jeszcze chce uslyszec jedno na temat legend dotyczacych Gentoo, czy kompilacja na wlasnym procesorze kazdej paczki przyspiesza jej dzialanie? Tutaj chce zaznaczyc ze nie chodzi mi o zwiazek z flagami, po prostu czy tlumaczenie dajmy na to z jezyka C/C++ programu na program binrarny przyspiesza jego dzialanie na tym wlasnie procesorze niz sciagniecie samych binarnych paczek? Bo tutaj musi zajsc translacja na jezyk asm danego procka wiec teoretycznie powinien program szybciej chodzic, czy to kolejna legenda?

 

Gdzies Ty takie legendy uslyszal? Co ma konkretny egzemplarz do wynikowej binarki? Ta Twoja teoria z 'powinien program szybciej chodzic' to dopiero bzdura.

----------

## soban_

Nie moja, lecz kolesia z uczelni tez uwazalem to za glupote ale chcialem sie upewnic. Dlatego nazwalem to 'legenda' - poparl to argumentem ze aplikacje pisane w asemblerze chodza szybciej od tych pisanych w C/C++.

----------

## SlashBeast

 *soban_ wrote:*   

> Nie moja, lecz kolesia z uczelni tez uwazalem to za glupote ale chcialem sie upewnic. Dlatego nazwalem to 'legenda' - poparl to argumentem ze aplikacje pisane w asemblerze chodza szybciej od tych pisanych w C/C++.

 

Wiesz czym jest legenda? Chyba nie do konca.

Poza_tym, co to za pomysl porownywac predkosc niskopoziomowego jezyka jakim jest assambler do C!? Kompromitacja.

Arfrever: Ortografia

----------

## soban_

http://pl.wikipedia.org/wiki/Legenda - "w literaturze opowieść, posługująca się elementami niezwykłości oraz cudowności, związanej z życiem świętych i męczenników." glownie o ten watek mi chodzilo, nawiazanie niby do cudownego kompilowania zrodel na wlasnym procesorze.

Pomysl skad sie wzial: *Quote:*   

> Tworzenie programu w C++ składa się z 4 etapów. Pierwszy etap to edycja. W tym etapie wykorzystywany jest program edytora (np. Notatnik w Windows). Jest to moim zdaniem najważniejsza faza, gdyż tutaj wpisujesz instrukcje, które wykona komputer. Następnie plik z instrukcjami zapisywany jest na dysku. Kolejnym etapem jest kompilacja programu. Kompilacja polega na "przetłumaczeniu" instrukcji w C++ na język wewnętrzny procesora.
> 
> Zanim nastąpi kompilacja wykonywany jest automatycznie program preprocesora. Preprocesor to taki program, który wykonuje instrukcje zwane dyrektywami preprocesora. Zadaniem tych instrukcji jest wykonanie pewnych czynności zanim jeszcze dokonana zostanie kompilacja programu. Te czynności to np. dołączenie innych plików tekstowych. Preprocesor wywoływany jest przez kompilator zanim program zostanie przekształcony na język maszynowy. Ostatnim etapem jest łączenie, na czym to polega ? Otóż programy w C++ składają się z funkcji lub obiektów zdefiniowanych w innych plikach ( np. bibliotekach standardowych). Kod tworzony przez kompilator zawiera puste miejsca, które muszą zostać wypełnione przez funkcje z tych innych plików, tak aby stworzyć program w pełni wykonywalny.

 

http://forum.fedora.pl/lofiversion/index.php/t1409.html

 *Quote:*   

> pesto
> 
> 10 Sep 2004, 22:33 
> 
> joł 
> ...

 

Zastanawia mnie tylko jeszcze jedna kwestia w takim razie, dlaczego ludzie sie spieraja ze openoffic-bin jest wolniejszy od tego kompilowanego ze zrodel?

----------

## SlashBeast

```
-źródła chodzą szybciej niż rpm [binarki] ponieważ są kompilowane pod konkretny procesor [AMD/Intel/VIA/PowerPC] posiadający unikatowe instrukcje 
```

CFLAGS!

----------

## soban_

Uhm, to wracajac do tematu glownego - dlaczego wszyscy napisali ze nie nalezy rekompilowac paczek gdy autor zmienil cflags? Czyli dzieki cflags paczki kompilowane wnioskuje chodza szybciej od bin? Dlatego openoffice kompilowany ma prawo chodzic szybciej od -bin?

----------

## SlashBeast

Przeczytaj posty unK i moje na pierwszej stronie, bylo juz o tym.

----------

## soban_

Faktycznie moj blad, nie przeczytalem z jakiego powodu nie zalecacie rekompilacji. W kazdym badz razie wielkie dzieki za wyjasnienie @SlashBeast i przepraszam za moj brak czytania ze zrozumieniem  :Razz:  czyli wpis w cflags nie tylko skraca czas kompilacji, ale w jakims stopniu (niewielkim) tylko i wylacznie ten wpis przyspiesza dzialanie programow kompilowanych pod dany sprzet jesli wykluczymy flagi...

----------

## Xywa

A czy ma ktoś może linki do stron z jakimiś testami, gdzie ktoś się bawił z różnymi ustawieniami flag, etc - i później sprawdzał efekty.

----------

## dziadu

Wy jednak macie wypaczone pojęcie o Gentoo. Testów jest sporo.

Ale czy dasz flagę nocona czy core2 to to systemowi lata koło ****. Uzysk będzie pomijalny, kilka instrukcji asemblerowych może się przemiesza, doda lub odejmie i tyle. Możesz zyskać na aplikacjach wykorzystujących technologie typu sse ale aplikacja musi też z tych technologi korzystać. Szkoda tracić czasu na to, ustaw standardowe flagi, życie będzie przyjemniejsze. Gdy coś się zepsuje, to z pamiętaj, że z ricerami mało kto chce gadać. Dużo więcej uzyskasz bawiąc się flagami USE - i na tym polega właśnie filozofia Gentoo.

----------

## Xywa

 *dziadu wrote:*   

> Uzysk będzie pomijalny

 To po co te wszystkie sse, mmx, mmxy2 i cała reszta? Po co tyle odmian skoro można przekompilować wszytsko pod i686?

Poniżej wyniki z BYTE UNIX Benchmarks (Version 3.11) dla systemu Intel(R) Core(TM)2 CPU T5200 @ 1.60GHz GenuineIntel:

[1] Bez ustawionych żadnych flag

[2] Dla systemu z -pipe -O3 -fomit-frame-pointer -ffast-math -malign-double -march=prescott -mtune=prescott -msseregparm -msse3 -minline-all-stringops -fgcse-lm -fgcse-sm -fforce-addr 

TEST BASELINE RESULT INDEX

[1] AVERAGE 184.7

[2] AVERAGE 240.4

I wypowiedź autora:

As you can see by using custom CFLAGS I'm getting about a 40% increase in the average speed. You can use BYTE UNIX Benchmark to test your own CFLAGS. Happy tinkering

------ ciach

Polecam też poczytanie (jak na wydajność systemu wpływa optymalizacja tylko jednej flagi i porównanie do i686 Ubuntu):

Gentoo is a source based distribution which lets the user decide how to optimize their system in many ways. Linux Magazine benchmarks three of the most common GCC optimizations; -Os, -O2 and -O3, and throws in Ubuntu for good measure.

Całość tutaj:

http://www.linux-mag.com/id/7574/1/

i konkluzja:

Although we are not comparing apples to apples, Gentoo did out-perform Ubuntu in almost every test, and sometimes by a fair margin. It does appear that optimizing for a specific CPU can yield a decent performance increase.

----------

## dziadu

Pytanie tylko, po co Ci to? Co to był za test? Czy ten wynik jakoś ułatwi Ci pracę z OpenOffice, GIMP-em czy KDE? Jaka była platforma testowa, co wykonywał program testowy? Czy to były miliony obliczeń arytmetycznych, pętli które prawdopodobnie w normalnym programie rzadko kiedy się znajdą.

Jeśli chcesz się bawić w ricerowanie to droga wolna, tylko zauważ, że ja zaproponowałem standardowe flagi typu "-pipe -O3 -fomit-frame-pointer -ffast-math" dorzucić można jeszcze -msse3. I teraz sprawdź jaka będzie różnica między tym zestawem a zestawem nr 2 z Twojego postu.

Postów na forum było wiele o tuningowaniu CFLAGS, wystarczy poszukać. Chcesz zrobić rakietę z samochodu a trzeba Cię za rączkę do Google prowadzić.

Z flagami to jest tak, że trzeba wiedzieć co się włącza a co nie, trzeba wiedzieć jakie są zależności miedzy nimi, bo może okazać się, że ten łańcuszek flag który podałeś można obciąć o połowę i różnicy nie będzie.

W ogóle to temat powinien być w OTW bo z samym Gentoo ma niewiele wspólnego.

Ja już kończę, bo znowu będzie że marudzę (bo marudzę przecież ale nikt tego głośno nie powiedział jeszcze). To było moje 5 groszy do dyskusji która wraca co pół-do-jednego roku, wraz z nową falą użytkowników. A w sumie to się nawet czepiam, i nie wiedzieć czemu  :Shocked:  Tylko żeby tu jakichś głupot nie pisać, bo ktoś jeszcze to przeczyta i wtedy dopiero będzie bigos  :Smile: 

Koniec, miłego dnia!

----------

## soban_

Ja uwazam ze takie tamty sa bardzo potrzebne, rozwiewaja watpliwosci (jesli temat sie powtarza to dziadu zglosc to ewentualnie podaj linka) - chetnie sam odswieze temat, poczytam - czegos nowego sie dowiem. 

Co do tuningowania Gentoo to tak z ciekawosci warto czasami to przegladac - w koncu chyba wszyscy sie pasjonujemy optymalizacja systemu (ja miedzy innymi przez to wybralem Gentoo).

Wcale nie uwazam ze marudzisz i masz w bardzo duzym stopniu racje, moze nie wszyscy jestesmy tak PRO jak Ty w tej wiedzy na temat optymalizacji flag w cflags dlatego chcemy uslyszec opinnie innych, wykazac sie glupota, wiedza i roznymi zbednymi duperelami ktore rozwieja watpliwosci i zwieksza nasze doswiadczenie z Gentoo co moim zdaniem jest bardzo potrzebne.

Co do tematu OTW to sie wogle nie zgadzam, jest to scisle zwiazane z instalacja systemu wiec dlaczego ma byc to porownane do tematu typu - "O slusznosci uczelni" (tutaj mozna zdrowo to powiedziec ze nie jest to praktycznie wogle zwiazane z Gentoo)?

Jesli ktos ma cos do dodania na ten temat i znajdzie nowe testy na konkretnych wynikach programow to z wielka ciekawoscia to obejrze, tez milo byloby uslyszec o czasie kompilacji oraz o flagach ktore powoduja ze system staje sie niestabilny ewentualnie dana aplikacja przestaje dzialac stabilnie - lub daje taki wyniki jakiego bys nie chcieli.

----------

## Xywa

 *dziadu wrote:*   

> Pytanie tylko, po co Ci to? Co to był za test? Czy ten wynik jakoś ułatwi Ci pracę z OpenOffice, GIMP-em czy KDE? 

 

W podanym linku jest cały artykuł ze szczegółami publikowany w Linux Magazine, autor jest twórcą Kororaa Linux i spechjalizuje się w wykorzystania linuxa do grafiki 3D (dlatego bawi się optymalizacją). Co do falg, to wiadomo że są one głównie multimedialne - czyli jeżeli ktoś korzysta z Offfice nic nie odczuje, ale ripovanie czy edycja filmów DVD czy skmplikowane animacje 3D, to już dość chłonne procesy. Tam każde 5-10% lepiej ma znaczenie. W testach powyżej z Linux Magazine różnice w klatkach na sekunde w Unreal Tornamet są do 10%.Last edited by Xywa on Thu Nov 12, 2009 4:34 pm; edited 2 times in total

----------

## no4b

 *Quote:*   

> msse3 mam by wymusic wszystkie sse

 

Dlaczego nie wymuszasz sse4.1?

----------

## SlashBeast

 *no4b wrote:*   

>  *Quote:*   msse3 mam by wymusic wszystkie sse 
> 
> Dlaczego nie wymuszasz sse4.1?

 

Bo moj procesor, core2 serii T (65nm) nie posiada sse4.1.

I chodzilo mi o mssse3, z testow widze, ze automattycznie dodaje to msse(,2,3)

----------

## lazy_bum

-march=native też to wszystko dodaje:

```
./analyze-x86 /usr/bin/mplayer 

Checking vendor_id string... GenuineIntel

Disassembling /usr/bin/mplayer, please wait...

i486: 3599 i586:   18 ppro: 6540 mmx: 119411 sse: 5252 sse2: 1994 sse3:  640 ssse3:  165 sse4.1:    0 sse4.2:    0

```

----------

## lsdudi

 *lazy_bum wrote:*   

> -march=native też to wszystko dodaje:
> 
> ```
> ./analyze-x86 /usr/bin/mplayer 
> 
> ...

 

lazy się popisałeś :], tak przypadkiem mplayer ma flagi do sse w USE'ach masz moze przypadkiem włączone?

```
equery u media-video/mplayer |grep ss

-ass

-oss

+sse

+sse2

+ssse3

```

Kiedyś cos czytałem że wymuszanie użycia sse  dla operacji nie przeznaczonych powodowalo spadek wydajności ale o co chodziło dokladnie i gdzie teraz tego arta znaleźć nie wiem.

----------

## lazy_bum

 *lsdudi wrote:*   

>  *lazy_bum wrote:*   -march=native też to wszystko dodaje:
> 
> ```
> ./analyze-x86 /usr/bin/mplayer 
> 
> ...

 

Owszem ma, mam je też włączone. Z ciekawości sprawdziłem z -mmx, -sse itd. Efekt:

```
Disassembling /usr/bin/mplayer, please wait...

i486: 3599 i586:   14 ppro: 6577 mmx: 6656 sse:  578 sse2:    0 sse3:  634 ssse3:    0 sse4.1:    0 sse4.2:    0
```

Swoją drogą, ciekawe jaką to daje różnicę w wydajności odtwarzania/konwertowania wideo.

----------

