Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
K tomu HyperThteadingu >> Dufam, ze budu vyriesene zakladne problemy, ktore boli na NetBurst-e:
1. kradnutie jednotiek - nesmie dochadzat k prepadom vykonu, ked 2 thready pozaduju rovnaku jednotku ([FPU,FPU],[ALU,ALU] a pod.). Vykon by mal ostat na 100%, nemal by ist nizsie.
2. priority - na starom P4 s HT, ked pustim BOINC a gamesu naraz, dojde k tomu, ze gamesa (high priority) nabezi naplno lebo BOINC (low priority) kradne jednotky a dostava od MS OS viac CPU time.
K tej 2. napisal krasne vysvetlenie EAGLE, v cca tomto zneni:
Spustim hru, obsadi prvy virtualny procesor. Spustim dalsiu app s nizkou prioritou. OS zisti, ze ma volne dalsie jadro (dalsie virtualne jadro) a tak nastavi afinitu na toto druhe jadro a posle tam thread na spracovanie. Lenze kedze stale sa jedna o to iste fyzicke jadro, BOINC zacne uzierat jednotky (BOINC je FPU narocne) a na gamesu nedojde (aj ked ma vysoku prioritu). Bohuzial toto nemoze vyriesit OS ale vyvojar CPU.
Tak dufam, ze to uz vyriesili, inak to zase v BIOSe vypnem.
Máš istým spôsobom pravdu. BOIC je myslím určený na využitie zvyšeného výkonu PC pri bežnej práci. Asi ty pr hraní hry už ale moc zvyšného výkonu nemáš.
Ono je to řešitelné i softwarově. Pokud systém ví, která virtuální jádra tvoří jádro reálné (což není až takový problém zjistit), tak stačí zajistit, aby se na fyzickém jádře s high priority procesem nevyužívá druhé virtuální jádro vůbec. Navíc není potřeba upravovat aplikace, stačí upravit plánovač v jádře. V Linuxu je toto řešení už dlouho a "nice" procesy (s nízkou prioritou) se nespouští na vytížených fyzických jádrech (resp. to jde tuším vypnout a zapnout). Někdo mě přesvědčoval, že stejný princip do Windows přináší SP2 pro XP, tak tomu věřím. HT procesor jsem nikdy neměl, tak to nemůžu otestovat...
2 xvasek: To, co říkáš, není žádné řešení, ale pouhé softwarové vypnutí druhého jádra, tedy ekvivalent vypnutí v Setupu BIOSu.
BOINC bezi typicky na nejnizsi priorite, tudiz prakticky kazdy jiny program, ktery spustis, bezi na normal priorite a ma tedy prednost pred BOINCem. Nemelo be se teda stavat, ze bude BOINC krast vykon hre, pokud bude oboje spustene soucasne.
Nemá někdo informace k SSE4 ?
http://en.wikipedia.org/wiki/SSE4
mmmm: Dík, taky mě to mohlo napadnout :) nebo to mohl WIFT rovnou nalinkovat :))
2 Eagle_not_registered: Nie je to celkom to iste. Na setup BIOSu musis restartovat PC.
Necroman: priklad - jednojadrovy procesor bez HT, bezi dve aplikace s ruznou prioritou, aplikace s vyssi prioritou vytizi procesor na 100%, druha stoji.
Dvoujadrovy procesor, bezi dve aplikace s ruznou prioritou, pokud aplikace s vyssi prioritou vytizi pouze jedno jadro system prideli druhe aplikaci s nizsi prioritou druhe jadro.
Jednojadrovy procesor s HT, bezi dve aplikace s ruznou prioritou, pokud aplikace s vyssi prioritou vytizi pouze jedno jadro system prideli druhe aplikaci s nizsi prioritou druhe jadro, ale to je jen virtualni, pouzivaji stejne vypocetni jednotky a na urovni vlaken v procesoru se priority nastavene ve windows neuplatnuji, takze kazdy si vezme polovinu vykonu procesoru (pokud budou pouzivat stejne jednotky) a aplikace s vyssi prioritou tak bude pomalejsi nez kdyby byla spustena samostatne.
Skutecnym resenim by byla uprava planovace tak, aby sledoval efektivitu behu jednotlivych threadu na ruznych procesorech (jedno zda logickych, ci fyzickych). To lze udelat s pomoci jiz existujicich funkci CPU, ktere dokazi pocitat vykonane instrukce a tak by stacilo upravit planovac uloh tak, aby meril, kolik instrukci danny thread zvladnul za jednotku casu a postupne zkousel danny thread presouvast na jine procesory a podle toho rozhodnul, ktera kombinace rozlozni threadu je nejlepsi. Toto neni muj vymysl, ale uz jsem o tom cetl pred drahne mesici, toto reseni navrhnuli nekde na nejake univerzite, bohuzel link uz nevim ale mam pocit, ze jsem to jiz posisla v nejake diskusi zde ohledne hyperthreadingu. Jediny problem vidim v tom, ze mnozstvi kombinaci muze byt sakramentsky velke, napr. me ted bezi v XP--kach cca 400 threadu, pokud bych mel ctyrjadro s HT, tak se bude muset prohledat sakramentsky velky pocet kombinaci jak rozmistit 400 threadu na 8 CPU a to muze trvat velmi dlouho. Nastesti skutecne aktivni jsou jen nektere thready, takze v praxi postaci kombinovat jen par tech aktualne pracujicich a to uz by snad bylo resitelne v rozumnem case. Tento zpusob rozdelovani threadu pak vyresi jak problem s vhodnym sdilenim vypocetnich jednotek, tak i sdileni, resp. nesdileni CPU cache, popr. RAM, resit to pomoci nejakych pevne dannych pravidel v planovaci uloh je nerealne, napr. dvouprocesorovy system s dvoujadrovymi Opterony by vyzadoval uplne jiny pristup nez ctyrjadrovy Xeon (4x vyhrazena cache + 2x vyhrazena RAM u AMD, versus 2x sdilena cache + 1x sdilena RAM u Intelu), krome toho je to zavisle i na tom, co ktery thread vlatne dela (napr. nekdy se hodi, kdyz budou dva thready sdilet stejnou cache, jindy zase naopak) a to uz planovac uloh nemuze nijak vedet, navic s prichodem kazde nove genearce CPU by se musel planovac uloh upravovat dle aktualni architektury, oproti tomu mnou nastinene reseni je zcela univerzalni.
Rastr: Pěkně si tu vysvětlil, proč je mnohem lepší naučit jádra rozlišovat priority jak to umí Power nebo ještě lepší udělat jádra co nejjednoduší a mít jich co nejvíc a na celej HT se vyprdnout, jak je tomu u Cellu.
Teda pánové, měl by vás Intel zaměstnat... Koukám, že tomu docela rozumíte.
Klobouk dolu...
Nevíte jak to bude s jádrama?
Jeden plát křemíku 4 jádra, slepenec 2kusů 8 jader?
Nevidim dovod, aby sa priority riesili v CPU - to musi robit OS a zrejme XP ma v tomto este medzery, lebo neberie dostatcone do uvahy specifika implementacie HT oproti cistemu MPS.
Priority nic nevyresi. Napr. mam aplikaci, ktera provadi rekompresi HD videa z MPEG2 do MPEG4 (abych snizil bitrate). Dekompresi MPEG2 bude obsluhovat pro jednoduchost jeden thread, kompresi do MPEG4 pak opet pro jednoduchost druhy thread. V pripade klasickeho dvouprocesoroveho reseni typu 2x Pentium III, nebo i novejsiho Pentia D, je jasne nejvyhodnejsi nastavit u obou threadu stejnou (nejvyssi) prioritu. Planovac uloh pak spusti dekopresi na jednom CPU a kompresi na tom druhem, nic lepsiho se tady vymyslet neda. Ovsem v pripade, ze misto Pentia D dame Core 2 Extreme (2x dvoujadro v jedne patici, pricemz 2 a 2 jadra sdili po jedne ctyrmegove pameti cache) tak to jiz neni tak jednoduche, protoze se zrejme ukaze, ze nejvhodnejsi je spustit oba thready na dvou jadrech ruznych cipu, aby mel kazdy thread k dizpozici "sve" 4MB rychle pameti cache (coz lze pri trose dobre vule stale jeste odvodit z toho, ze oba maji nejvyssi prioritu, tak jim kazdemu proste vyhradim jeden kompletni CPU), ovsem pri pouziti procesoru s cache sdilenou obemi jadry o velkosti rekneme 32MB je jiz pravdepodobne, ze se do cache vejdou jak data unikatni pro kazdy thread, tak spolecna raw-video data, ktera je nutno mezi thready sdilet, takze v takovem pripade je pak naopak lepsi pouzit jadra, ktera cache sdili. To je neco, co bez konkretniho testu behu konretni aplikace nijak nevyspekulujete a zadne priority vam k optimalnimu reseni nepomuzou. 32MB sdilene cache sice zadny dnesni procesor nema, ale kombinace sdilena vs. vyhrazena cache, a/nebo (u CPU AMD) sdilena/vyhrazena RAM jsou realitou jiz dnes a bez znalosti konkretni spustnene aplikace, popr. cele sady aplikaci, nelze jen tak jednoduse rozhodnout, jake rozlozeni threadu je optimalni !
Eagle, Ra str: Co se tyce nevhodne implementace planovace v XP pro HT procesory, mame jasno (tady IMHO az na vyjimky radeji HT vypnout nez nechat planovac chybne planovat pro 2 virtualni procesory). Netusite, meni se neco ve Vista? Myslim pro klasickou situaci s HT P4, a dale i pro opravdova (ne virtualni by HT) jadra, ktera sdileji jen L2 cache. Nema byt Vista v tomhle chytrejsi nez XP?
2 TomK: Operační systém nemůže tenhle problém vyřešit, protože do procesoru nevidí. Systém neví, které jednotky se aktuálně používají a i kdyby to věděl, nebude mít informaci o tom, které jednotky bude využívat nějaký konkrétní program - jednoduše proto, že OS program nepouští jako nějaký emulátor (tj. nezná jeho obsah), ale předává ho ke zpracování do CPU. A mimo to CPU vnitně nepracuje s instrukcemi, ale s rozdělením do mikroinstrukcí, což je u každého designu jinak, tudíž využití jednotek zná pouze výrobce CPU a nelze to nijak zjistit. Jediný způsob ošetření funkce virtuálních CPU je přes procesorem řízené priority - tj. OS by musel v CPU nastavit společně předáním IP taky jakousi prioritu procesu a CPU by se už postaral o zbytek.
Eagle: Chapu, ze nejlepe planovat to muze pouze nekdo, kdo zna zavislosti mezi jednotlivymi zdroji. Nemyslim az konkretne na to, ktere vlakno vyuziva specificke casti CPU, ale jsem presvedcen, ze ta cast OS, ktera se stara o pridelovani threadu CPU, by mela mit podrobnejsi informace o strukture CPU a vyuzit je spolu s informacemi o priorite procesu, pro rozdelovani threadu mezi CPU: Ze treba CPU 0/1 jsou jen 2 HT instance jednoho jadra, kdezto CPU 2/3 jsou instance druheho, nezavisleho jadra.
Ocekaval bych, z inzenyri z Redmondu vezmou alespon tohle v potaz. A co tucnaci?
To samozřejmě je možné zjistit pomocí CPUID. Ale zda to skutečně Windows dělají nebo ne, to nevím.
RaStr
Riesit to dymanicky je prakticky nemozne, lebo vlakno moze casto menit svoje poziadavky podla toho co prave pocita a teda by ti nestacilo raz rozhodit vlakna na jednotlive jadra, ale musel by si to kontrolovat dost casto a ako si uz spominal pri vedsom pocte jadier a aktivnych procesov by to uz mohlo byt celkom dost kombinacii.
Ovela jednoduchsie riesenie, aj ked nie uplne doknale by bolo zaviest do OS nejaky driver pre CPU ktory by obsahoval informacie o tom ktore, jadro s ktorim zdiela cache, ktore virulane jadra bezia na jednom fyzickom a tak na zaklade tychto inforamcii by OS vedel ovela chytrejsie priradovat vlakna jednotlivim jadram.
Ale robia... Mam k tomu doc, ale na MSDN ho uz nevidim..
Tu je aspon nieco.. Ukazuje to na ten doc, ale uz tam neni... Kto chce, mam...
http://blogs.msdn.com/oldnewthing/archive/2004/09/13/228780.aspx
Mam ho:http://download.microsoft.com/download/5/7/7/577a5684-8a83-43ae-9272-ff2...
Sorry za tolko post-ov... ;-)
Mumak: Takže používají procesory, dokud jsou volné - mohlo by to být i chytřejší.
RaStr: Optimalizace systému pro daný procesor je jednoduchá a navíc procesorových rodin s různým chováním není až tak moc - proto není takové heuristiky potřeba. Navíc nezapomínej, že svět jde směrem k NUMA, takže migrace mezi procesory se ještě "prodraží" - kromě vytřískání cache dostane proces po migraci ještě jako bonus pomalý přístup do paměti - proto je lepší nemigrovat. Každý OS by měl mít pro speciální případy možnost umístit daný proces na procesor "napevno".
Eagle: Není to jako vypnutí HT. Jednak je to jenom lokální (pro jeden procesor) a druhak je to pouze pro "nice" procesy, což řeší většinu problémů - pokud máš dva procesy se stejnou prioritou, rád využiješ nárustu výkonu přes HT, ale pokud ti běží seti na pozadí, raši bys možná dělal něco jiného, než se s ním dělil o procesor.
xvasek: Dik za info o planovani lowest priority procesu pro HT na linuxu. Skoda ze neexistuje ddto pro Win, Uplne by stacilo, aby se procesy s nejnizsi prioritou (typicky background ulohy OS jako indexing, virusscan, boinc, dnet, ..) stoply pokud na HT instanci daneho fyzickeho jadra bezi nejaky proces s vyssi prioitou, jak uz tady nekdo psal. Neni pro Win alespon nejaky patch? A kdyz ne pro OS, tak alespon pro konkretni aplikaci jako treba boinc?
Mumak: Dik, takze vime alespon, ze XP SP2 a vys (2k3 server) pri planovani threadu pro vice HT-enabled CPU obsazuje nejprve fyzicka jadra a potom az jejich "HT protejsky". Coz se dnes projevi jen u Xeonu. Doufam, ze pro novy serverovy OS Win uz to bude vyreseno lip.
CSI je common system interface a nie ako je napisane v clanku common seriall interconnect...pls opravit
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.