Hlavní stránka Hardware Procesory, paměti Architektura procesorů Nehalem (2/2)
Architektura procesorů Nehalem (2/2)
autor: Petr Koc , publikováno 4.9.2008
Architektura procesorů Nehalem (2/2)

Nehalem bude první masově nasazovaný procesor Intelu, který bude integrovat řadič pamětí blízko procesoru. Tím ale výčet novinek nekončí. Inženýři se při návrhu zaměřili také na návrh samotné výpočetní části a kompletně předělali také návrh cache subsystému. Pojďme se podívat, v čem budou největší změny samotné architektury procesoru.


Jak vidno, Nehalem není principielně žádná velká revoluce. Je to spíše oprášení některých konceptů známých z Pentia 4 a jejich integrování do architektury Core + okopírování konceptu integrovaného řadiče RAM od AMD.

Architektura procesorů Nehalem (2/2)
Celkové schéma procesoru Nehalem


Přesto se domnívám, že Nehalem se po uvedení s přehledem stane nejrychlejším procesorem na trhu a to zejména v oblasti multithreaded software – tedy u serverů a pracovních stanic. Prostřednictvím integrovaného paměťového řadiče Intel konečně odbourá poslední vážný nedostatek architektury Core – vysokou latenci při náhodném přístupu k datům, která se nevešla do cache.

Na druhou stranu se nabízí otázka, co Nehalem přinese běžným uživatelům. V některých případech (třeba u Photoshopu náročného na propustnost pamětí) určitě vyšší výkon, v mnoha jiných ale přínosy nebudou až tak razantní a místy dokonce může dojít v důsledku změn k poklesu výkonu, byť to bude spíše výjimečná situace. Jednoduše řečeno Nehalem nepřináší ani nic úžasně převratného, jako tomu bylo u Core (fúzování instrukcí, spekulativní načítání potenciálně aliasovaných paměťových adres, 128bit SSE jednotky), ani nijak rapidně nezvyšuje frekvence. Majitelé stávajících procesorů architektury Core patrně nebudou mít mnoho důvodů k upgrade, pokud tedy zrovna nepoužívají silně multithreaded aplikace.

Co se dle mého na Nehalemu opravdu povedlo?

  • Integrovaný paměťový řadič odbourává hlavní nedostatek současné platformy. Pro integrované grafické karty sice znamená určité nevýhody, na druhou stranu očekávaná integrace GPU do procesoru tento problém odstraní. Navíc od integrované grafické karty asi sotva lze čekat nějaké převratné výkony.
  • Větší instrukční okno znamená lepší možnosti paralelizace.
  • Fúzování instrukcí funguje i v 64bit režimu.
  • Turbo mode – konečně aspoň maličké zlepšení pro neoptimalizované aplikace.
  • Zavedení konceptu NUMA, kde s každým CPU přibývá osaditelné množství paměti i jejich celková propustnost (u serverů).
  • Hyper-Threading (u serverů; u desktopů je lepší ho vypnout).

Hovořit o tom, co se na Nehalemu nepovedlo, je ještě před jeho uvedením troufalé. Přesto si dovolím v několika bodech shrnout hlavní „nedostatky“:

  • Procesor je striktně zaměřen na multithreading. To je sice skvělá zpráva pro servery, ale již méně pro desktopy, kde stále většina aplikací je jednovláknová a nic nenasvědčuje tomu, že se to v blízké době změní. Na architektuře Nehalemu je vidět, že multithreadovému výkonu ustupuje výkon na jedno jádro – cache je oproti Core pomalejší a fyzické jádro sdílí prostředky mezi logická jádra, v některých případech dokonce ne na bázi konkurence, ale na bázi pevného rozdělení zdrojů na polovinu.
  • Počáteční úvodní frekvence jsou pouze na stejné úrovni jako u předchozí generace procesorů a to při podobné / vyšší spotřebě. To může znamenat, že aplikace, které nejsou schopné těžit ze zlepšení (tj. zejména aplikace, které nejsou příliš závislé na rychlosti přístupu k paměti) a které by naopak těžily z vyšších frekvencí, na novince nepoběží o mnoho lépe než na současných generacích.
  • Využití Hyper-Threadingu je stále v mnoha ohledech diskutabilní. Opět je to vynikající věc pro servery, ale u desktopů vede k velmi nepříjemnému fenoménu ignorování priorit procesů, tedy situaci, kdy jsou potírány snahy uživatele / operačního systému o přidělování výpočetních prostředků na základě potřeb. Obávám se, že dokud tento problém nebude vyřešen (a to může být pouze na úrovni spolupráce výrobce CPU + programátora operačního systému), bude stále lepší Hyper-Threading vypnout, stejně jako v dobách Pentia 4.

A to je pro dnešek všechno, na pokračování článku s reálnými testy výkonu budete muset počkat až na konec NDA začátkem příštího měsíce.
 

 



