Viceprocesoru a FreeBSD
Dan Lukes
dan at obluda.cz
Fri May 5 12:33:50 CEST 2006
MeX napsal/wrote, On 05/05/06 11:43:
> On Fri, 2006-May-05 at 10:46:37 +0200, Dan Lukes wrote:
>> Ano v tom bychom se patrne neshodli. Problem ztraty vykonu s HTT nepada
>> az tak na vrub OS, ale predevsim na HW samotny - a nemam dojem, ze by
>> nove procesory mely HTT udelane nejak uplne jinak, nez ty drivejsi (pro
>> jistotu - dual-core != HTT).
> V tomto pripade si dovolim nesuhlasit. Je podstatne, rovnako ako pri dual-core
> procesoroch, ako je v konkretnom systeme implementovane SMP.
To samozrejme je. Dobry scheduler napriklad dokaze vyresit v clanku
zminene problemy s prioritizaci. Sikovna SMP implementace dokaze omezit
(nikoli vsak na nulu) overhead souvisejici se spravou vice procesoru.
Ale tezko na strane softwaru pujde vyresit nedostatky hardwaru. Ani
scheduler ani samotne jadro neni schopne bez prilis vysokych casovych
nakladu zjistit, jake operace bude konkretni proces provadet a jake
casti procesoru tedy vyuzije. Neni tedy schopno posoudit, zda pri
schedulovani konkretnich dvou procesu na dva virtualni semi-procesory
oba procesy skutecne pobezi, respektive, neni schopno k procesu A
efektivne vybrat takovy proces B takovy, aby mohl skutecne bezet. Uz jen
proto, ze jadro nema informace o vnitrni strukture procesoru a tak, i
kdyby presne vedelo, jake instrukce budouv nejblizsi chvili oba procesy
provadet (coz ovsem, dotazeno do dusledku, znamena umet predikci toho,
kam se program pri svem vykonavani ve svem kodu zatoula).
Nic takoveho jadro, jakkoli bude napsane, delat nemuze a spoleha se
tedy jen na statistiku, ze dva procesy, ktere vybere, budou moci spolu
bezet alespon castecne.
A to se od prvni doby, kdy se objevilo HTT nezmenilo a pokud se nezmeni
(hardwarove) samotne HTT, tak s tim nelze nic udelat softwarove.
> napr. vypoctovo intenzivne ulohy ako su napr. distribuovane vypocty
> (napr. BOINC) bezia RYCHLEJSIE na procesore s HTT ako na rovnakom procesore bez
> HTT, a to tak, ze za rovnaky cas spracuje procesor s HTT cca. 1.5x viac ako
> procesor bez HTT. Toto si moze jednoducho overit kazdy sam experimentalne alebo
> sa pozriet na rozne fora k danej problematike, kde su konkretne casy
Souhlasim.
Ponechme tedy stranou, co je "vetsinou" a je patrne chyba, ze jsem ten
termin pouzil. Tim jsme se dostali do neprekonatelnych problemu s
definici "typickeho provozu". Nekomu na pocitaci bezi SETI, jiny pouziva
media-player, jiny ja-nevim-co-jeste.
Kazdy by si mel bud' udelat testy vlastni, nebo najit testy cizi, ovsem
takove, ktere byly delany na podobnem typu provozu, jaky odpovida jeho
provozu.
Nemusite delat ani zadne sofistikovane testy - zkuste si na svem
pocitaci HTT zapnout a nejakou dobu na nem normalne pracovat, pak ho
zkuste vypnout a nejakou dobu normalne pracovat. Podku poznate nejaky
rozdil, tak mate jasno, pokud nepoznate - tak je evidentne jedno, jak si
to nastavite ;-)
Predevsim jsem ale oponoval Romanovu nazoru, ze se v teto oblasti mohlo
neco zasadniho udat "casem". Ano, stare testy prestanou mit vypovidaci
hodnotu - az se vymeni scheduler. Ale ten se zatim nezmenil a hardwarovy
koncept HTT je take stale stejny, takze podle meho, starsi, drive
ziskane vysledky budou prinaset velmi podobne vysledky jako kdyby se
stejny test za podobnych podminek dnes opakoval a tak zpochybnovatni
cizich testu jen proto, ze byly udelany "uz davno" neni tak uplne na miste.
Nicmene, ja tady preci neprosazuji "jedinou pravou skutecnost". Ja
pouze vedle nazoru A s urcitymi argumenty pokladam nazor B s urcitymi
argumenty. je na kazdem vas si vybrat ten, ktery vas vic presvedci. Nebo
si vybirat nemusite a udelate si vlastni nazor C (vcetne nazoru, ze je
vam to jedno, protoze vas takhle problematika nepali) ;-)
> HTT v praxi, kazdopadne chcem poukazat na to, ze ROZHODNE nie je HTT na skodu,
Dohodneme se, ze ja se pokusim priste nerikat "vetsinou" a ty se
pokusis nerikat "ROZHODNE" ;-)
Dan
--
Dan Lukes SISAL MFF UK
AKA: dan at obluda.cz, dan at freebsd.cz,dan at kolej.mff.cuni.cz
More information about the Users-l
mailing list