No a pak že Blu Ray / HD DVD / atd nepudou cracknout ... to se pěkně zvýší odbyt HT procesorů ... :-)))

co jsem si precetl s pdfka, kde je problem nastinen a je tu i dost navodu jak tomu predejit po hw strance do budoucna, tak bych rekl, ze problem to neni neresitelny, ale dost realny na zneuziti (kdyz nekdo bude chtit). kazda dira by se mela zaplatovat a HT dira je. a to by vlastne stacilo oddelit pameti.

ad) Brano:
Prave ze uplne naopak, HT neni prilis vhodny pro thready, ktere silne vytezuji CPU, v takovem pripade je cela logika CPU (vsechny ALU, atp.) zamestnana jednim z threadu a paralelni beh druheho threadu na stejnem CPU zpusobi pouze to, ze se oba thready zacnou o danne zdroje "pretahovat" a celkovy vypocetni vykon (mereno dobou nutnou pro vykonani 1. i druheho threadu) je nizzsi. Napr. pri enkodovani videa jednim threadem a enkodovani audia threadem druhym, je casto rychlejsi spustit obe operace po sobe, nez najednou (a to nejen kvuli vykonu CPU, ale treba i kvuli praci s HDD, atp.). Vyhody HT se ukazi zejmena v situaci, kdy jeden z threadu je vyrazne mene narocny na zdroje CPU, v takovem pripade muze druhy narocnejsi thread bezet paralelne a diky tomu se snizi celkova latence systemu. Tipickym prikladem mohou byt operace s diskem (obecne s V/V zarizenimi), kdy zatimco jeden thread hodne casu stravi cekanim na vybaveni dat z V/V zarizeni (viz. takt CPU vs. takt PCI sbernice napr.), druhy thread bezici na virtualnim druhem CPU muze vesele pracovat s daty v RAM (resp. cache), napr. pri prohledavani disku jeden thread realizuje nacitani dat (a je znacne brzden operacemi souvisejicim s obsluhou radice), zatimco druhy thread nerusene provadi samotne vyhledevani v nactenych datech. Muzete sice namitat, ze takove operace jsou OS realizovany jako multithreadova a pre-emptivni mutitasking si uz se zabrzdenym threadem poradi, ale to je prave ten velky omyl, casto je totiz daleko rychlejsi provadet dva thready na dvou CPU s polovicnim vykonem, nez dva thready prepinat na jednom CPU s vykonem plnym, nebot znacnou cast vykonu CPU muze v takove situaci spotrebovat samotne prepinani threadu, ktere v pripade dvouprocesoroveho systemu odpada (a to i v pripade virtualnich CPU jako u HT). V praxi to znamena zrychledni reakci systemu v diskove narocnych operacich, napr. v prubehu nacitani nejake rozsahle aplikace je stale jeste mozne pomerne svizne prepinat mezi okny, system ma dost vykonu CPU pro inicializaci knihoven, atp. Takze HT je velmi vhodny pro kancelarska PC, zatimco jiz vyrazne mene se uplatni u serveru. Dalsi vyhodou HT muze (ale nemusi) byt nasazeni na hernich pocitacich, zejmena u her zalozenych na vyuziti DirectX je mozne pozorovat zrychleni, nebot samotna logika hry je obvykle jednothreadova (a tudiz zamestnava pouze jeden logicky CPU) a druhy paralelne bezici thread se muze napr. venovat V/V (vstupne/vystupnim) operacim s grafickou kartou a jinym procesum v DirectX, coz sice vyzaduje minimum strojoveho casu, ale diky nutnosti prepinani threadu (s tim spojenemu overheadu) v jednoprocesorovem systemu muze brzdit samotne vykreslovani, ale zalezi na konkretni implementaci a situaci, takze to nelze zobecnit. Co zobecnit lze, je, ze HT se obvykle pozitivne projevi v situacich, kdy dochazi k caste interakci uzivatele a systemu (napr. v kancelarskych aplikacich), kdy nizzsi latence systemu vytvari subjektivni dojem  vyssi vykonnosti, zatimco neni obvykle prilis vhodny pro ulohy, ktere intenzivne a dlouhodobe vytezuji CPU (napr. zpracovani multimedii, matematicke vypocty, atp.). Co se tyce stability, resp. nestability systemu se zapnutym HT, pricinou muze byt bud vadny HW (zejmena bych tipoval RAM), kdy v dusledku (byt jen kratkodobe) vyssiho vytizeni systemu v situacich, kdy oba thready skutecne "pobezi" soucasne, tzn. nemuseji na sebe cekat, muze dojit k vyskytu chyb, ktere se za nizzi zateze neprojevi. To ovsem pochopitelne neni chyba HT ! Druhou moznosti byva fakt, ze znacne mnozstvi software, zejmena ovladacu, nejen ze neni optimalizovano pro multiprocesing, ale casto ani nefunguje korektne na SMP zarizenich! To ovsem take neni chybou HT a naopak je lepsi, ze diky HT jiz nyni existuje tlak na vyrobce, aby SMP korektne podporovali, protoze jak ukazuji jak INTEL, tak AMD i dalsi, budoucnost cpu neni v nekonecnem zvysovani taktu ale ve zvysovani poctu jader v systemu a podpora SMP tak bude do budoucna nezbytna !
 