Tagy: Nehalem  Intel  architektura  procesor  Core i7  


 
Komentáře k článku
RSS
Pouze registrovaní uživatelé mohou přidat komentář!
4.9.2008 09:01:30   193.108.106.xxx 131
nejak jsem nepochopil argument autora ze pres vetsi velikost cache snizili asociativitu. Je to prave naopak. Vyssi asociativita znamena komplexnejsi ridici obvody cache (multiplexery) a take zpravidla vetsi latenci. Naopak vetsi cache klidne i pri nizzsi asociativite muze znamenat vyssi vykon.
4.9.2008 09:10:46   193.108.106.xxx 100
jeste jsem zapomel zminit jednu vec a to je, ze pri velkych velikostech cache zvyseny stupen asociativity neprinasi zadny zazracny narust vykonu, naopak to zeslozituje navrh cache.
4.9.2008 09:10:46   193.108.106.xxx 110
jeste jsem zapomel zminit jednu vec a to je, ze pri velkych velikostech cache zvyseny stupen asociativity neprinasi zadny zazracny narust vykonu, naopak to zeslozituje navrh cache.
4.9.2008 09:10:46   193.108.106.xxx 110
jeste jsem zapomel zminit jednu vec a to je, ze pri velkych velikostech cache zvyseny stupen asociativity neprinasi zadny zazracny narust vykonu, naopak to zeslozituje navrh cache.
4.9.2008 21:46:09   213.220.244.xxx 120
Nevím, že bych někde tvrdil, že větší cache má menší asociativitu. To z článku snad nevyplývá. Jediné, co jsem tvrdil, že Intel v Nehalemu sice bude mít 8 MB cache, ale ta bude navržena s menší asociativitou, než 6 MB cache Penrynu.
4.9.2008 22:27:07   62.245.80.xxx 120
cituji "L3 cache hrozivě pomalá a dokonce má i přes větší velikost menší asociativitu než L2 u Penrynu!" z toho je to jasne. Pokud byste znal jak se cache realizuje tak vite ze na vyssi stupen asociativity potrebujete krome spousty komparatoru a multiplexeru i vice pameti pro tagy datoveho bloku. Takze spravne tvrzeni by spise bylo: "Intel se rozhodl pro nizsi stupen asociativity a diky tomu ziskal navic misto na cipu pro vetsi velikost cache"
4.9.2008 22:40:27   213.220.244.xxx 101
S tímto tvrzením nemůžu souhlasit. Podle mého je cache v Nehalemu horší než u Penrynu. Jestli Intel potřeboval zmenšit množství tagů, aby mohl zvětšit velikost, to je mi upřímně řečeno jedno. Výsledek je pro mě jasný - nová cache je sice o 33 % větší, ale taky 3x tak pomalá a má horší asociativitu. Z toho mi tak nějak vyplývá, že hit rate může být podobný (větší velikost, ale menší asociativita) a to při třetinové rychlosti. Celkově tedy jednoznačně mínus.

Trošku off-topic: je zajímavé sledovat, že Intel cache skládá z bloků včetně tagů a asociativity. Penryn má 6 MB při 24-way, Conroe má 4 MB při 16-way, Conroe-2M jsou 2 MB při 8-way, Conroe-1M je 1 MB při 4-way a Conroe-512K je dokonce 512 kB při 2-way. Se snižující se velikostí je tak odrovnávána nejen účinnost vyplynoucí z kapacity, ale také účinnost plynoucí z asociativity. AMD s menší cache asociativitu zachovává.
4.9.2008 22:53:09   62.245.80.xxx 102
hm, no nevim, asi zapominate na to, ze je tam stale ta L2 cache, ktera je naopak RYCHLEJSI, troufam si tvrdit ze L2, ackoliv je vyrazne mensi, tak pri o tretine nizsi latenci (4T) muze klidne dosahnout stejnych vykonovych parametru, protoze s rostouci kapacitou u techto velikosti jiz neprinasi razantni snizeni cache miss.
4.9.2008 22:54:07   62.245.80.xxx 102
upresneni, ta latence nove L2 je 10T misto 14T
4.9.2008 23:02:54   62.245.80.xxx 101
k te asociativite, to muze byt taky jen marketingova hra, aby levnejsi procesory proste byly v benchmarcich viditelne pomalejsi. Krome toho bude taky vyssi vyteznost, protoze pri nizsi asociativite jsou na cache kladeny mensi naroky. Pokud si dobre vzpominam tak podobna situace byla u Tualatinu, tehdy L2 cache PIII mela krome dvounasobne velikosti i dvounasobny stupen asociativity,
4.9.2008 22:44:52   62.245.80.xxx 101
jinak pokud se jednalo pouze o nevhodne zvolenou formulaci, tak se omlouvam za pripadne rypani ;-) pro me to bohuzel vyzniva ze vetsi cache musi mit nutne vyssi stupen asociativity. Osobne bych rekl ze tento navrh byl vytvoren na zaklade simulaci realneho kodu a proste takto navrzena triurovnova architektura je pravdepodobne pro tento procesor, s ohledem na technologii, nejefektivnejsi. Taky zde neni zminena velikost datoveho bloku s tou mohli take pohnout...
5.9.2008 07:43:27   213.220.244.xxx 101
V pohodě, jako nevhodnou formulaci to určitě neberu. Datový blok by snad stále měl mít 64 byte, tahle hodnota se neměnila ani v Pentiu 4, kde byl velmi agresivní prefetch (2x 64 byte). Větší mi přijde, že už by nebyly efektivní.
4.9.2008 09:01:55   62.157.116.xxx 164
''Například u Pentia 4 Prescott činila statická spotřeba až 62 Ampér, tedy více než polovinu z maximálních 119 Ampér.''

Je na teto vete opravdu vsechno v poradku?
4.9.2008 10:27:48   88.101.37.xxx 147
No co. Clovek, ktery si mysli, ze klicove slovo for v C se pise s velkym f a ze se ve vyctu polozek uvnitr zavorku u tohoto klicoveho slova pouziva carka a ne strednik, dovoli si tvrdit, ze vetsina cyklu se vejde do 28 micro ops, nenapadne ho, ze 4-issue tam je kvuli hyperthreadingu atd., atd. , ten si klidne muze myslet, ze ampery jsou jednotkou spotreby.
4.9.2008 11:29:23   212.111.28.xxx 95
K poznamce, ze Windows stejnemu procesu prideluje pokazde jine jadro: Ve spravci uloh je mozne pro kazdy proces urcit jadra, ktere mu muze pridelit. Ja jsem pri tom zjistil, ze kdyz na mem Athlonu 64 X2 4850e zakazu CPU1, vykon aplikace (deshaker filtr ve virtualdubu) se nezmeni, ale teplota je podstatne nizsi. Zakazani CPU2 nema vliv na teplotu. Mate nekdo podobnou zkusenost?

