[OT] Procesory intel (do PC)

Úterý Březen 13 05:22:30 CET 2012

Zdravím,
  ano, přesně tak. Pokud úloha čeká na jakékoliv I/O (disk, klávesnici,
vykreslení graf. prvku pomocí GPU atd.), prostě OS pustí ty, co běžet mohou.
Čili běží-li nějaký "žrout CPU" s minimálním I/O, dostane maximum výkonu
v okamžicích, kdy ostatní úlohy musí čekat. Kdyby tam takový "žrout" nebyl,
dostane CPU Idle task, který je využije k fyzickému usnutí a snížení 
spotřeby. Tehdy bude nenulový iowait. Pokud budou CPU využity i tehdy, kdy
nějaké úlohy čekají na I/O, bude iowait 0.
  Zdraví Pavel

> Ano, teplota cpu je nízká, prostě čeká. Takže kdybych tam měl nějaký 
> zatěžovací program, který vůbec nepotřebuje disk a ramky mu stačí pár 
> desítek bajtů, v pohodě by při takovém čekání na disk 70% (jen jedno cpu) a 
> vytížení ostatními aplikacemi 30% (tedy idle=0), si vzal těch 70% výkonu, 
> co stráví cpu čekáním na disk? Takže čekání na disk bude v tomto případě 
> 0%, 70% si vezme zatěžovací program a 30% aplikace, které čekají na data z 
> disku?
>
> ----- Původní zpráva ----- Od: "Pavel Troller" <patrol na sinus.cz>
>
>
> Zdravím,
>
>> No mám to hlavně vypozorováno - na linuxu ale týká se to úplně stejně i
>> woken, taky se extrémně zpomalí když se moc hrabe na disk.
>
> To samozřejmě ano. Ale není to proto, že by CPU čekaly na disk - v takovém
> případě si CPU spokojeně pochrupávají v idle tasku :-). Uživatelsky se to
> ale může jevit, že na ten disk čekají.
>
>>
>> Když pustím top při vytíženém disku, tak (jen jeden) cpu čeká třeba z 70%
>> (stav wait), zbytek 30% něco dělá a idle je zhruba nula. Jakmile přestanou
>> diskové operace, je idle (třeba) 20%. Pokud to samé jede na dvojjádru, tak
>> máme k dispozici 200%, takže top ukazuje idle v tomto případě 200-80-70
>> (tj. 50%) a systém má svižné odezvy. S dvoujádrem mám ale zkušenosti jen 
>> ve
>> virtualizovaném stroji.
>
> Aha, vy myslíte stav iowait. Nu, název toho stavu je poněkud matoucí. Tento
> stav neznamená, že cpu aktuálně na něco čeká, ale, cituji definici,
> "... The actual definition of %iowait is the percentage of the time that the
> system was idle and at least one process was waiting for disk IO to finish".
> Čili, měří to situaci, kdyby systém mohl něco dělat, kdyby měl rychlejší
> disky. Nicméně, ano, z uživatelského hlediska se může zdát, že ty CPU 
> skutečně
> čekají - ovšem programátorsky je v tom, jistě netřeba vysvětlovat, velký
> rozdíl :-).
>
>>
>> podotýkám, že při wait 70% se s takovým systémem prakticky nedá dělat a i
>> ten top hodí stránku jednou za čtvrt minuty. Většinou se toto děje když
>> swapuje.
>>
>
> Zcela logické. Pokud se swapuje, diskové buffery a fronty se zaplní takovou
> šňůrou požadavků, že prakticky každá úloha, která občas musí hrábnout na 
> disk
> pro běžná data, třeba minutu čeká, než se na ni dostane. Pokud navíc jí byla
> zabavena RAM, musí čekat i na to, až ji dostane zpátky :-). Ale pokud byste
> měřil teplotu/spotřebu CPU, bude překvapivě nízká a tyto budou většinu času
> trávit v nejhlubším možném spánku :-).
>
> Zdraví Pavel
>
>
>>
>> ----- Původní zpráva ----- Od: "Pavel Troller" <patrol na sinus.cz>
>>
>>
>> Zdravím,
>>  chtěl jsem se zeptat, zda níže popisované chování je skutečně
>> implementováno
>> v nějakém OS, nebo zda to je jen určité zjednodušení a přiblížení laickému
>> čtenáři. Dle svých znalostí mnou používaných OS (preemptivní Unixového 
>> typu)
>> tomu tak totiž není.
>>  V obecném víceúlohovém OS preemptivního typu jsou v zásadě možné 4 stavy
>> úloh: běžící, připravená, čekající a pozastavená.
>>  V takovém OS může teoreticky běžet (tj. být ve stavu "Běžící") tolik 
>> úloh,
>> kolik má OS k dispozici logických CPU.
>>  Uloha, která nemůže běžet, např. proto, že čeká na disk, je ve stavu
>> "čekající" a nezabírá ŽÁDNÉ prostředky CPU. Rozhodně neplatí, že by "jádro
>> čekalo", až disk dodá data. Je to uděláno tak, že na disk čeká hardware -
>> řadič disku - a jakmile disk dodá data, řadič je přijme, uloží do bufferu
>> (zcela automaticky pomocí DMA) a vygeneruje přerušení do CPU, to přeruší
>> právě prováděnou úlohu, vyvolá obsluhu disku v jádru OS a pokud na data z
>> disku
>> skutečně čekala nějaká úloha, jádro (modul plánovače - scheduleru) ji
>> přesune
>> z haldy úloh (heap - úlohy jsou tam bez nějakého řazení) čekajících do
>> fronty
>> úloh (řazené dle aktuální dynamické priority) připravených. Pokud to OS 
>> umí
>> a priorita úlohy je dostatečně vysoká, provede se tzv. dynamický 
>> asynchronní
>> rescheduling, kdy tato úloha dostane CPU a rozeběhne se, zatímco dříve
>> běžící
>> úloha je odstavena zpravidla na konec fronty úloh připravených.
>>  Pokud je tedy co dělat - tzn. nejméně tolik připravených - běhu schopných
>> -
>> úloh, kolik je logických CPU, budou všechny dostupné logické CPU naplno
>> zaměstnány během těchto úloh. Je-li běhu schopných úloh méně, jsou některé
>> logické CPU "zaměstnány" tzv. klidovou úlohou - "idle task", která je
>> zřízena
>> v jádře OS proto, aby plánovač byl regulární - měl vždy po ruce úlohu i v
>> případě, že nic na systému nepožaduje běh. Tento idle task obvykle na HW
>> úrovni vykoná instrukci HLT, což procesor uvede (ve spolupráci s ACPI
>> subsystémem) do nějakého úsporného režimu spotřeby energie.
>>  Po tomto teoretickém úvodu tedy pár detailů o různých typech logických
>> CPU.
>> Pro jednoduchost mějme na mysli SMP architekturu, která je nejrozšířenější
>> u běžných domácích PC.
>>  V zásadě může logické CPU být tvořeno:
>>  1) Fyzickým CPU - tedy plně samostatným pouzdrem, které má všchny 
>> podpůrné
>> moduly (např. L1 - L3 cache, řadiče sběrnic atd.) pro sebe. Zde je
>> samozřejmě
>> úroveň samostatnosti nejvyšší a jediné, co takové CPU brzdí od práce, je
>> průchodnost sběrnice při přístupu do paměti, kdy musí sdílet sběrnice
>> s ostatními CPU. Pokud má však dostatečně velké cache, nemusí to být 
>> příliš
>> omezující a proto je tento (dnes poměrně vzácný) způsob implementace
>> logických
>> CPU obecně nejvýkonnější.
>>  2) Samostatným jádrem na společném čipu vícejádrového CPU - zde je 
>> situace
>> jiná v tom, že některé podpůrné obvody jsou společné pro celý čip. Např. 
>> to
>> bývají cache vyšších úrovní (L2 - L3), zatímco L1 cache bývá stále
>> individuální
>> per jádro. Pochopitelně zde už se jedná o kompromis - pokud bude každé z
>> jader
>> vykonávat zcela rozdílné úlohy, budou se o cache muset dělit a tedy bude
>> výkon
>> nižší. Naštěstí mají moderní čipy poměrně velké L2/L3 cache, takže i při
>> tomto dělení na každé jádro zbyde slušný kus.
>>  3) Využitím funkce Hyperthreading. Zde je vtipnýn řešením pipeliningu
>> (řazení
>> instrukcí do fronty k vykonání) dosaženo toho, že z logického pohledu se
>> jedná
>> o 2 CPU, zatímco fyzicky jde o jedno. Paralelismu lze dosáhnout nejen tím,
>> že
>> by jedno jádro "čekalo na disk" (jak vysvětleno výše, takto dle mého 
>> názoru
>> moderní OS nepracuje), ale hlavně tím, že může současně pracovat např. 
>> FPU,
>> ALU a některé další části CPU. Pokud tedy např. jedna úloha řeší operace
>> s reálnými čísly a využívá FPU, druhá může takřka nerušeně paralelně s ní
>> využivat celočíselnou ALU např. pro běžné výpočty. Nebo může jedna úloha
>> pracovat s ALU, zatímco druhá vykonává nějaký přesun dat v paměti pomocí
>> cyklických instrukcí či jiného obdobného mechanismu. Dále samozřejmě je
>> jasné,
>> že veškeré podpůrné moduly (včetně L1 cache atd.) jsou společné.
>>  Jak je asi jasné, aby se HT uplatnil, musí být k tomu vhodné podmínky.
>> Rovněž je vhodné pro tento účel optimalizovat plánovač, který může dle
>> způsobu
>> fyzické implementace měnit svoji strategii. Např. v Linuxovém jádře se 
>> volí
>> tato strategie při kompilaci a lze zapnout jak podporu samostatných CPU, 
>> tak
>> i multicore a hyperthreadingu, případně i vše dohromady (což je i běžný
>> stav, např. běžně pracuji se servery, které mají 2 fyzické CPU, v každém
>> 4 jádra a každé jádro má ještě HT. Dohromady tedy je v bedně 16 makajících
>> tučňáků :-).
>>  A teď tedy, na závěr, pár praktických zkušeností, ovšem jen z oblasti
>> Unixových OS, jiné bohužel nepoužívám:
>>  Na jednojádrovém CPU schopném funkce HT se zapnutím HT zvýší výkon 
>> řekněme
>> o 25 - 30%. Je to rozhodně poznat. Je pak nutno k systému přistupovat jako
>> ke dvouprocesorovému a náležitě to využívat - např. pouštět paralelní běh
>> make při kompilacích atd. Pozná to ale i běžný BFU - např. grafické
>> prostředí bude běžet lépe, protože přeci jen X-server a X-klienti budou 
>> moci
>> alespoň částečně využít výhody HT.
>>  Opravdové vícejádrové systémy mají samozřejmě vyšší parametry, tam lze
>> říci,
>> že třeba dvoujádro bude mít o cca 60 - 70% vyšší výkon než jednojádro na
>> odpovídající frekvenci.
>>  Pokud by to byly samostatné procesory, boost bude tak 80 - 90%, 
>> samozřejmě
>> na aplikacích, které jsou pro paralelní běh optimalizovány.
>>  Doufám, že jsem tady tím poměrně dlouhým mailem alespoň trošku něco
>> málo objasnil, ovšem podotýkám, že i můj popis je jen značně zjednodušený
>> a povrchní a možná i místy chybný :-).
>>
>> Zdraví Pavel
>>
>>> HT pomůže hlavně u IO operací, není to pravý dualprocesor, ale v podstatě
>>> virtuální dvojče na jednom. Díky tomu při čekání třeba na disk výpočty
>>> dále
>>> pokračují, protože HT si vezme kousiček z procesoru co obsluhuje disk a
>>> čeká na něj, zbytek je k dispozici ostatním procesům v systému.
>>>
>>> Proto je přínos HT sporný, protože testovací aplikace staví na paralelní
>>> práci, nikoli na reálných podmínkách. V reálu je to v kritických 
>>> situacích
>>> dost poznat.
>>>
>>> Dualcore má 2 jádra, tady jedno jádro s plným výkonem obsluhuje disk, 
>>> tedy
>>> vlastně na něj čeká, zatímco druhé je k dispozici. Rozdíl oproti HT je
>>> prakticky jen u výpočetně intenzivních aplikací, které nehrabou moc na
>>> disk. V okamžiku velkého množství IO budou na tom HT a dualcore v 
>>> podstatě
>>> stejně.
>>>
>>> Co se týče her, nevím jak vytěžují disk a kolik potřebují výkonu, ale 
>>> spíš
>>> bych řekl, že potřebují hlavně nadupanou grafiku a cpu obstarává jen
>>> chování drátového modelu.
>>>
>>>
>>> ----- Původní zpráva ----- Od: "Michal Gregor" <a2x1nptda8 na email.cz>
>>>
>>>
>>> Pro znameho tady louskam sestavy pocitacu v obchodech. Zatim jsme se
>>> shodli
>>> na stredne vykonnem PC, WIN7 32bit , 4GB RAM, procesor do 65W.
>>>
>>> Intel ma hromadu procesoru (mozna vetsi nez Microchip) a ted se v tom
>>> vyznej. Recenze na netu se trochu rozchazeji, takze se divam na
>>> porovnavaci
>>> tabulky Intelu Treba i3-2100 a G850 rozdil skoro 900kc, jediny rozdil je
>>> podpora Hyper-Threading. Jak moc se to podepise na vykonu? Co nevim, je
>>> vliv
>>> vykonu procesoru u her. Neni lepsi investovat do grafiky?
>>>
>>> Horsi bude vybrat grafiku, tam zatim nemam vubec zadny prehled. Jak jsou
>>> na
>>> tom jednotlivy vyrobci s ovladaci, chlazenim a predevsim se spotrebou v
>>> "kancelarskem rezimu"?
>>>
>>> _______________________________________________
>>> HW-list mailing list  -  sponsored by www.HW.cz
>>> Hw-list na list.hw.cz
>>> http://list.hw.cz/mailman/listinfo/hw-list
>> _______________________________________________
>> HW-list mailing list  -  sponsored by www.HW.cz
>> Hw-list na list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
>> _______________________________________________
>> HW-list mailing list  -  sponsored by www.HW.cz
>> Hw-list na list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list 
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list