AMD FX-8150 „Bulldozer“ na Linuxu

Phoronix přináší linuxový test procesoru AMD FX-8150 architektury „Bulldozer“. Konstatuje, že díky připravenosti většiny open-source softwaru na vícevláknový běh je CPU dobře použitelné, stejně tak tuto architekturu již umí využít třeba GCC a Open64.

24.10.2011 11:04 | David Ježek | Zajímavý článek

Komentáře

[Mti.]

no...nevim jestli se tak snazili najit alespn par "lepsich" apliakci nebo je to bezne, ale podle tech obrazku to vubec nevypada tak zle, jak tvrdily ty predchozi recenze.

[Jaroslav Kucera]

JJ. Je to o optimalizacích. Když si vzpomenu na blahé paměti Pentium Pro, tak v normálních aplikacích a hrách se na stejně taktované Pentium MMX nechytalo, v serverovém segmentu však ukazovalo sílu. Také se z něj doplněním MMX rozšíření následně stalo Pentium II Ze začátku pro normální smrtelníky architektura na dvě věci. Bull je na tom dnes podobně (teda hlavně ve Woknech ).

[Mandarinka]

Ono pokud si dobře vzpomínám mělo Pentium Pro problémy s tehdy ještě běžným 16bitovým kódem. Tady bych to přirovnal možná spíš k Pentiu 4, ktérému dost prospívalo, když vývojáři použili SSE2 (u Bulldozeru a následníků by měla být stejná situace s FMA4/3).

[Mti.]

sem se dival na ty FMA4/3 a uz ted je mi AMD lito. Neco jako kdysi 3dnow... proste Intel to neimplementuje a pokud nebude kod specialne optimalizovany, bude AMD "zase" ten pomaly a PR oddeleni Intelu zase bude hyrit inovacemi. :-/

[Mandarinka]

Riziko tu je, Intel šachoval ve specifikaci mezi 3- a 4-operandovou verzí FMA... nejdřív to AMD změnilo z FMA3 na FMA4 aby bylo kompatibilní, ale když si to Intel rozmyslel podruhé (zpět na FMA3), tak už bylo pozdě (Intel uvádí FMA až za rok s Haswellem, načasoval to hezky). AMD přidá kompatibiltu s FMA3 asi tak za 3/4 roku s refreshem BD; nicméně v tomto případě bych to neviděl ani pro původní BD tak černě, protože ty instrukce nejsou nějak diametrálně odlišné (prostě u FMA3 musíte navíc přesunout obsah registru, jinak o něj přijdete), takže podporovat vedle FMA3 i FMA4 bude téměř zadarmo, navíc má AMD náskok přes rok.

[Mti.]