BTW spotreba proudu se meri v amperech, benzinu v litrech. Vim, jake 'f' se pise ve 'for' v C.
4.9.2008 11:49:40   62.141.0.xxx 101
Co jsem se docetl v nejakym foru (uz bohuzel nevim, kde to bylo ), tak se jedna o bug v sheduleru OS W-XP SP2, s tim, ze snad SP3 by to melo resit.

Jinak, moje zkusenost je ne sice se snizenim teploty, ale spis se mi nerozjede IDA, tedy 200MHZ+ k maximalnimu taktu 2.4G (T7700). Mohlo by to souviset, protoze to jedno jadro musi byt hodne malo, resp. vubec vytizeny.
takze, pokud ho OS porad utilizuje, nemuze se dostat do uspornyho stavu, aby to druhymu umoznilo se pretaktovat. Ale to je jen moje domenka.
S afinitama jsem sice zkousel laborovat, ale pokazdy klikat na spousty procesu je trosku pruda.
5.9.2008 00:21:34   86.49.83.xxx 112
Existuje nejakej patch na tohle "rotovani" procesu i pro XP x64 nebo 2003 Server?

Snazil jsem se o tomhle debilni jevu zjistit neco v EN, ale stranky MS jsou zticha a vseobecne je tak odbornej, ze vetsina lidi ani netusi, ze je to chyba v chovani scheduleru.
Docela by me zajimalo, jak moc to clouma se spotrebou na phenomu. Tam by mel bejt vliv este mnohem vetsi nez u C2D.

Nekdy by MS vazne zaslouzil kopnout do *****.
5.9.2008 07:41:34   213.220.244.xxx 91
Plně funkční oprava určitě neexistuje. Zkuste ale nainstalovat patche, třeba se to trochu zlepší - http://thehotfixshare.net/board/index.php?autocom=downloads&showcat=14
4.9.2008 11:53:27   62.141.0.xxx 142
jinak, mozna nekdo spotrebu proudu skutecne meri v amperech.
Ale, zkuste nekdy neco takovyho rict u ZK na FELu a o vasem osudu je rozhodnuto...
4.9.2008 11:56:26   193.108.106.xxx 122
jenom upresneni, autor si asi predstavuje ze windows "hloupe" prehazuji proces mezi jadry jen tak pro nic zanic. To neni pravda, fakticky dochazi k prepinani mnohatisickrat za sekundu, rika se tomu kontext switch a ten nastava ve chvili kdy scheduler priradi CPU jinemu procesu. Druha otazka je, na jakem procesoru uspany proces opet obnovi. Je spatne kdyz ho obnovi na jinem procesoru kdyz ten jeho "puvodni" je zrovna v tu chvili vice zatizen? ja bych rekl ze ne.... druha vec je, jak je to v tu chvili s efektivitou vyuziti nesdilene cache, tuto informaci OS nema a ani nemuze mit!
4.9.2008 18:06:28   213.192.56.xxx 91
Me by vubec zajimalo jak bude fungovat ve Windows to odpojovani jader, kdyz Windowsy prubezne rozdeluji procesy mezi vsechna jadra, takze porad jsou vsechna aspon trochu zatizena. V jake chvili se teda bude moct nejake odpojit, pokud s tim Windows nebudou pocitat?
4.9.2008 21:59:25   213.220.244.xxx 110
To je věc k diskuzi, každopádně stav bude takový, že jádro, byť bude odpojeno přes Power Gate, se stále bude hlásit operačnímu systému, a proto minimálně některé jeho části budou muset být v pohotovostním režimu. Případný cache flush před odpojením přes Power Gate (pokud bude vyžadován) může trvat natolik dlouho, že než se jádro připraví k odpojení, Windows mu přidělí další úlohu. S HTT to bude ještě horší.
5.9.2008 08:02:15   62.141.0.xxx 101
no, prece CPU hot swap uz na svete, aspon v oblasti serveru, nejakou dobu je, tak proc by MS nejakou podobnou ficuru nemhly implementovat ? urcite by to bylo uzitecnejsi nez nejaky Aero apod. omalovanky, ktery sice sou pekny, ale prakticky k nicemu a jen zerou vykon/pamet
4.9.2008 21:53:24   213.220.244.xxx 100
O kontext switch nejde, je to o obnovení vlákna, jak jste nastínil. Určitě to není jednoduchá problematika, nicméně mělo by přece platit, že OS by se měl snažit obnovit proces na jádře, ze kterého ho předtím vyhnal. Jinak totiž dochází k obrovskému množství cache miss, které vedou leda tak k tomu, že než se vlákno opět rozeběhne, bude to docela dlouho trvat. Mám změřeno, že pokles výkonu tímto způsobený činí asi 1 až 2 %, což je při dnešním (ne)růstu výkonu CPU strašně moc. Navíc přesun dat mezi cache způsobí zátěž na cache subsystém, a tedy zpomalení i ostatních threadů, takže v případě plného vytížení je to ještě horší.

