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