[OT] Procesory intel (do PC)

Pondělí Březen 12 22:07:10 CET 2012

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 