Mimochodem, ono nejde jen o proces, ale také o samotné thredy, při jejichž přehození (což uživatel nemůže nastavením ovlivnit... pominu-li stanovení afinity přímo threadu v programovém kódu) dojde k velkému množství cache miss.
4.9.2008 22:35:24   62.245.80.xxx 100
jasne ze OS rozdeluje cpu defacto jednotlivym vlaknum, procesy jsem zvolil pro zjednoduseni, princip je stejny. Je jasny ze pokud budu prepinat vlakna jednoho procesu tak bude zrejme vyhodnejsi ho obnovit na stejnem jadre. Zajimavejsi otazka k diskuzi by byla jestli on-line pocitani vyhodnosti obnoveni vlanka na konkretni cpu neprinese vetsi skodu nez uzitek. Uvedomme si, ze opravdu ve chvili kdy chceme konkretni vlakno obnovit muze byt jeho puvodni jadro mezitim zamestnano jinym procesem. Jak pak urcime jestli je vyhodnejsi tento proces presunout na druhe jadro nebo ho spustit na tom puvodnim? OS by musel on-line analyzovat spousteny kod a podle toho odhadovat aktualni vyuziti cache a to nebude zadarmo.
5.9.2008 07:46:44   213.220.244.xxx 101
A co třeba evidovat, kolik proces spotřeboval v posledních pár milisekundách času? Pokud by spotřeboval hodně, pak by to mohlo naznačovat, že bude ještě hodně času potřebovat. Nové procesy (... s potenciálně krátkou dobou běhu) by se přidělovaly jednomu jádru (byť i třeba s určitým čekáním) a starý proces s velkým vytížením nerušeně druhému.
5.9.2008 09:17:38   62.141.0.xxx 102
nechci rejpat, ale... pokud namerim rozdil 1-2%, tak bych se mozna spis zamyslel nad tim, jestli 1) mam pro obe mereni uplne stejny podminky, 2) jaka je presnost mereni, ktery provadim. prece jen, 1-2% mi pripadaji jako prijatelna chyba... ?

navic, cekal bych, ze prave mezicachovej traffic se znacne zredukuje prave tim ,ze nektery cache jsou sdileny a v pripade Intelu inklusivni.
5.9.2008 18:24:52   213.220.244.xxx 101
ad 1) Ano, podmínky úplně stejné, protože se prostě v BIOSu druhé jádro vypnulo. Tedy úplně stejný HW i SW, jediný rozdíl byl počet zapnutých jader.

ad 2) Přesnost měření je taková, že opakování testu generuje přesně stejné výsledky, což vzhledem k reportované jednotce (sekundy) znamená maximální nepřesnost menší než 1 sekunda z času nějakých 100 až 130 sekund. Měření bylo provedeno na dvou procesorech a výsledkem byl pokles výkonu o cca 1 až 5 %.


U Intelu jsou ale sdíleny jen L2 cache, u Nehalemu dokonce až L3. Není sdílena L1. A právě že při rychlém střídání procesů a jejich přehazováním jinam se nejdřív musí do L2 zapsat upravené výsledky z L1 prvního CPU a pak se tyto výsledky musí dostat z L2 do L1 druhého CPU. To stojí hrozně moc výpočetního času.
5.9.2008 08:06:29   62.141.0.xxx 91
kontext switch neni o probuzeni se na nejakym jinym CPU, ale o tom, co vsechno se deje, aby se v konecnym case vystridaly vsechny procesy, aby zadny 'nehladovel'.. a je jedno, jestli jde o uni/multi-proc. masinu. kontext je proste stav vsech registru v danym case (nejen GPR, ale i EIP apodobnych, ktery nejsou primo pristupny)
5.9.2008 09:35:47   147.32.127.xxx 100
kolego, ja vim co je kontext switch, ale je na vuli scheduleru na jakem procesoru vlakno/proces spusti, protoze cely jeho stav je ulozen v hlavni pameti, ktera je pristupna vsem procesorum stejne.
5.9.2008 09:40:36   62.141.0.xxx 100
ok, nic ve zlym. ale vypadalo to, jako ze povazujete kontext switch za proceduru, kdy se prave proces zmigruje na jiny jadro... takze, uz si pravdepodobne rozumime ;-)
5.9.2008 09:58:18   62.141.0.xxx 120
jeste uprava, ne ze se zmigruje, ale ze prave v tu dobu migruje jinam.
5.9.2008 10:54:04   147.32.127.xxx 90
ano, v dobe kdyz je proces schedulerem vypnut se nachazi pouze v hlavni pameti, navaznost na puvodni jadro je pouze v moznosti existence nejakych relevantnich dat v cache konkretniho jadra, kterou si ale myslim ze nema cenu schedulerem vubec zjistovat, dopad na vykon muze byt nemaly a navic bude opravdu velmi zalezet na konkretni architekture procesoru, poctu cachi, jejich velikosti, asociativity, velikosti bloku, inkluzivite atd. atd... muselo by se to realizovat primo v HW aby to melo vubec smysl.
5.9.2008 11:04:40   62.141.0.xxx 100
je fakt, ze aby scheduler jeste zjistoval, jestli proces nema v nejaky cachi data, a proto se ho snazil opet probudit na stejnym jadru, je nesmysl.
Ale, slo spis o to, ze nekdy ty procesy migruji vic, nez by bylo ptoreba, protoze ani jedno jaro neni vytizeny tak, ze by nestihalo. sice pohled scheduleru muze byt jiny.. ale, snad by nebyl problem mit nejakou bitovou masku, ktera by rikala, na kterym jadre proces posledne bezel. zaroven scheduelr musi mit prehled o utilizaci jader.
z toho si myslim, ze uz by mohl nejak dat dohromady, na kterym jadru proces opet probudit, ne ? proste, kdyz jsou obe jadra vytizeny na 10%, tak mi to prijde divny a radsi bych jedno mel na treba i 25% a druhy v nejakym spacim stavu. zrovna na NB by to mohlo byt znat, na desktopu to v podstate muze byt jedno.

