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.
Vím pouze o jednom porovnání výkonů Conroe-AMD, z něho je spíš víc otázek než důkazů. AntiHT není špatný nápad (pro tuto dobu, kdy je pramálo SW využívajícího více jader), ale budoucnost stejně patří optimalizaci SW pro vícejádrové procesory-systémy.
Ty museli vypadat...
@ Begy - celkem souhlas, vicejadra maji budoucnost.
Ale zatim se mohou u AMD zaridit podle soucasneho stavu a tudiz by toto bylo obchodne dobre reseni. Tak jako na FX nema zadny jiny procak pri hrani her, tento koncept by si napriklad hrace asi ziskal. Treba i blbe pakovani souboru to velmi vyuzije... proste pouziti pri single-core stale je.
Pokud by se jim nahodou podarilo prepinat prokac mezi mega-single-core and multi-core, tak to by byla fakt bomba.
To spíš vypadá na nějakou kachnu od AMD. Realizace něčeho takovýho je vysoce problematická a něco jako sčítání výkonů jader rozhodně neplatí. Když na takovým virt. procesoru bude systém pouštět víc vláken najednou, může to fungovat jako MT (ale spíš tam budou problémy - nebude to tak efektivní). Když tam pošle jenom jedno vlákno, výpočet by se měl nějak rozdělit na víc jader. Tady je řada problémů s realizací. Je to jako dělat aplikaci s jedním vláknem do víc vláken v reálným čase. Toto prostě někdy není možné, pokud se nejvíc času spálí v nějakém cyklu, který má každou iteraci závislou na předchozí. Pak nelze pustit 2 cykly (za sebou) paralelně, pokud jeden závisí na výsledích druhého, atd. Tyhle problém by šly částečně optimalizovat, pokud by tam byla dostatečně chytrá analýza kódu, takže by se tam spálilo brutální množství proc. času (muselo by to být chytřejší než Intel C++ Compiler v paralelizaci). Např. 2 filtry (po sobě) pro video by se mohly aplikavat skoro paralelně, pokud by ten druhý začal později, za předpokladu, že filtry zpracovávají snímek po řádcích.
Každopádně bych takovou technologii v dohledné době nečekal.
A co teprve komprese videa! Joj, kdyby to doslo od jedna pani povidala do skutecne realizace, to by se jarku prevadelo video jedna radost!
Vetsi blbost jsem po ranu jeste necetl. To co se v clanecku popisuje proste nejde. Prevedeno do polopaticke reci je to asi jako kdyby jste chteli zkratit dobu prepravy jedne osoby z bodu A do bodu B na polovinu tim, ze k preprave misto jednoho auta pouzijete dve identicka auta. Je zrejme, ze to proste nejde. Pokud mate osoby treba dve a jedno auto uveze prave jednu, tak pri uziti dvou aut namisto jednoho se doba preprevy obou z A do B muze zkratit na polovinu (pokud nebude ucpana silnice, atp.), ale jednu osobu tak urychlit nemuzete. To by slo jedine tak, ze by se ta dve auta "svarila" dohromady a vzniklo by tak jedno auto s osmi koly a dvema motory, pak by snad byla ta preprava rychlejsi, ovsem vysledek toho svareni je uz uplne neco jineho, v podstate je to nove vetsi auto s dvojnasobne vykonnym agregatem a neni duvod to delat tak komplikovane. Prevedeno do reci pocitacu, jiste, AMD muze vyvinout CPU s dvojnasobnym poctem ALU, dvojnasobnym poctem registru, dvojnasobnou velikosti cache, atd., atd., ktery bude mit dvojnasobny vykon v single-threaded aplikacich a nebo s pouzitim toho, cemu Intel rika HT se bude chovat jako 2 CPU s relativnim vykonem 1, ale to je asi tak vse!
ja sem to pochopil tak ze z vonku sa bude chovat ako 1jadrovy proc. ja to vidim tak ze ta funkcia bude prerozdelovat ziadosti (aplik. pisane pre 1 jadro) na viac jadier. a tym teoreticky znasobi frekvenciu.
To RaStr : s tema autama to je spis tak, ze vice paraelne zapojenych aut tahnoucich jeden vlek pojede porad rychleji nez jedno auto se stejnou zaprazenou zatezi ....
I kdyby se jim to podařilo s rozumnou účinností, tak je to plýtvání křemíkem.
To Richard: to sice ano, ovsem kde jsi kdy videl vice aut, aby neco paralelne tahli. U vlaku prosim, tam se zapojeni vice lokomotiv primo vybizi, protoze lokomotivy jsou navrzene tak, aby sledovali jedny koleje a je velice snadne je synchronizovat a tudiz zvysovat rychlost a vykon celeho vlaku pridavanim dalsich a dalsich "tahounu". Ovsem auta jsou stejne jako CPU v PC spise navrzena tak, aby kazde jelo kamkoliv se mu zamane (a bylo tak operativnejsi) a jejich spojovani dohromady je tak komplikovane, ze se v praxi radeji nepouziva a namisto toho se spise vyrobi vetsi a silnejsi auto jedine. Proto navesy prevazeji tahace a ne 4 Octavie v tandemu :-) !
Tohle je jen neefektivni slepa ulicka ... jedine spravne reseni je ze se budou programatori sami snazit problemy resit tak aby se na nich mohlo podilet vice procesoru soucasne ... tohle za ne zadna zazracna inteligentni technologie na strane procesoru neudela. Pokud AMD skutecne pujde touto cestou pripravi se jen o cas ktery by mohla venovat do vyvoje smysluplnych technologii ... udelali by stejnout chybu jako kdysi intel s NetBurst ... doufam ze je to jen kachna
Slepá ulička to rozhodně není a intel na tom pracuje taky - viděl jsem materiály o tomhle už zhruba před rokem(od intelu) a plánoval to tušm na rok 2009. Bylo to dokonce ve formě videa. Myslím, že to rozebírali na sh.
2DaGu: Kdybys o tom neco vedel, tak nenapises takovouhle blbost. Prave komprese videa je jedna z mala uloh ktery lze velmi snadno provadet na nekolika CPU. Ostatne, kazdej rozumnej SW to umi, staci mit bud nekolik CPU nebo nekolik kompletnich PC, funguje to totiz i po siti.
K te technoligii, planovat neco takoveho v delsim horizontu je trochu nesmysl, bylo by trba neco takoveho mit ted, za par let se aplikace prizpusobi spis vyuzivani vice procesoru a doufam ze vyvojari budou natolik inteligentni a nebudou to omezovat na konkretni pocet.
Za slepou ulicku to nepovazuju do te doby, dokud se bude programovat prevazne pro singe-core procesory (coz bude asi jeste relativne dost dlouho)
Nechtěl jsem reagovat, ale kdo tvrdí, že je to slepá ulička, tak si asi dostatečně neuvědomuje, co asi řeší multiprocesorové superpočítače... Prostě zpracování jednoho úkolu se na strojové úrovni přerozdělí mezi více jader, a je celkem irelevantní, jestli jsou v jednom pouzdru či nikoliv... Asi to nebude jednoduché, ale znáte někdo vynález třeba J.Verna, který by nakonec nevznikl? :)) Co se vysloví, to bude vynalezeno...
trilobyt: ajaj... pokud má úloha využít více procesorů (jader), musí být podle toho napsána. Pokud mám "program":for (int i = 0; i < 1000000000; i++);nepomůže mně asi 100 procesorů, poběží to pořád stejně rychle, protože není čím ty zbylé procesory zatížit.Jinak kódování videa je pro více CPU optimalizováno už dnes (jestli to využívá ta která konkrétní aplikace, je jiná pohádka). Některé hry taky.
Obecně bych to označil za slepou uličku, výkon jednoho 3 GHz CPU na většinu věcí stačí a více jader se pozitivně projevuje také na multitaskingu (když kóduju video, můžu ještě v pohodě pracovat - to by se single-core nešlo), nejen na tom, jak rychle skončí nějaký výpočet.
Pro cdr.cz: nechcete už něco udělat s tím editboxem, abych nemusel startovat IE jen proto, že chci použít blbé tučné písmo a kurzívu? Už i na idnes.cz to mají vyřešené, styďte se! Nerad to píšu, ale mám pocit, že od té doby, co jste zavedli dobrovolné placení, na čtenáře kašlete; už dost lidí vás na to upozorňovalo :-(
To je kachna jak vysita. Na to, aby bylo mozne zatez rozdelit mezi paralelni procesory (t.j. zpracovavat neco soubezne) je nutne zjistit, ktere casti programu musi bezet samostatne (tzv. kriticke sekce). Tento problem ale neni algoritmicky mozne resit (neni vypocitatelny) a tudiz je rozdeleni jednoho threadu na vic nemozne bez pomoci programatora...
Neni to tak davno, kdy by jsme vsichni kriceli, ze rychlost zvuku nikdo nemuze prekonat :-) a ejhle ....
Jen jedno vlakno? To bych chtěl vidět jak to bude fungovat.
Já neznám strukturu vláken, ale jestli se nepletu tak na pozadí běží spousta SW v samostatných vláknech, který nemůžeme vypnout Například drivery - LAN, monitor, myš, antivir, jádro operačního systému.
@Jano: To samozřejmě automatizovaně řešit lze, a už je to dnes řešeno v kompilátorech (znovu uvedu Intel Compiler). Problém je ten, že počítače se zdaleka nemůžou dnes srovnávat s lidským mozkem, takže výsledky nejsou příliž potěšující. Podle mé zkušenosti vám to přidá asi 10-40% na rychlosti. Ale to má kompilátor přístup k C++ kódu, kde to lze optimalizovat snadněji. My tu ale mluvíme o rozdělení strojového kódu na víc jader, což je opravdu poměrně těžko realizovatelné.
Libb: no, tuhle ukazku zoptimalizovat pro vice procesoru problem neni :)
podla mna to bude v buducnosti riesenie ako zdvihat frekvencie,kedze sucasna technologia zatial to riesi stale mensou vyrobou (teraz 65nm, za rok 40nm atd)...vysledkom bude neskor napr nie 8x 2,6ghz cpu do jedneho 20ghz ,ale napr do dvoch 10ghz
proste cesta viacerych procesorov zostane,ale ked sa dojde na koniec a uz sa nebudu dat zvysovat frekvencie, tak miesto nezmyselneho pridavania nekonecneho poctu jadier sa tieto jadra budu spajat do vacsich celkov, kt si uz lepsie poradia s dotycnymi threadmi
@trilobit: Ono to prerozdeleni nebude nejen slozite ale i nemozne. Pokud je nejaky thread, ktery lze rozdelit na vice dilcich uloh, tak to tak ucini uz programator pri psani kodu, nebo kompilator pri optimalizaci. Pokud to ucinit nelze, tak s tim proste nehne ani sebelepsi hardware. To co si dovedu pod tim o cem se tu mluvi predstavit je vlastne jen prohloubeni jiz v soucasnosti pouzivaneho paralelismu zpracovani instrukci, napriklad mohu jeden thread rozdelit na ctyri casti kazdou znich pak spustit na jednom jadru a pote, zo bude dokoncen vypocet te prvni, provede se analyza, zda cinnost prvni casti nejak ovlivnila vstupni data jiz predtim provedene casti druhe, pokud ne, tak se pouziji jiz hotove vysledky druhe casti (v opacnem pripade se bude muset druha cast znovu prepocit, ted jiz s aktualnimi vstupnimi daty) a cely postup se opakuje pro cast treti a ctvrtou. V optimalnim pripade se pak beh celeho threadu skutecne urychli az ctyrnasobne, ovsem to jen za predpokladu, ze kazda cast bude datove nezavisla na tech castech ostatnich. Ale pokud tomu tak opravdu je, je daleko snazsi takovy thread rovnou napsat jako mutithreadovy task, takze ono vylepseni CPU bude fungovat je u spatne napsanych (zkompilovanych) aplikaci, jinak to bude jen zbytecne zvysovat prikon CPU (protoze se budou neustale zbytecne vykonavat cinnosti, jejichz vysledek se pak stejne bude muset ignorovat). Ovsem tohle vsechno uz dnesni CPU umeji, takze to vlastne neni zadna velka novinka, i kdyz mozna je to novinka pro AMD, protoze momentalne je v predikcich lepsi spise Intel, at uz se jenda o vetveni, nebo o pristup ke cache, atd. takze pokud chce AMD udrzet krok a pripadne vedeni, bude na tom muset take radne zapracovat.
K tomu Verneovi: ukazte mi, kde se prakticky pouziva elektricky pohaneny letoun (dokonce vlastne vrtulnik), krome modelariny a mozna jednou nekde na Marsu zatim nikde ! To jen tak napriklad. J.V. toho sice predpovedel celkem hodne, ale zaroven take predpovedel spoustu veci, ktere se pak z ruznych duvodu nikdy nerealizovali, takze v souhrnu se da rici, ze byl sice nesmirne inventivni, ovsem pravdepodobnost "zasahu" zase az tak velka nebyla, namatkou jeste treba: doprava nakladu (nerku-li lidi) alespon na obeznou drahu delem - neexistuje, vynalez zkazy - neexistuje (castecne sice mozna v podobe nuklearnich zbrani, to ovsem ani zdaleka neni ono, atomovka se neda udelat dostatecne miniaturni, ani rozmery a ani ucinky, takze jako nahrada strelneho prachu naprilad vubec nejde pouzit), a nasli by se jiste i veci dalsi, kdy byl J.V. bud uplne "mimo" a nebo znacne nepresny. Je sice pravda ze docela hodne toho, o cem se J.V. rozepisuje, se sice casem "nejak" podarilo, ale zpravidla znacne jinak, nez J.V. nastinil, prikladem budiz treba prave Cesta na Mesic, projektil vystreleny z dela na Mesic, bez moznoti rizeneho navratu na Zemi, lze jen opravdu jen tezko nejak nalezt v projektu Apollo, i kdyz nektere dilci podobnosti tam samozrejme budou, nektere principy byly obezne zname jiz v dobe J.V., napr. ze lide dychaji kyslik a vylucuji jinak jedovaty CO2 a tudiz bude potreba v uzavrenem prostoru provadet upravu atmosfery bylo celkem dobre znamo jiz dlouho pred J.V., takze to, ze to J.V. ve svem dile zminuje a v praxi se pak opravdu muselo provadet, zase az tak podivuhodna souhra okolnosti neni.
Může to být užitečná technologie, ale záleží na tom, jak dobře bude udělána a nakolik ji budou chutnat současné nemultithreadové programy.
Libb: My to v plánu máme, ale teď byly pro nás poněkud důležitější priority. Nyní máme rozděláno něco, co nám dramaticky ulehčí a zrychlí publikování a až bude hotovo i to, tak tohle bude první věc, která se udělá.
PS: Já sám taky píšu ve Firefoxu, takže to uvítám...
2 RaStr & Libb: Díky za Váš názor, ale já se budu dál usmívat :))
Evidentně jste ze skupiny lidí, kteří pracují s daty a fakty a denně odvádí svoji otrockou práci. Ti co mají VIZI sedí nad Vámi, celé to řídí a někam směřují, a ještě se u toho baví.
Analogie s lidskými smysly: sluch = sériové zpracování, zrak = paralelní zpracování ... opravdu si myslíte, že se obejdete jen s multi anebo jen se single?? Kdepak... mezi tím se musí bedna rozhodnout a použít optimální proces využití zdrojů které má k dispozici tak, aby se neflákaly...
Vynálezy J.V. neuvedené do běžného života byly samozřejmě z části nahrazené jejich dokonalejší variantou, ale na druhou stranu J.V. viděl v některých ohledech ještě dál. Např. dodnes nemáme dokonalé baterie, ale už se na tom pracuje... Předností J.V. bylo to, že kromě vize se docela tvrdě vzdělával a obšírně studoval techniku...
P.S. Když jsem před 20 lety koukal na Startrek v dosahu signálu rakouské televize, taky jsem považoval osobní komunikátor s videopřenosem za kouzlo z pohádky :)))
A taky nikdy nepochopím, že vědci dokázali výpočetně prokázat existenci až 10-rozměrného prostoru... ?! :))
Ale to je pro jinou diskusi... No flamewar please...
@RaStr: Tvoje řešení pokus a omyl naneštěstí přináší další problémy. Algoritmus napsaný programátorem zpravidla nemusí zvládat výpočty s neočekávanými daty, která by tam lezla vždy, tzn. kromě špatného výsledku by to generovalo i fatální chyby / unhandled exceptions.
Řešení, které se nabízí, je identifikovat jednotlivé proměnné (paměťové lokace), zjistit si závislosti proměnných, a pokud jsou na sobě nezávislé, je možné provádět paralelizaci (to je ta jednoduchá verze). Pak je možné i provádět par. závisle proměnných, ale to vyžaduje hodně výpočetního výkonu. Když to budeme chtít dělat efektivně, nemá smysl vytvářet tisíce vláken. Je potřeba vytvořit jenom ty, které se provádí dlouho, což můžou být v reálu iterace nad nějakým polem / seznamem. Toto poznat ze strojového kódu musí být opravdu zážitek. Tímto přeji AMD hodně úspěchu při řešení.
trilobyt >> ty si zjavne nepochopil priklad s autami. RASTR >> poklona, takto vysvetlene by to mal pochopit aj uplny magor. Nuz ale nestalo sa. Vizionari asi nikdy neskusali programovat na urovni ASM, preto nepoznaju matematicky dokazane obmedzenia programovania.
Ono to nie je taka sprostost ako sa niekomu zda AMD do novej generacie ccHT/cHT cache coherent HyperTransport vlastnost, ze si CPU budu cez neho "prepoziciavta navzajom volne vypoctove jednotky podla potreby" to sa samozrejme tykalo len multiCPU systemov, a uz to na ITnews nie je je tu nieco podobne a sice CPU si moze prisvojit jednotky koprocesora.
http://www.itnews.sk/buxus_dev/generate_page.php?page_id=40071
A v tom clanku je opisane len to, ze si okrem vypoctovych jednotiek bude vediet nazdielat/prisvojit si aj dekodery mikroinstrukcii, co je tiez len jednotka CPU.. Navyse CTO (Chief Technology Officer) AMD povedalm ze buducnost AMD je v CELL LIKE ARCHITEKTURACH a toto je nieco podobne... Takze by som to nezavrhoval...
Keby ste tak videli
Conclusion
INTEL is 5 generations behind AMD, and there are other major areas that INTEL is lacking, such as IOMMU for fast DMA. To match AMD in 2 core performance, INTEL will have to use very large cache size, which will negate its shrink to 65nm. At 4 core and up level, INTEL is simply hopless.
http://sharikou.blogspot.com/2006_02_01_sharikou_archive.html
Teoreticky by to slo, jako obdoba WLIW architektury + rozdelovani instukci do vetsiho poctu vykonovych jednotek.
2RaStr: Trochu te zklamu, ale naklad na obeznou drahu dopravit delem lze, je to otestovano a je to dokonce mnohem efektivnejsi nez raketovy pohon. Jen je trochu problem v pretizeni, ale daly by se tak velmi snadno dopravovat mechanicky casti zakladen, nektery zasoby ... zkratka cokoli co bez uhony prezije spoustu G.
jak jiz tu nekdo psal, vlastne jiz neco takoveho v soucasnosti na procesorech funguje.
Procesor paralelne vykonava nekolik casti kodu dopredu a kdyz dojde prvni cast nakonec tak kontroluje jestli se zmenili podminky ktere odhadl pro zacatek druhe casti. Jestlize se zmenili tak musi pochopitelne zahodit celej predpocitanej vysledek, ale uspesnost odhadu je celkem vysoka (cca 80%) takze je to celkem dobra cesta. Samozrejme pri vetsim rozdelovani musi byt daleko slozitejsi algoritmy, ale jestli na tom jiz AMD delsi dobu pracuje tak by to skutecne mohlo byt dobre reseni.
Paralelne neco primo programovat pri vyvoji aplikace je velmi slozite a u normalnich aplikaci neumerne zvysuje naklady na vyvoj tudiz se to pro 95% aplikaci naprosto nevyplati. Vyplati se to jen u velmi narocnejch ukolu ktere jsou jiz ze sve podstaty prirozene paralelizovane (video, hry- zvuk,grafika,AI, ...)
Presto ze jsem si na zacatku cteni prispevku jako mnozi myslel, ze to je naprosty nesmysl, jak jsem o tom behem cteni premyslel, realizovatelne to je za predpokladu:
Beh programu se rozdeli s pomoci TDM (Time Division Multiplex) na useky, ktere bude mozno realizovat paralerne(budou mit nezavisla data a vysledky) a kazdy usek pak bude zpracovavat jeden procesor. Jinymi slovy v programu bude sice fyzicky (resp. logicky) jedno vlakno, ktere se ovsem virtualne rozdeli na vlaken nekolik a ty pobezi synchronizovane na jednotlivych procesorech. Samozrejme to vyzaduje urcite postupy pri programovani a navrhu tech procesoru a chipsetu, ale pokud je nekde potreba maximalni vykon, tak to vyzaduje i normalne.
Celkove to na me dela ale dojem spis marketingoveho tahu a klicky pred licenci na HT, protoze se jedna ve vysledku o totez, jako by to nekdo naprogramoval normalne vicevlaknove a vyuzival HT.
Priklad s auty tahnoucimi vlak je zcestny, protoze se jedna o uplne jinou koncepci v tomhle pripade se nejedna o vahu, ale o objem.
Podľa mňa na to idete moc komplikovane. Nič kreatívne som tu ešte nečítal. Každý je len zabednený v klasickej predstave paralelných výpočtov. Nikde predsa nie je napísané, že v jednom takte musia naraz pracovať všetky jadrá. Majme napr. časovač ktorý generuje takt 20.8 GHz. Za ním je delič, ktorý rozdeľuje jednotlivé takty cyklicky jednotlivým jadrám. Takže v konečnom dôsledku každé jadro beží na tých svojich 2.6 GHz. Jednotlive jadra pracujú pekne postupne. Teraz už len musíme zabezpečiť aby každé jadro pracovalo na rovnakých dátach. Pokiaľ viem tak stojové inštrukcie vedia pracovať s dátami v pamäti alebo v registroch. Pamäť je len jedna a registre prepojí ten HyperThreading. Tým pádom budu jadra spracuvávať dáta sekvenčne v správnom poradí. Nasledujúce jadro nájde v registroch výsledok výpočtu predchadzajúceho jadra. Netreba žiadne úpravy kódu. Viem si dokonca predstaviť žeby sa dali dynamicky vytvárať viaceré rôzne rýchle virtuálne jadra.
2dahab: Sice hezka idea, to co popisujes, ale nic moc objevneho. Krome toho, ze pamet je sice jen jedna a dostatecne rychly pristup do ni muze byt trosku problem, tak pro registry to plati stonasob. Takze tak jak to popisuje to asi nepujde. Nicmene presne to same, co navrhujes se dnes uz v CPU davno deje, mechanismus se jmenuje pipeline a umoznuje krome zvyseni taktu take vykonavat v jednom taktu vice instrukci nez jen jednu, coz je to, co se snazite nazvat paralelnimi vypocty. Ovsem, pokud vam to kremik dovoli, je mozne zvysovat max. pocet instrukci proveditelnych soubezne, narocnost navrhu vsak roste s poctem instukci v jednom taktu geometrickou radou a tak napr. P4 (NetBurst) zvlada 3 a nova generace Core CPU jen 4 instrukce za cyklus a pokud se neprejde na nejakou vyrazne zjednodusenou instrukcni sadu typu RISC, tak se ty pocty asi nijak zasadne nezmeni. Navic i pri vysokem poctu zpracovatelnych instrukci v jednom taktu se muze stat, ze celkovy vykon nebude nic moc, pokud bude mit CPU problem s pristupem k RAM a tedy datum a instrukce budou muset na data cekat. Tento problem melo puvodne AMD, proto musel byt pametovy radic integrovan primo do jadra CPU, tim mohla CPU od AMD vice vyuzit svuj potencial vykonavat v jednom taktu vice instrukci nez konkurecni INTEL, a tak se jim nakonec i pres nizsi dosahovane takty podarilo INTEL CPU vykonostne dohnat a predehnat.
Tato diskuze je nyní společná i pro článek Pár střípků o „Anti-HyperThreadingu“ AMD.
Tato diskuze byla založena k článku AMD asi kutí „HyperThreading naruby“.
dahab:
to je sice pekny ale pak by ty jadra museli vydrzet 20Ghz na dobu kdy maji bezet
tech 2,6GHz je blbost , to by bylo neefektivni, bylo by to jen stridani x jader a vykon by byl mensi - velke pametove presuny a tak,to by bylo jako stafeta, kdyz dobehne 1. vybehne 2. pak az dobehne 2. vybehne 3. to je blbost furt bezi stejnou rychlosti, zde neni urychleni :))) :))) :)))) hahaha
spis udelat x jader na 20GHz a pridelovat jim cas behu po sobe(priklad 10 jader -tedy 1 jadro bezi treba jen 1/10casu a pak 9/10 odpociva aby se neznicilo) , aby to vydrzeli, takze v souctu by pak mohli dat vykon treba 15GHz a zbylych 5GHz by bylo pro presuny na sbernicich a tak podobne
rekl bych ze to je o tom premyslet a vymyslet
shit:
vyrobit x jader pracujich na 20GHz, je dost drahy, a je pak strasne neefektivni to drahy jadro vyuzivat z 1/10. Jestli neni lepsi vyrobit min a pomalejsich jader a vypocty provadet paralelne?
aktualizace operacniho systemu opravdu neni problem, staci stahnout novej kernel :-)
tahle funkce vypada vic nez zajimave, doufam ze se AMD povede, a bude mit tudiz dustojnou konkurenci proti Intel Conroe atd...
adr> Tady nejde o cenu, ale o dosazitelny vykon. Technologie vyroby se vyviji a cena muze jit natolik dolu, ze jiz nebude omezujicim faktorem. Co ale zustane jsou fyzikalni omezeni. Hlavnim limitem je tepelna vodivost kremiku, jakmile mnozstvi tepla produkovaneho v male plose dosahne urcite vyse danne prevazne vodivosti samotneho aktivniho materialu, uz se to proste neda uchladit. Zvetsit plochu aktivniho prvku a tak to teplo "rozprostrit" nejde, protoze velke tranzistory maji veke kapacity a nemohou pracovat na velkych rychlostech. Cili vice jader by mohlo problem castecne resit, protoze kazdy tranzistor ma i urcitou tepelnou kapacitu, takze kratkodobe snese i urcite vykonove "pretizeni". Ovsem zustava problem chlazeni celeho CPU, pokud bude mit CPU na 2GHz cca 50W prikonu, tak na 20GHz bude mit prinejlepsim 500W, spise ale 5kW i vice, protoze prikon neroste s taktem linearne ale spise geometricky, a uchladit takove CPU je sice mozne, ale neprakticke. Ostatne s necim podobnym se INTEL jiz zabyval, v dnesnich CPU je produkce tepla nerovnomerna a vznikaji zony az 10x teplejsi nez je prumer a prave ty limituji maximalni mozny takt celeho CPU, takze jejich lokalnim prichlazenim by bylo mozne dosahnout zvyseni taktu celeho CPU pomerne snadno. Problemem je ze pri vyuziti napr. integrovanych peltierovych clanku, by se az prilis zvysila celkova produkce "odpadniho" tepla a to je uzivatelsky neprijatelne, jen malokdo by mel zajem o CPU s prikonem 2KW, byt by pracoval na 40GHz (ja bych si jej ale urcite koupil :-) !
adr> Tady nejde o cenu, ale o dosazitelny vykon. Technologie vyroby se vyviji a cena muze jit natolik dolu, ze jiz nebude omezujicim faktorem. Co ale zustane jsou fyzikalni omezeni. Hlavnim limitem je tepelna vodivost kremiku, jakmile mnozstvi tepla produkovaneho v male plose dosahne urcite vyse danne prevazne vodivosti samotneho aktivniho materialu, uz se to proste neda uchladit. Zvetsit plochu aktivniho prvku a tak to teplo "rozprostrit" nejde, protoze velke tranzistory maji veke kapacity a nemohou pracovat na velkych rychlostech. Cili vice jader by mohlo problem castecne resit, protoze kazdy tranzistor ma i urcitou tepelnou kapacitu, takze kratkodobe snese i urcite vykonove "pretizeni". Ovsem zustava problem chlazeni celeho CPU, pokud bude mit CPU na 2GHz cca 50W prikonu, tak na 20GHz bude mit prinejlepsim 500W, spise ale 5kW i vice, protoze prikon neroste s taktem linearne ale spise geometricky, a uchladit takove CPU je sice mozne, ale neprakticke. Ostatne s necim podobnym se INTEL jiz zabyval, v dnesnich CPU je produkce tepla nerovnomerna a vznikaji zony az 10x teplejsi nez je prumer a prave ty limituji maximalni mozny takt celeho CPU, takze jejich lokalnim prichlazenim by bylo mozne dosahnout zvyseni taktu celeho CPU pomerne snadno. Problemem je ze pri vyuziti napr. integrovanych peltierovych clanku, by se az prilis zvysila celkova produkce "odpadniho" tepla a to je uzivatelsky neprijatelne, jen malokdo by mel zajem o CPU s prikonem 2KW, byt by pracoval na 40GHz (ja bych si jej ale urcite koupil :-) !
Jedna se o dotazeny Hyperthreading do konce. AMD potrebuje pridat dekodery, aby se vyrovnalo/predbehlo Conroe, ale s kazdym pridanym dekoderem jeho efektivita klesa. Zkratka pri vicevlaknovych operacich jsou rychlejsi 2 jadra po dvou dekoderech, pri single vlaknu 1 jadro se 4 dekodery. Jedine OS tohle muze efektivne ridit. Super napad. Je tady nekdo si mysli, ze AMD za dobu od uvedeni A64 nepracovalo na nove architekture? :-)
adr:
ty asi nechapes ten problem, v tom pripade je tedy lepsi udelat jedno slozity a velky jadro se spoustou sbernic atd... ktery udela za jeden cyklus treba 15 instrukci,i kdyz bude drazsi a slozitejsi
porad bude rychlejsi nez paralelni blbosti - ty proste nejdou do nekonecna - existuji realna omezeni a vyuziti x-jader === 100procentni podminky pro max. vykon neexistuji a existovat nebudou, leda ze by se z cpu udelala odlehcena kalkulacka ci neco jako x GHz RISK procesor s minimalnim poctem instrukci a pak by nebyl problem i tech 80GHz :)), to uz by pak ale nemuselo byt PC PC
to by bylo mnohem rychlejsi nez delat min slozity jadra , ale delat jich zase 2,4,6,8,ci ci do jednoho cipu, dnes je to spis otazka ceny, ale za rok po tom ani nestekne pes
Ach jo,tady je to samy odbornik na GHz...ovsem docela tu zapominate na 1 vec,totiz na rychlost elektrickeho proudu.Ony ty elektrony tam totiz litaji jen OMEZEMOU rychlosti,ktera se slabe blizi rychlosti svetla,ale to samo o sobe je pomerne POMALA rychlost.Cetl jsem pomerne odborny rozbor kam az muze jit teoreticky kmitocet CPU a je to kolem 10GHz,neresim teplo a jine veci,pouze teoretickou moznost elektronu doletet z bodu A do bodu B.
300000km/s je tu odbornik co spocita rychlost GHz pokud ti body jsou v 45nm ci 65nm vyrobnim procesu
nepocital jsem zatim nic, ale odhad budou rady desitek az mozna i stovek GHz
Lojza:
precti si prispevky od Rastra, jsou dost presne a vystizne
Ono to zrejme bude uplne jinak. Vzhledem k tomu, ze nedoslo k zadnemu vetsimu prepracovani jadra, bude to nejspis figl prevazne na urovni SW s malou HW podporovu. Delat z jednoho threadu dva ani scitat zdroje proste NENI MOZNE.
Podle me to bude fungovat tak, ze na druhem jadru pobezi nejaky spekulativni thread, ktery bude "zametat cesticku" pro hlavni thread na prvnim jadre a ten tim padem pobezi rychleji. Bude tedy delat prefetch dat, resit vetveni a ruzne podobne pomocne zalezitosti.
Mno,ale ono nejde o to,jak rychle ten elektron prolitne jednim tranzistorem ci klopnym obvodem ci nejakou podobnou elementarni jednotkou...jde o to,za jakou dobu se informace dokaze prenest z JEDNE strany CPu na DRUHOU stranu CPU.A to uz je problem.Tedy je uplne jedno,jestli se jedna o 90,nebo 65 a nebo 5 nm technologii.Porad je tu problem toho,ze ten samotny cip je nejak velky a te informaci to trva,nez se na jedne strane nacte a na druhe vypusti ven(toto rikam velmi zjednodusene). A z fyzikalnich duvodu je obtizne se dostat realne nad 10 GHz.Ono to samozrejme teoreticky jde,ale potom uz by proste ty klopne obvody nestihaly klopit a elektrony litat,takze muzeme udelat vice GHz,ale nic to nespocita uz.Proto se uz nyni uvazuje,jak ZMENSIT samotny cip,a zcela vazne se uvazuje o "3D" reseni,tedy zmenseni cipu a jeho vetsi rozsireni smerem "nahoru".Ne nadarmo ma napriklad lidsky mozek takovy tvar jaky ma.Ostatne i pro CPU by bylo nejlepsi,kdyby samotny cip mel tvar koule,ale to by se asi blbe realizovalo:-))
Lojzo, přečti si články - IBM otestovala 500GHz procesor, spekulují o 1THz
tv: tranzistor. to je hoooooooooooodne velky rozdil.
TV->to bude asi nejaky omyl,ne? 500GHz CPU???? chapu jeste 500 GHz tranzistor ci klopny obvod,ale CPU?? Dnes se slavnostne pri teplotach kolem absolutni nuly dari taktovat na 5GHz,mozna 6 ... jednou to urcite dojde na tech 10 a mozna casem i na tech 10 pri beznem chlazeni,ac o tom pochybuju...Ale 500? to je nejaky omyl asi...Apropo - proc se podchlazuji CPU na skoro 0K? Nikoliv jen kvuli produkovanemu teplu,ale take proto,ze pri nizkych teplotach dramaticky klesa odpor a zvysuje se rychlost elektrickeho proudu...(viz trebas supravodice,ale to uz jsme nekde jinde).Takze jak uz jsem psal kdysi - do budoucna uz mame limit rychlosti uz temer z poloviny vycerpany,pokud chceme dale zrychlovat,budeme to muset delat jinak nez zvysovanim taktovaci frekvence
Lojza : polovodice jsou pri 0K izolanty, musi primesy musi byt dostatecne ionizovane , aby zmensily energetickou barieru mezi vodivostnim a valencnim pasem
Lojza> rychlost pohybu elektronu neni az tak dulezita. Je mozne si to predstavit treba jako vlak, ktery ma vsechny vagony (elektrony) hezky srazeny k sobe, tj. dotykaji se narazniky. Pokud do takoveho vlaku na konci strcim, tak zacatek se mi zacne pohybovat za l/c (kde l je delka vlaku a c je rychlost svetla v materialu toho vlaku, cili cca 210 tisic kilometru za hodinu u medi), cili prakticky ihned, pritom vsak jednotlive vagony nepojedou po kolejich rychleji nez par centimetru za sekundu (cili obdobne jako elektrony v kremiku). Jediny pripad, kdy bude zalezet na rychosti pohybu samotnych elektronu, bude situace, kdy na konci toho vodice umistim nejaky detektor, ktery bude registrovat prave kazdy proletajici elektron, to se ale vetsinou nedela, vetsinou se registruje zmena el. pole a ne samotny elektronovy tok (resp. spravneji tok nosicu naboje, protoze to nemuseji vzdy nutne byt prave elektrony).
shit> pro cip o delce hrany 1cm a meterialu med (CSV 70%) vychazi rychlost prenosu na cca 500 pikosekund. Cili za pozadavku zachovani synchronnosti dat a hodin, nemuze takt presahnout nejakych 20 GHz, v realu pak spise 10GHz, ovsem CPU muze byt navrzen i tak, ze prenost dat po jeho sbernicich bude probihat asynchronne, a pak takove omezeni neplati. Znamena to ovsem nutnost totalniho prepracovani architektury cipu. Da se to, ale zatim se to u PC CPU nepouziva, alespon pokud vim. Nicmene specializovane obvody, ktere takto pracuji, existuji a obvykle jsou takto reseny prave proto, ze museji by velmi rychle, ale jsou pomerne jednoucelove, coz jejich navrh dostatecne zjednodussi.
Lojza: IBM mluví o čipu, nikoliv pouze o tranzistoru, nicméně je jistě otázkou, jak byl ten čip složitý (asi moc ne).
Orig. znění:
Researchers from IBM and the Georgia Institute of Technology have demonstrated the first silicon-based chip capable of operating at frequencies above 500 GHz -- 500 billion cycles per second. That?s about 250 times faster than today?s cell phone processors and about 100 times faster than PCs. There is one catch ? the chip was cryogenically ?frozen? to 451 degrees below zero Fahrenheit (4.5 Kelvin). Such extreme cold is found naturally only in outer space, but can be achieved on Earth using ultra-cold materials such as liquid helium. (If you?re counting, Absolute Zero, the lowest possible temperature in nature, occurs at minus 459.67 degrees Fahrenheit).
?This work redefines the upper bounds of what is possible using silicon-germanium nanotechnology techniques,? said John D. Cressler, Byers Professor in Georgia Tech?s School of Electrical and Computer Engineering, and a researcher in the Georgia Electronic Design Center (GEDC) at Georgia Tech.
The chip experiments are helping to explore the ultimate speed limits of silicon-germanium (SiGe) devices, which operate faster at very cold temperatures. The chips used in the research operated at approximately 350 GHz at room temperature. However, computer simulations suggest that the silicon-germanium (SiGe) technology used in the chip could ultimately support even higher (near 1,000 GHz) operational frequencies even at room temperature.
holt ono je to cele o inom, je jasne, ze to je uz v sucasnych AM2 CPU, len nie su dosky, kde by to malo realne uplatneie- ono to totiz ma vediet spojit dve dual core CPU po 3 dekodery/jadro do jedneho single core s 12 dekodermi na jadro... Holt taky virual CPU by mal teoreticky vykon v single thread aplikaciach 12 Instrukcii za takt (Athlon ich ma 3, Conroe 4 a Pentium 4/D ich ma 2)
Dnes vysla na svetlo sveta
Opterony pre Socket 939 budu nahradenee tymy pre AM2
By Theo Valich: Friday 23 June 2006, 08:40
Dala sa cakat, ze Opterony rady 1200 budu pre Socket AM2, co sa ale necakalo je, ze aj Opterony rady 2200 budu tiez pre AM2. (t.j. budu dual Socket AM2 a to v suvislosti s tymto a Clearspeedom je o inom)
http://www.theinquirer.net/?article=32594
a to by hovorilo o AMD 4x4
Kódové jméno platformy je 4×4 a dá se to chápat jako dva sockety AM2 pro dva desktopové procesory s DDR2 paměťovým řadičem (Opterony s DDR2 paměťovým řadičem budou využívat 1 207pinový socket F).
http://www.cdr.cz/a/17687
Dosky pre 4x4 sa pripravuju
http://www.theinquirer.net/?article=32605AM
AMD plánuje návrat matematického koprocesora
AMD pre svoje nové procesory už licencovalo niekoľko veľmi zaujímavých technológií - ZRAM na zvýšenie hustoty a výkonu ich pamätí cache, pamäťový interface Rambus XDR - a posledným prírastkom zrejme bude matematický koprocesor od firmy Clearspeed.
Procesor Clearspeed CSX 600 sa využíva najmä v oblastiach lekárskeho výskumu, CAD a data mining. Pri vhodnom optimalizovaní inštrukcií je schopný dosiahnuť výkonu 25 gigaflops, teda 25 miliárd operácií s desatinnými číslami za sekundu. Pre porovnanie ? súčasné najrýchlejšie Opterony dokážu udržať výkon 5,7 Gflops
celý má čip spotrebu iba 10 W
http://www.itnews.sk/buxus_dev/generate_page.php?page_id=40071
ClearSpeed uviedol uvadza chip pre vedecke clustre
prva verzia je na PCI ale v priprave su aj verzie pre Hypertransport a PCI-X
http://www.infoworld.com/article/03/10/14/HNclearspeed_1.html
Co su to AMD akceleratory?
Zalozene je to na tom, ze sa pouzije coherent Hypertransport linka upravne pre koprocesory ccHT na pripojenie koprocesora k CPU
http://www.theinquirer.net/?article=29155
Boze fotoba! Ty si fakt psychopat! Moze mi to niekto pretlmocit?
Ja si myslim, ze to bude o tom, ze sa prerozdelia SSE instrukcie jednojadroveho procesora medzi obe jadra a podobne veci. Je zname, ze AMD nelame s rychlostou SSE rekordy. Toto je lahke overit, z ktoreho registra do ktoreho SSE instrukcia "rata".
Ale pravdive by to mohlo byt, zmena soketu koli pamatiam? Aj ked to neprinieslo vyssi vykon, prave naopak? Snad si to predtym vedeli obenchmarkovat a neurobili by takuto chybu.
len_user>
je to uplne, ale uplne, inak ako pises...
dnesna superskalarna architektura CPU funguje tak, ze instrukcie sa rozdelia na mikroinstrukcie a tie sa vykonvaju v vykonnych jednotkach - tych ma kazdy iny pocet... Kedze niektore po sebe iduce mikroinstrukcie z jedinej x86 instrukcie sa mozu vykonavat v roznych jednotkach cim sa zvysi vykon. Preco tych jednotiek nie je viac je v tom, ze napisat mikrokod - nieco ako firmware CPU-, ktory moze menit BIOS, pokial jeho cast POST, nazapne cache -
tak sa uz od Pentia riesia HW problemy, zmenou mikrokodu, tak aby sa chybe vyhlo...
AMD cez mikrokody riesi viacero produktov, kedze kremik je ten isty
Opteron - mikrokod je riseny tak, aby najrychlsejsie boli server aplikacie a ostatne programy su tym pomalsie - zisk je 20% strat moze byt aj 40%
Athlon FX- aby najrychlejsie su hry
Athlon - najrychlejsie su aplikacie, ktore povazuje AM d za typicke
Sempron - najrychlejsie su kancelarske aplikacie
Turion - dozraz sa kladie na znizenie spotreby, lebo aj to sa da riesit mikrokodom
AMD je asi mesiac distributorom Transmenty, ktorej CPU dokonca vie menit svoj mikrokod tak, aby bol optimalizovany na ten program, ktory prave bezi - vola sa to CodeMorphing
Mozno je to nejaka verzia tohto, kedze kazdy dekoder ma svoju pamat mikrokodov., moze ist o zdielanie mikrokodov medzi jednotkami a/alebo optimalizacia jedneho jadra na nejake ulohy a nejaku logiku, ktora prideli x86 instrukciu tomu jadra resp. jednotke, ktora je optimalizovana na danu ulohu- v ramci jednho jadra sa vybera to, na ktorom podla zatazenia a optimalizacie , prebehne kod najrychlejsie, ale je to prilis tazke urobit pre vela jednotiek. mozno to AMD robi vo viacerych krokoch..
Nieco tam musi byt
AMD CPU maju vacsie jadra a via tranzistorov ako tie pre Scoket 939
pri dual core z 194 mm^2 na 220 sq^2 ,a pri pocte tranzistorov z 233mil na 243mil pri single core je to z 106 sq^2 na 126 sq^2 resp. z 120mln na 129mln.
teda DDR-II radic ma oproti DDR radicu o 9 mil viac tranzistorov
jadra sa u AMD pripajaju na System reguest intreface, pricom SRI single core uz vie pripojnie dvoch jadrier z SRI to ide na X-Switch a odtial do radica RAM a na radic Hypertransportu ale dual core maju navyse nieco co ma 1 mil tranzistorov a o tom sa nic nevie co to je...
Fotoba, takhle jsem se uz dlouho nenasmal. Takova snuska nesmyslu se jen tak nevidi :) Optimalizovat procesor pomoci mikrokodu na konkretni aplikace - ROFL (hlavne ten Sempron). Sectely jsi opravdu dobre, jen by to chtelo obcas pouzivat takove to sede, co mas mozna v hlave...
Lojza a spol: Nemůžu se úvodem ubránit jednomu citátu:
" Když něco prostě nejde, vždycky se najde nějaký blbec, který neví, že to nejde, prostě jde a udělá to."
Vizionáři jsou potřeba, kdyby jich nebylo, tak dnes diskutujeme pravděpodobně o něčem jako jestli je možné slézt ze stromů a žít na zemi... Čas ukáže, jestli je to AMD kachna nebo jim to bude fungovat (oni asi o konstruování procesorů ví o něco víc, než my všichni dohromady).
Jednou všichni ví, že je Země placka, pak všichni ví, že je Země středem vesmíru...
Když jsem končil školu (1990), tak všichni věděli, že mezní frekvence pro křemík je 100 MHz a dál to nejde (naštěstí se našel ten správnej blbec). Dnes třeba uplink na satelity běží někde kolem 20 GHz (a v tom vysílači asi jenom jeden tranzistor nebude).
PS: Link bohužel nemám, ale cca před pěti lety jsem četl o USA firmě, která má technologii (teoreticky) na dopravu cca 100 kg nákladů na oběžnou dráhu výstřelem z děla (hlaveň dlouhá cca 500 m, postupné odpalování náloží = postupný nárůst přetížení, odpružení nákladu atd). Tuším že mluvili max o 20 g, takže pro většinu nákladů v poho při ceně kolem 10% ceny rakety za stejný náklad. Když jsem o nich četl, tak sháněli investory, soudě podle dnešního stavu asi (zatím...) všichni ví, že to nejde.
Ne, ne AMDéčko, už asi zase má firmu Intel v kapse, a ani procesor Intel Core Solo, už Intel nezachrání, holt prostě ve firmě AMD, jsou prostě fakt chytrý lidi, no teda nezachrání, teda ne že by Intel zkrachoval, ale AMD zase válí, no možná, že Intel bude firmě AMD, zase tak trochu koukat na záda, no!
fotoba> este k tomu si aj dislektik...
Btw. kolko moze zabrat IOMMU?
xR> Optimalizovat jadro mikrokodom sa asi skutocne da, ved aj pri xeonoch v serveroch je nastavenie na optimalizaciu IO, alebo vypoctoveho vykonu, neviem sice co to presne nastavuje, mozno to s mikrokodom nesuvisi, ale kedze risc jadro cpu od amd vykonava mikrokod ktory realizuje samostatne instrukcie, mozne to je, ale podla mna sa tie procesory lisia len v cache/pocte ht liniek/funkciami na setrenie energie.
Rhino> No mozno je 100MHz maximum pre kremik, ved ani dnesne tranzistory nie su vyrobene z cisteho kremika a ten 500GHz cip tiez nie je z kremika.
fotoba: Tak bud si blbej ty nebo Eagle, co se tyce moznosti microcodu, tak mate oba presne opacne nazory, prosim rozpravu na toto tema. :)
Pro ostatni co tadypindaji o omezeni pararrelizace a uvazuji v urovni software a instrukci x86 napsal blaznivy fotoba prece jen jednu dulezitou pripominku:
Dnesni x86 procesory se navenek tvari jako CISC, ale interne pod dekoderem jsou RISC, treba IA64 je cisty RISC - nema dekoder instrukci IA64, mikroinstrukce se sypou primo do vypocetnyich jednotek.
Zatimco treba P4 nebo AMD64 musi x86 instrukce prezvejkat a rozdelit do mensich, sobe nativnich RISC mikroinstrukci, ktere ma P4 a AMD64 odlisne. Parve zde je urcita nezanedbatelna sance pararelizace zdanlive, z pohledu x86 instrukci tvrde singlethreated ulohy... Komplexni x86 instrukce se rozdeli na vice mikroinstrukci a jde taky o to, jak tyto mikroinstrukce, pokud je to mozne zpracovat pararelne, prave tento interni pararelismus pro mikroinstrukce je u Core architektury proti AMD 64 zvetsen o 33% za idealnich podminek (ze 3 na 4).
Vetsina casto pouzivanych instrukci je u AMD64 implementovana primo, tedy bez mikrokodu. Podil instrukci implementovanych mikrokodem je v beznych programech tak maly, ze z vykonoveho hlediska nestoji vubec za rec. A hlavne jejich implementace je prakticky jedina mozna a optimalni. Zmena mikrokodu by prinesla akorat tak zpomaleni. A ten mikrokod je stejny pro vsechny CPU - at je to Sempron, nebo Opteron.
S tím dělem to není tak od věci....takové dělo se už stavělo v Iráku (jedinej Sadám byl ochoten investovat do toho prachy). Když byly hotový odlitky hlavně tak to prasklo a ten vědec co to měl na starosti byl zavražděn. Mělo to být k použití vystřelení špionážní družice o váze několika desítek kg - mělo to být levnější než rakety na tekuté palivo. Zatím rekord výstřelu do výšky udělal tento vědec před mnoha lety a je to 180km kolmo nahoru, několika kilového projektilu. Každopádně velmi zajímavé. Z důvodu počátečního zrychlení to asi nebude nikdy pro lidi :-)
Re Ladik: Zase jeden zarytý AMDčkář (ale asi málo "zarytý", když ještě může psát). Nevím, co je zase tak moc skvělého na spojení dvou jáder v jedno. Vždyť dvě jádra vznikla proto, aby každé zpracovávalo jinou úlohu. A minimálně pro mě je toto důvod, proč půjdu do dvoujádrového procesoru.
Hele: jak to jedno jadro pozna, ze ta uloha je pro nej a ta dalsi uz je pro druhe jadro? A vubec jak si to vlastne rozdelej, kdyz na PC bezi dohromady napr 20 programu? To si jako zahrajou "kamen,papir,nuzky"?
To řeší OS.
Tato diskuze je nyní společná i pro článek Reverse HT u AMD neexistuje?.
2 Hele & Ladik: asi jste si spletli pokoj ?
Tiez si myslim, ze nieco take nebude tak skoro. Ziadne dokumenty (NDA verzie) tuto technologiu neuvadzaju - teda RevF ani RevG.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.