A abych se vratil k tematu, pripada mi to znacne jako velka bublina, nebo "Hodne povyku pro nic", protoze je v praxi daleko pravdepodobnejsi, ze k utoku na zabezpeceni PC dojde pres zneuziti "beznych" chyb v software, jako jsou neosetrene buffer-overflow, nebo kernel-rootkits, nez monitorovanim sdilene cache v CPU. Ostatne ke zneziti vyse zminene chyby je zapotrebi, aby utocnik spustil na napadenem PC svuj monitorovaci kod, a v takovem pripade asi bude mit administrator jine starosti, nez zrovna co presne takovy kod muze vycist ze sdilene pameti v CPU!

Abych to jeste trochu doplnil, nejsem zadny velky fanda HT, osobne davam spise prednost skutecnym procesorum, nez virtualnim, a tak opravdovy prinos HT skutecne vidim v tlaku na programatory. Diky skvele desce ABIT BP6 jsem byl jiz pred cca 5-ti lety hrdym majitelem viceprocesoroveho systemu a musim rici, ze situace v software pro Windows a  podpory SMP byla v te dobe skutecna hruza. Vetsina software pro WinNT radu vznikala pouhym prevedenim software z platformy Win9x a proste pocitala s tim, ze pokud se proces bezici na urovni kernelu (ovladace) zacykli v nejake smycce, tak zadny jiny proces v systemu proste nic neprovede. Dusledkem byly pady systemu s ovladaci od VIA (radice), SB Live!, scannery pripojenymi na LPT port, atp. Ted jiz cca 2 roky pouzivam P4 s HT a narazil jsem pouze na jedinou aplikaci (sw. logicky analayzator pripojeny na LPT port), ktera ma se SMP problem ! (samozrejme odhlednu-li od aplikaci urcenych pro Win9x, ci dokonce MS-DOS prostredi)

Joker: U P4 to tak je. U IBM Power lze nastavovat prioritu obou threadů na 1-5.

Joker & MildaIV: V zasade ano, ale ne nutne. Zalezi na tom, jak moc inteligentni bude planovac uloh v dannem OS. Pro system neni problem odlisit fyzicky a virtualni CPU, takze muze k CPU s HT pristupovat odlisne nez k systemu se dvemi fyzickymi CPU (napr. dual-core). V praxi tak tomu skutecne take je, napr. novejsi LINUX kernely, ci WindowsXP a vyssi skutecne rozlisuji mezi HT a fyzickymi CPU. Pravda je, ze HT od INTELu nepodporu prioritu threadu v jednotlivych "sub-procesorech" ovsem zaroven je take pravdou, ze samotne priority toho moc neresi, napr. WindowsXP znaji jen 6 urovni priorit a prakticky se vyuzivaji obvykle stejne jen dve (high a normal), takze v HT CPU se stejne mohou sejit dva procesy se stejnou prioritou, ktere by se ovsem nazajem kombinovat nemely. Mozne reseni je nastineno napr. tady: http://www.cl.cam.ac.uk/users/jrb44/docs/bulpin_usenix05.pdf, uvedene reseni ma tu vyhodu, ze je zcela univerzalni. Pro neznale anglictiny, nebo pro ty, kterym se zmineny dokument nechce cist, uvadim strucne nastineny princip cinnosti takoveho planovace. Planovac prubezne vyhodnocuje efektivitu vyuziti CPU v dannych kombinacich soucasne spustenych threadu a prirazuje jednotlivym threadum jakysi rating danny podilem jejich vykonu v HT vs. dedikovany CPU,  odvozovane z CPU performance counteru. Na zaklade takto ziskanych udaju pote pocita system dynamicky prioritu kandidatu na mozne druhe thready (doplnky k jiz bezicimu threadu primarniho CPU) a spusti na druhem (virtualnim) CPU thready s nejvyssi takto ziskanou prioritou. Uvedeny proces lze dle autoru rel. snadno implementovat v soucasnych systemech pri soucasnem zachovani vsech dosavadnich funkci planovace(pevne priority, vynucena afinita, atd.). Uvedeny proces by dle meho mohl take velmi pomoci i "skutecnemu" SMP, kde take (i kdyz samozrejme v mensi mire) muze dochazet k vzajemnemu ovlivnovani jednotlivych paralelne provadenych threadu v dusledku sdileni i jinych systemovych zdroju nez samotnych jednotek v CPU (napr. FSB, RAM, atd.).  