ale jeste me napadlo, s tim, ze jak intel, tak amd se sunou smerem k NUMe, tak probuzeni na jinym jadru muze dost zvysit latenci (pristup k pameti adresovane jinym procesorem). resp. ne jadru, ale procesoru.. ale nevim, jak ma scheduler namapovany vlakna/jadra/procesory. na tom asi bude hodne zalezet
5.9.2008 11:11:28   147.32.127.xxx 101
tak tahle otazka je balancovani nad celkovym vykonem a latenci pridelovani procesoru a ne nad vyuzitelnosti cache. Primarne jde o to ze samotne prepnuti kontextu je pomerne narocna zalezitost, takze je potreba jeho pocty minimalizovat, ale zase ne za cenu zvyseni latence. Vemte si napriklad ze hloupa mys, ktera ma frekvenci 200Hz, techto prepnuti vygeneruje minimalne 200 za sekundu a neni to jen o mysi, muzete na pozadi stahovat soubor, takze Vam minimalne kazdy frame vyvola dalsi prepnuti...
5.9.2008 11:17:13   62.141.0.xxx 91
ja to chapu, ze tech prepnuti je hodne. jde mi o to, jaky vsechny faktory ten scheduler umi vzit v uvahu. kdyz budu mit 2nehalemy, tak uz je velky rozdil, jestli kdyz se proces probudi na jadre druhyho procesoru, kterej je sice treba nezatizenej, ale do pameti, kterou proces ma alokovanou stejne poleze jako do vzdaleny.
takze, jsem zvedav, co s tim MS udela, nebo jestli uz na to mysleli a Visty to maj nejak vychytany (zavolaji treba CPUID a podle toho zvoli strategii scheduleru?), nebo se bude cekat treba na SP2.
V linuxu by to snad takovej problem byt nemel, tam se novy verze kernelu objevuji celkem casto, ale s frekvenci vydavani SP se bojim, ze nehalem jeste nejakou dobu nebude moct ukazat, co vlastne umi
5.9.2008 18:35:31   213.220.244.xxx 91
Jde primárně o to, že logická úvaha je taková, že přesunem na jiné jádro OS způsobí latence v důsledku cache miss (a to, jak se ukázalo z reálných měření, nikoli zanedbatelné). Systém má přehled o utilizaci paměti procesem (alokace RAM probíhá voláním funkcí OS), tak by přece mohl sám vyvodit, že aplikace, která alokuje větší objemy dat bude při přesunu do jiného jádra značně zpomalena vznikajícími cache miss, a proto by mohl klidně počkat na uvolnění původního jádra. Přijde mi, že je lepší mít latence na úrovni kontext switch, než pak způsobit ještě větší latenci na úrovni cache miss.
4.9.2008 11:56:26   193.108.106.xxx 101
jenom upresneni, autor si asi predstavuje ze windows "hloupe" prehazuji proces mezi jadry jen tak pro nic zanic. To neni pravda, fakticky dochazi k prepinani mnohatisickrat za sekundu, rika se tomu kontext switch a ten nastava ve chvili kdy scheduler priradi CPU jinemu procesu. Druha otazka je, na jakem procesoru uspany proces opet obnovi. Je spatne kdyz ho obnovi na jinem procesoru kdyz ten jeho "puvodni" je zrovna v tu chvili vice zatizen? ja bych rekl ze ne.... druha vec je, jak je to v tu chvili s efektivitou vyuziti nesdilene cache, tuto informaci OS nema a ani nemuze mit!
4.9.2008 11:56:26   193.108.106.xxx 101
jenom upresneni, autor si asi predstavuje ze windows "hloupe" prehazuji proces mezi jadry jen tak pro nic zanic. To neni pravda, fakticky dochazi k prepinani mnohatisickrat za sekundu, rika se tomu kontext switch a ten nastava ve chvili kdy scheduler priradi CPU jinemu procesu. Druha otazka je, na jakem procesoru uspany proces opet obnovi. Je spatne kdyz ho obnovi na jinem procesoru kdyz ten jeho "puvodni" je zrovna v tu chvili vice zatizen? ja bych rekl ze ne.... druha vec je, jak je to v tu chvili s efektivitou vyuziti nesdilene cache, tuto informaci OS nema a ani nemuze mit!
4.9.2008 12:25:24   212.111.31.xxx 110
Moc pěkný článek, jen bych se chtěl ujistit, jestli v procecorech Nehalem skutečně bude obsažen "tříkrálový" paměťový řadič ;)?
4.9.2008 13:16:00   89.111.89.xxx 111
Souhlas, moc pekny clanek. Ten "trikralovy" pametovy radic skutecne zasobuje 16 stupnu "piperine" ;)
4.9.2008 21:38:09   213.220.244.xxx 100
Ach ty automatické opravy. Poprvé jsem to nepsal v HTML a jak to dopadlo... díky.
4.9.2008 13:27:16   80.87.222.xxx 130
Konecne silno odborny clanok na PCT. Drza otazka - nepisal ho Eagle?