podpora je jedna vec, ale i z distribucnich instalaci je videt, co se "pouziva". Vse je kompilovane tak, aby to "nejak" jelo. Kod pro x64 tezil z toho, ze vlastne neexistuje prcesor, ktery by neumel SSE1 (2/3?), takze muze byt zaple. Pro i686 se vicemene porad pocita s Pentium3. (cimz ted s dovolenim ignoruji par" lidi s vlastnim kernelem nebo lfs...aby se to nepletlo)

Takze pokud v distribuci bude receno, ze pro 64bit "SSE3-max", tak maji vsechny samohybne rypadla na dlouhou dobu smulu. (ok, mozna specializovane knihovny budou obsahovat vicero implementaci, ale nejak se mi nechce verit, ze by se do toho nekdo hrnul)

[Peter Fodrek]

Posl man je ovela zaujimavejsie, preco strojovi navrh chipu tak vcelmi nevyhovuje Windows a relativne vyhovuje jadru Linux a jeho aplikaciam. Vysledky sa totiz spolu s clankom dol daju vylozit len tak, ze Linucxove programy su napiane lepsie a standardnejsie ako Windows a jeho aplikacie.

Výkon nových osmijádrových procesorů z produkce AMD (AMD FX) nijak neoslnil nikoho, faktem je, že v reálných aplikacích jen stěží stačí na čtyřjádrové procesory konkurence (Intel). Hlavní (možný) důvod tohoto problému nám odhalí bývalý zaměstnanec AMD, inženýr Cliff A. Maier, který se rozhodl o tom promluvit.

Cliff A. Maier opustil AMD už před lety, zrovna ve chvíli, kdy AMD opustilo ruční způsob návrhu procesorů a adoptovalo automatický proces skrze automatické designovací nástroje. Ty přinesou pozitiva - rychlejší návrh, rychlejší odladění, ale nemohou nahradit "klasickou" ruční prácí techniků. Negativem je horší efektivita a výkon takto navrženého čipu.

Tehdy v době odchodu výše zmíněného inženýra, se AMD snažilo konsolidovat své zaměstnance po koupi ATI a slučovalo vývojové týmy obou společností. Až do této chvíle byly vždy klíčové části procesoru navrhovány ručně, což až dodnes Intel dodržuje. Od této doby se ale AMD spoléhá pouze na automatické designérské nástroje a ručně (pravděpodobně) nenavrhuje nic.

Jaký je problém automatické tvorby návrhu čipů? - Takhle navržený čip je o 20 procent větší, o 20 procent pomalejší a má významně vyšší spotřebu než ručně navržený procesor. http://pctuning.tyden.cz/component/content/article/1-aktualni-zpravy/22268-co-stoji-za-nevykonem-bulldozeru-objasnuje-inzenyr-z-amd

[Mti.]

Otazkou je, jak dlouho to Intel vydrzi nez taky zlenivi. Slozitost se stupnuje.

Pokud se jeden podiva do historie, muze analogii najit i v programovacich jazycich. Assembler, pokud programator opravdu chce, bude efektivnejsi (vykon nebo kod), nez kod v C (o vyssich jazycich nemluve). Dani za to bude to, ze se u velkych projektu dost nadre a nektere optimalizace jsou doslova sebevrazedne, pokud by se mely casem "nepatrne" upravit. Dodnes se toto dilema porad resi na malych jednocipech. A v okamziku, kdy mate jen par kilo na kod a radove stovky bajtu ram, takove rozhodovani ziskava na vaze. Na druhou stranu si jakykoliv vetsi projekt bez C (s inline Assemblerem) nedokazu predstavit

Vyrobci CPU jsou ted na stejnem rozcesti. Kompilatory se postupne zlepsovaly. Da se ocekavat, ze stroje na automaticky navrh pro CPU taky postupem casu zlepsi moznosti. (minimalne vymenou za vyssi vypocetni vykon, ale toho je cim dal vic)

Je mozne, ze "male" AMD si uz proste armadu "assmebleristu" nemuze dovolit. Automaticky navrh jim umozni udelat "rychlej" slozitejsi stroj. :-/

[Mandarinka]

To vysvětlení s automatickým návrhem je to takové populární klišé, na kterém může být něco pravdy, ale skutečnost je o dost složitější, než jak to lama papouškují.

Koukněte na thread odkazovaný v tomhle tvídu: link

[David Ježek]

...než jak to lama papouškují.

ale fuj, jak to o panu Obrovi mluvíš!

[Mandarinka]

Já myslel spíš tu masu anonymních lam co papouškují například ty staré posty C. Maiera z apple insideru (sic...). I když je fakt, že Z.O. to nejspíš linkoval taky, to by mu bylo podobné. Když si přečtete ty příspěvky co jsem linknul, tak to hned je komplikovanější - automatiku používá i Intel, je to vlastně zhola nezbytné, K7/K8 ani zdaleka nebyl plně ruční design a ani Intely posledních desti let nejsou; a naopak, BD není plně automatický, etc...

Podobně pitomou tendencí je i připisovat nízký výkon BD jádra pamětem cache. Ale ruku na srdce, pochybuju že by to bylo tak jednoduché. Všichni ti pytlíci postující na různých fórech o věci ví naprosté hovno. Nejenže prostě blbě 'retvítují' cizí 'retvíty', ale co je horší, nejsou schopní se nad věcí nejdřív elementárně zamyslet.

Taky se hodně hřeší na to, aby se u každé informace zřetelně uvedlo, jestli je to domněnka, podložené, etc. To je pak internet plný plků a legend.

RAAAANNNNTTTTT....

[kapo]

Jsem zvědavej na ty další články, který by měly osvětlit i vliv optimalizací...

[Honz]

Chápu to správně, že by mělo být zvlášť linuxové jádro s optimalizacemi pro Bulldozer a zvlášť pro intel?

[Mti.]

A nejlepe i veskery kod, ktery to muze umet vyuzit by mel byt kompilovany pro buldozer... a to je mene realne.

[vencour]

Gentoo rules again?

[Mandarinka]

Ani ne, košer je spíš mít v programu detekci cpu, která vybere z několika možností ideální kód. Dělá to tak ffmpeg a x264, například. Ale v jejich případě je to spojeno s tím, že mají kritické SIMD části napsané (ve více verzích) v asambléru.

[Mti.]

coz je presne to, ceho se asi masove nedockame... malokdo by na to mel nervy.