No, ja jsem tuto diru pochopil tak, ze pomoci toho by se dalo prorazit sifrovani souboru, nejake ochrany a tak dale - pokud se mylim tak me opravte :-)

intellll: Jestli ono to nebude spise tim, ze HT v realu zvysuje vykon o cca 5% a oba uvedene CPU jsou na tom vykonostne zhruba stejne a to dost dobre, takze v beznych aplikacich je pripadny narust vykonu stejne temer nepozorovatelny (neby Vy snad poznate, ze se web-stranka vykreslila o 20ms drive, nebo ze hra ma framerate 102fps namisto 98fps ? Asi tezko, ze ? A uvedenemu prikladu se S-ATA: ono jde o to, ze dnesni disky maji max. rychlost (sekvencniho) cteni do cca 80MB/s, takze i obycejne UDMA 100 s efektivni prenosovkou cca 90MB/s jim bohate staci. Vyhody S-ATA se projevi az v systemech se dvema (a vice) HDD diky dedikovanym 150MB/s pro kazde ATA zarizeni a dale pak v serverech diky podpore NCQ, hot-swap, AHCI, atd.. Dle ohlaseni prednich vyrobcu je  vsak nedaleko doba, kdy disky v dusledku rustu zaznamove kapacity (pomoci vertikalniho zaznamu) vyrazne zrychli a pak by jiz UDMA nemuselo stacit. Ostatne uz dnesni disky s 15k otackami a kapacitou 146GB dosahuji rychlosti cteni kolem 140MB/s, v provedeni S-ATA se ale zatim bohuzel nevyrabi. Navic ma S-ATA i nesporne mechanicke vyhody a je dobre, ze dnes jiz prehistoricke P-ATA jiz bylo konecne nahrazeno necim od zakladu lepsim a ne neustale vylepsovano neustalymi doplnky (LBA, UDMA1-5, LBA32, atd.), ktere stejne vyzadovali obvykle vymenu celeho hardware.

RaStr: lepsi mechanicky konektor S-ATA nema. Pokud pominu problemy s ata kablem a vyhodu tenkyho s-ata kablu, tak konektor (datovy) na S-ata je mechanicky podstatne horsi nezli ata.

A jeste si dovolim doplnit diskusi o HT ... to druhe, HT vlakno je takove "nechtene dite" architektury P4, ktere lze ale nekdy sikovne vyuzit, a co je podstatne, neni vubec ale vubec rovnocenne tomu hlavnimu vlaknu v procesore.

Itokar: to je vec nazoru, ja jsem s nim, zatim zadny problem nemel, i kdyz je fakt, ze vypada dost forove a asi toho mechanicky tolik nevydrzi, nadruhou stranu je zase pripraven pro hot-plug a asi se proste nepocita s tim, ze nekdo bude za ten kabel tahat, nebo s nim nejak pacit do stran, ze ? Navic UDMA kabely nejsou take nic moc, sice se to nezda, ale po nejake dobe se diky povytazeni kabliku z koncovky po nekolikanasobnem odpojeni zhorsi el. parametry natolik, ze se v prenosu zacnou vyskytovat chyby, CRC zabezpeceni prenosu to sice odhali, ale klesa propustnost. Je to videt ve statistice SMART a osobne jsem se s tim setkal, oproti tomu S-ATA konektory maji kablik zataveny a funguji bud na 100% nebo vubec (pri nedostatecnem zasunuti, nebo nasilnem odehnuti). 

MarSik: UDMA je specifikace predevsim pro format prenosu dat mezi host-adapterem a radicem(ktery je na disku). Softwareove se to chova prakticky stejne jako MW-DMA aplikovatelne jiz na PIO4 fyzicke rozhrani. Samozrejme, ze UDMA vyzaduje podporu na strane host-adapteru (vcetne jeho software, cili BIOSu ci OS driveru), i na strane IDE radice (integrovaneho na disku), ale zaroven ponechava i vsechna omezeni puvodni PIO a master/slave architektury, to jen tak na okraj.
Specifikace S-ATA zachovava UDMA, ci LBA z duvodu zpetne kompatibility v rezimu emulace standardniho IDE rozhrani, v nativnim S-ATA modu je obvykle uzito rozhrani AHCI, ktere pracuje uplne jinak, predevsim podporuje standardne az 64-bitove adresovani datovych bloku a az 32 S-ATA portu (cili minimalne 32 S-ATA zarizeni), takze umoznuje SW dokonale vyuziti vsech novych vlastnosti noveho HW rozhrani. Proste S-ATA v nativnim modu se spise podoba SCSI nez ATA .

>JeJe: Me 2 ... :-))
 
Prostě si pustímp rogram, kterému se chci trošku podívat "na zoubek" - na příklad nějaký ten SW DRM či Blu Ray player a v druhém threadu si očuchám pěkně klíče či další kryptované a / nebo kryptovací údaje ... prostě ideální "debug tool".