Mam malu pripomienku, na tretej strane, druhy odstavec sa autor pozastavuje nad konceptom 4-issue procesora, ze je to mrhanie paralelizomom. To nie je celkom pravda. Treba si uvedomit, ze jedna x86 instrukcia moze byt rozlozena na niekolko uOps, takze posielanie az 4uOps do pipeline je velmi rozumne.
4.9.2008 22:05:19   213.220.244.xxx 101
Ono jde o to, že drtivá většina aplikací má IPC kolem 1 (na x86). Paralelismus u nich tedy moc neexistuje. Čím větší počet microOPs za takt, tím menší využití. U dnešních procesorů platí, že průměrné využití výpočetních jednotek je asi 30 % (možná teď se spekulací u načítání u Core a Nehalemu trochu víc). Samozřejmě můžou nastat špičky, kdy se hodí 4 microOPs za takt, ale moc jich asi nebude. A je otázkou, zda takto široký paralelismus neomezuje frekvenci a nevnáší do návrhu přílišné množství chyb (širší paralelismus zvyšuje komplexnost čipu exponencielně). Ono třeba na Itaniu je vidět, že s paralelismem to opravdu přehnali, tím si zablokovali možnost mít vysoké frekvence a dneska i Xeon s mnohem menšími výrobními náklady je podobně rychlý jako Itanium (... což určitě není úplně nejlepší vizitka).
5.9.2008 08:13:14   62.141.0.xxx 121
no, tam hodne zalezi co bezi za aplikaci. prece jen, xeon je mnohem dostupnejsi nez itanium a nasazujou se na uplne jiny masiny.
Je ale fakt, ze tam se spolehalo prave na to, ze kompilator dokaze generovat dostatecne paralelni kod, coz ne vzdycky jde - proste nema tolik informaci o kodu, jako ten, kdo ho stvoril, coz neprekvapi.
5.9.2008 22:55:12   89.111.89.xxx 101
bezny x86 kod 4-issue procesor moc nevyuzije (IPC ~ 0.8-2)
samozrejme lze uvest specialni pripady, napr. nasledujici kod muze mit IPC ~ 3
INC EAX
INC ECX
INC EDX
lepsi vyuziti 4-issue procesoru s beznym kodem ma zajistit zde zatracovany SMT (HTT)
4.9.2008 15:00:54   77.104.245.xxx 103
Nesouhlasím s názorem, že bylo lepší HT u P4 vypnout. Už tehdy nabízelo HT mnohé z toho co dnes dvojjádra a co se týče odezvy, ta byla i proti C2D daleko lepší. Pokud by byly i C2D s HT měl bych ho znovu právě kvůli odezvě systému, takhle mě ale do 4 jádra nic netlačí
4.9.2008 21:44:17   213.220.244.xxx 121
Odezvu to zlepší, ale právě na úkor ignorování priorit. A to radši shodím méně důležitý program na nízkou prioritu, než abych priority ignoroval. S nízkou prioritou nelze z hlediska odezvy poznat rozdíl mezi jednojádrem a vícjádrem, zatímco ignorování priorit citelně poznám na výkonu.

Dle mého je HTT vhodné jen pro úlohy se stejnou prioritou, kde ignorování priorit logicky nevadí. U vícjádra může dokonce HTT vést k dramatickému poklesu výkonu - schválně se podívejte po Internetu na testy Pentia Extreme Edition (čipu Smithfield) proti Pentiu D stejné frekvence - často je Déčko rychlejší a to z toho důvodu, že máme-li např. 2 thready a OS je přidělí jednomu fyzickému CPU s HTT, tak to samozřejmě musí dopadnout hůř, než když je přidělí dvěma fyzickým CPU bez HTT.
5.9.2008 08:17:16   62.141.0.xxx 101
nevim, jak to je na win s ignorovanim priorit pri zapnutym HTT. Kazdopadne, na Linuxovym serveru, kterej bratr spravoval, takovydle problemy nemeli. proste nice -n a bylo vymalovano. treba kdyz se kompilovala nejaka velka obluda (OOo, X, glibc), dostal tendle proces velkej nice a makalo to celkove tak o 30% rychleji nez s vypnutym HTT.
Je ale fakt, ze to vyuziti je uplne jiny, nez asi vetsina lidi provozuje doma
5.9.2008 08:20:55   62.141.0.xxx 111
jinak, kde se vlastne vzalo to srovnani SMT = HTT ? vi se ze nehalem bude podporovat beh 2vlaken na jednom jadre, coz ale nemusi nutne znamenat, ze je to ten samej princip ve vsech ohledech a tedy, ze se to bude chovat uplne stejne, nebo ?
5.9.2008 18:15:08   213.220.244.xxx 91
Možná si nerozumíme - ignorování priorit je věc, která se nedá řešit na úrovni software. Musí tím tedy trpět i Linux, protože je to vlastně hardwarová závada. Řešení této vady by vyžadovalo úpravy operačních systémů a zřejmě i nějaký standardizovaný přístup k řízení priorit na úrovni hardware. Nic takového Intel ani MSFT neudělali.
5.9.2008 20:01:31   77.104.245.xxx 92
Diskutujeme o Intelu, nikoliv o AMD to má technologii HTT (HyperTransporT). Samozřejmě vím, že ta rychlá odezva byla na úkor ignorování priorit, ale mě to nikdy nijak neomezovalo, ba právě naopak, pokud jsem potřeboval na net nebo na ICQ bylo to právě v tu chvíli a že se mi o pár vteřin zpomalí přepočet videa mě nemrzelo.
Často jsem hrával NFS jen už si nepamatuju podnázev a současně přepočítával video a hra byla naprosto plynulá, jen občas se stalo jako by vypadl jeden snímek. Při vyplém HT to bylo buď nehratelné, nebo se musely přepočtu videa snížit priority a značně prodloužit čas přepočtu. Samozřejmě se najde spousta testů, kde se prokáže nevhodnost HT, ale stejně tak se dají najít testy, kde by Trabant porazíl bez problémů Mercedes :-). O nevhodnosti HT se toho napsalo hodně a přečetl jsem si to naštěstí až po koupi procesoru, určitě by mě to od koupi odradilo, nicméně já byl s HT naprosto spokojený a nikdy se nesetkal s problémy.
Někdy je možná dobré přemýšlet nad tím k čemu to nebo ono využít a ne jak dokázat, že se jedná o špatnou technologii
5.9.2008 21:44:55   213.220.244.xxx 111
Název HyperTransport (HT) vzniknul dříve než Hyper-Threading Technology (HTT), proto zkratka HT náleží AMD.

S tím zpomalením výpočtu videa to, obávám se, ne úplně chápete - při správném nastavení priorit je výpočtu videa přidělena nízká a ICQ jako standardní aplikaci normální. ICQ pak má vždy při přidělování prostředků přednost, což je logický a správný stav (výpočet videa počká). Toto je standardní chování operačního systému a jakékoli jeho narušení je chyba. Na hraní hry vs. výpočtu videa z vašeho příkladu je jasně dokázáno zcela chybné chování, protože je to hra, kdo má dostat 100 % výkonu CPU (bez ohledu na její hratelnost nebo nehratelnost) a nikoli jen jeho polovinu vlivem hardwarové chyby v návrhu procesoru. HTT fakticky degraduje prioritu všech úloh na standardní, což vede k tomu, že tato činnost úplně postrádá smysl.

Intel vymyslel HTT pro servery, kde mají všechny úlohy stejnou prioritu. U desktopů to byl jednoznačný marketingový tahák.
6.9.2008 18:54:19   77.104.245.xxx 90
Zvláštní ovšem je, že po zadání HT do prohlížeče mi to ukazuje pouze odkazy na články s Intely a HyperTheardingem - nu což asi se můj PC mýlí ve zktatce stejně jako já :-)
Mimochodem testoval jsem se stejnými programy i AMD a bez zásahu do priorit se chovalo naprosto stejně jako ten Intel při vyplém HT.
Co se týče ICQ a toho zda daný problém chápu můžu dodat jediné, s C2D i s dvojjádrovým AMD procesorem musím čekat až si na mě procesor udělá čas, u HT technologie k tomu nedošlo ani v případě, že jsem vypaloval, další film kopíroval na HDD, přepočítával video a měl 2* spuštěného klienta hry Lineage. Prostě v odezvě systémů měl starý P4 navrch i když jsem měl tehdy pouhý 1GB RAM
Ne nebylo to standartní využití PC, ale test a taky tak trochu předvádění mého počítače před kamarády, kteří měli vesměs AMD a nedovedli pochopit, proč jsem si pořídil Intel.
6.9.2008 19:34:06   213.220.244.xxx 92
Když si nechám vyhledat zkratku HT na stránkách Intel.com, tak mi to vždycky vyjede se slovem "technology". Z toho je celková zkratka HTT. AMD představilo HyperTransport již v roce 2001, tedy rok před tím, než Intel uvolnil HTT do Xeonů.

P4 s vypnutým HTT se samozřejmě chová úplně stejně jako jakýkoli jiný procesor - respektuje priority.

Odezva u HTT může být o něco lepší, protože tam nemusí docházet k tolika cache miss u L1 cache. Nicméně rozdíl takového charakteru mi přijde zcela neměřitelný a mnohem větší vliv má dle mého celková velikost cache (u Intel Penryn 6 MB) a rychlá RAM (u Athlonu integrovaný paměťový řadič). Přijde mi tedy, že "cítit" lepší odezvu HTT je spíš placebo efekt.
7.9.2008 18:01:37   77.104.245.xxx 92
Žádny intel.com :-) ale normální české servry. Vžilo se skutečně označení HT pro Hyperthearding a HTT pro HyperTransport, nicméně jsou i tací, kteří používají opak :-). Je v celku jedno jak kdo tuhle funkci ve zkratce označuje, pro mne bylo podstatné, že fungovala.

Nj Intel s vyplým HT respektuje priority, ale současný běh hry a přepočtu nezvládl stejně jako tehdy testované AMD s o krapet vyšším výkonem. Pro HT to byla brnkačka a pokud bych to vzal podle měření byl přepočet videa pomalejší o 10-15% než když bylo zpracováváno samostatně a hra se zpomalila jen nepatrně - docházelo pouze občas jakoby k vypadnutí jednoho snímku - obraz se občas na okamžik jakoby trhnul ale tyhle chyby byly ojedinělé a navíc skutečně kratičké. Dá se tedy říct, že HT mi umožnilo dostat z PC cca 160% výkonu, jestli ne víc. Samozřejmě pokud bych používal dva stejné programy, tento efekt by se neprojevil - byly by využívané stejné části procesoru.

Nenazval bych to placebo efektem, sám jsem počítal, že to bude s C2D ještě lepší přeci jen je rozdíl mít místo dvou virtuálních jader dvě skutečné – nejde o nijak katastrofální rozdíly, ale poznat to je.
7.9.2008 18:43:54   213.220.244.xxx 91
A byl výkon hry otestován nebo je to jen dojem? Ono totiž sotva poznám, jestli mi klesl počet fps ze 100 na 50 za sekundu a beztak u her kritické situace s rapidním poklesem výkonu zaviní většinou grafická karta.
7.9.2008 20:33:13   77.104.245.xxx 91
U NFS jde skutečně o dojem, ale vzhledem k tomu, že byla hra odzkoušena na podobné konfiguraci jen se slabším procesorem, dá se usuzovat že procesor při HT a zpracování dvou úloh neklesl pod 80% V některých hrách jsem ovšem mohl pomocí zobrazování počtu snímků udělat testy podrobnější a ani tam nedocházelo k poklesu o více jak 15%

Jsem si vědom toho jak HT fungovalo a je mi jasné, že ta technologie nebyla zcela dokonalá ale v mém případě tj. spušťěná hra a na pozadí přepočet videa skutečně fungovalo bezvadně.
Na druhé straně jsem si však nevšiml žádného zrychlení mezi během programu s vyplým a se zaplým HT. Malou vyjímkou byl DVD Shrink kde bylo zrychlení cca 10%.
HT bylo tedy využitelné pro spouštění dvou různých úloh, ale nikoliv pro programy které dovedou využít dvojjádro, nebo pro provoz programů využívajících stejné výpočetní jednotky procesoru.
4.9.2008 17:35:09   88.208.87.xxx 100
Uděluji pochvalu za skvělý článek.
5.9.2008 09:28:53   91.195.106.xxx 131
Nové instrukce se hodí pro práci s řetězcema. A o nich tu nepadlo ani slovo.
5.9.2008 09:41:53   62.141.0.xxx 91
no, vida, to je veledulezita vec, kterou jsem taky nikde zminou nevidel.. nejaky odkaz, pls. ?
5.9.2008 10:40:10   91.195.106.xxx 110
http://en.wikipedia.org/wiki/SSE4
http://xtreview.com/addcomment-id-3391-view-Intel-SSE4.2.html
5.9.2008 09:44:47   62.141.0.xxx 90
ikdyz, je otazka, jaktoho compilery dokazou vyuzit a jestli se to vubec nejak projevi u jiz existujicich aplikacich, ktery stavi na uz prelozenych knihovnach.
a psat treba parser v ASM by bylo asi hodne HC . ikdyz, kdyz za to vysledek stoji a pokud by pro to existovaly intrinsicty... bylo by to mozna docela elegantni
5.9.2008 10:49:59   91.195.106.xxx 100
Myslym si, že v servrech kde běží SQL databáze se to těžce vyplatí.
5.9.2008 11:22:46   62.141.0.xxx 100
no, jo, to je prave ale jedna z mala situaci, ktera me napa
5.9.2008 11:24:52   62.141.0.xxx 101
spis jem to myslel tak, ze i ta DB ma uz napsanej a do instrukci prelozenej kod. takze, idkyz nehalem bude umet nejaky triky s retezci, tak si bude treba nejak tuhle vlastnost vynutit. a to si myslim, ze prave stavajici kody nebudou umet... takze, si asi budu muset pockat, treba na Oracle 12G
5.9.2008 18:11:04   213.220.244.xxx 92
Zmiňovat se o instrukcích mi přijde jako ztráta času, protože normální programátoři toho nijak nevyužijí a dělat optimalizace jen proto, aby to využil jeden procesor z třiceti, to se nikomu nevyplatí (... a ještě to zpomalí kód pro ostatní). Ona historie ukázala, že zatím se využily jen dvě rozšiřující sady - MMX a SSE2, přičemž se využily převážně proto, že je nějaký (Microsoftí) kompilátor podporoval. Jinak je to se vším velmi bídné. Pro uživatele tedy nějaké nové instrukce dle mého nemají prakticky žádný efekt, minimálně ne v horizontu kratším než 5 let.
6.9.2008 13:00:18   213.220.228.xxx 122
no, nevim, jak by optimalizace mohla ostatni zpomalit ? proste bude zakladni binarka, ktera na zacatku zavola CPUID a podle toho natahne .dll (.so) s takovou verzi kodu, ktera bude nejak optimalizovana.
ano, je to nejaka rezie, ktera se ale potom urcite vyplati.
je to sice prace navic, ale pokud by slo jen o vytipovany casti, par funkci, ne psat celou aplikacku znova.. tak by to snad nebyl tak divoky a narocny.
6.9.2008 19:45:50   213.220.244.xxx 100
Odpověděl jste si sám - volání CPUID (což je mimochodem serializovaná instrukce !) a následná podmínka může dost zpomalovat. Např. Intel C++ Compiler vkládá CPUID rozhodovací podmínky ke každému podle něj vhodnému bloku - a to prostě znamená už slušnou režii. Kdyby to dělal na úrovni DLL, tak se poněkud zvětší výsledný kód.

Jinak pokud se vyplatí dělat nějaké optimalizace, tak profile guided. S těmi se dá získat klidně 30 % výkonu navrch a to bez jakýchkoli podmínek na přítomnost nějakého konkrétního CPU.
6.9.2008 13:04:12   213.220.228.xxx 101
jinak, SSEx umi vyuzit i jiny kompilery ;-) (gcc, icc)
je pravda, ze je treba to tomu prekladaci nejak inteligentne naznacit a pouzit intrinsicty, takze je treba zvazit, jestli se pro danou aplikaci vubec vyplati zabyvat se nejakou takovou vychytavkou, ktera zesloziti kod a tim ho nejspis prodrazi a pritom poskytne vykon. boost 5%
nicmene, z vlastni zkusenosti, pkud se nekde intenzivne pocita, opravdu se SSEx vyplati nastudovat. tech intrinsictu nakonec neni az tak moc a jsou celkem srozumitelne popsany.
ale chce to zvazit tu potrebnost
5.9.2008 10:34:35   195.98.5.xxx 140
Velmi pekny clanok.....aj ked som niektorym tym detailnym veciam neporozumel....ale myslim ze jadro som pochopil=) ....dik

Redakce si vyhrazuje právo odstranit neslušné a nevhodné příspěvky. Případné vyhrady na diskuze(zavináč)pctuning.cz

176 čtenářů navrhlo autorovi prémii: 84Kč Prémie tohoto článku jsou již uzavřené, děkujeme za váš zájem.
Tento web používá k poskytování služeb soubory cookie.