ad J) nesmis si plest plnohodnotny SMP a HT. Pri pouziti SMP s HT CPU muze dojit k poklesu vykonu, ovsem ne v OS (tam je pokles vykonu v souvislosti s narustem rezie naprosto minimalni, pokud vubec nejaky), ale v aplikacich, ktere jsou bud singlethreadove a nedokazi vyuzit vice exekucnich jednotek (CPU jader), pak se samozrejme zadny narust vykonu ani nemuze konat, a nebo naopak pri HT mohou dokonce snizovat vykonnost zbytecnym multithreadingem, kdy se dva procesy v CPU navzajem blokuji, protoze se snazi vyuzivat stejne CPU zdroje (ALU, atp.).
K tematu clanku, bych si dovolil polemizovat ohledne rychlosti FSB. Snad se prilis nemylim, ale domnivam se, ze v naproste vetsine dnesnich multi-cpu boardu je FSB sdilena pro minimalne dva, spise az ctyri CPU. Dnesni Xeony MP disponuji FSB o taktu max. 667MHz, takze planovanych 1066MHz je vyraznym zlepsenim ! Navic diky integraci vice jader do jedineho cipu, by v pripade spolecne pameti cache mohlo dojit k vyssi efektivite prace s RAM (odpadne zatezovani FSB inter-cpu komunikaci a slozita synchronizace jednotlivych radicu cache v jednotlivych CPU a koordinace prace s radicem RAM v NorthBridgi)) a ke snizeni celkovych latenci pristupu do RAM, takze se celkovy vykon temer urcite rapidne zvedne ! I v pripade pouheho vicecipoveho CPU v jednom pouzdre bude vyhodou alespon zjednoduseni navrhu MB a tudiz jeho pripadne zlevneni (zejmena pro 4-way reseni je kvalitni MB skutecne velmi draha zalezitost !).

RaStr: Komunikovat mimo fsb a ještě k tomu na frekvenci CPU umí zatím jenom AMD. Intel to plánuje, ale bůhví na kdy. U dvou 4 jádrových CPU už to může být pěkně cítit.

J: prozatím jsem si nevšiml rozdílu v testech rychlosti AMD a Intelu, snad jen toho rozdílu ceny. Je taky zajímavý posun ve výkonu, u jednojádrových procesorů vedlo AMD, je záhadou proč dle tebe blbě navržený Intel dává tytéž výsledky na 2,8 GHz jako AMD 3800 což je myslím třítisícovka. Prozatím jsem nepochopil podle jakých kritérií spousta rádoby odborníků poukazuje na výhody či nevýhody toho či onoho řešení, když ještě není jasné zda tyto rozdíly bude možné využít a jaký budou mít přínos. Jde opět o oblbování lidí jako u 64 bit procesorů, které jsou už cca 2 roky, ale na aplikace si ještě nějaký čas budeme muset počkat ? Kde je z počátku slibovaný dvojnásobný výkon který tak rádi zdůrazňovali prodejci ? Uživatelé AMD nejsou schopni uznat výhodu hypertheardingu a objevila se řada článků o tom proč to nemůže fungovat, ale já tuhle technologii využívám  víc než rok a jsem spokojený. Nevyvracím, že může způsobit i problémy, ale ještě jsem na ně nenarazil. Podotýkám že jsem obyč uživatel

J + XXL: 64 bit jsou dvě věci:
64 bit adresy - umožňoje v rámci procesu adresovat více než 2GB paměti - to dnes využije zlomek aplikací, pro ostatní to znamená zpomalení.
64 bitové celočíselné registry a operace nad nimi - to taky využije poměrně málo specifických aplikací, ale u nich je nárůst výkonu znát. Dnes se spíš výpočty přesovají na SSE a to je 128 bitové u všech procesorů.
Hlavním přínosem X86-64 tak je dvojnásobný počet registrů.

Co se HT týče, tak jeho hlavní nevýhodou je množství spotřebovaných tranzistorů, který by se daly využít efektivněji (více jader, vektorová jednotka). Ovšem vzhledem k cenové politice AMD, která dnes chce za méně tranzistorů stejné peníze jako Intel to není nevýhoda pro zákazníka (až na to teplo z těch tranzistorů :) )

Zajímalo by mě, u kolika jader se začnou odstraňovat části, které ztačí v jednom jádře (např. podpora reálného módu). Pěkně to vyřešili u Cellu, kde je jedno speciální jádro, na kterým běží OS a ostatní jsou ořezená na skutečně používané jednotky.

J: Komunikace jader u INTELA rozhodne nemusi byt zase az tak rychla. Narozdil od AMD, CPU neridi primo RAM, takze pokud jedno jadro potrebuje pristupovat kamkoliv do RAM, nikdy k tomu neni potreba projit pres druhe jadro, tak jako u AMD. Je tedy logicke, ze AMD proste muselo pridal dalsi sbernici pro inter-cpu komunikaci, pokud chtelo vytvorit SMP system, ktery nebude brzden prave FSB (ci jak tomu u AMD vlastne rikat). Oproti tomu INTEL FSB je pro komunikaci s RAM i s PCI rychla dost a vzajemna komunikaci mezi CPU probiha pouze ve chvili, kdy jeden CPU pristupuje do pametoveho prostoru uzivaneho zaroven i jinym CPU, to se ovsem nestava zase az tak casto. Pochopitelne resenim je namisto rychle interni FSB jednoduse sdilena CACHE a to v planech INTELU urcite je! Samozrejme, ze SMP architektura typu bus, v soucasnosti uzivana u SMP INTELU je horsi nez architektura hvezda, ovsem zase je jednodussi na implementaci a tudiz i levnejsi. Takze kazde ma sve pro i proti a co je skutecne lepsi ukaze az praxe !
Co se tyce 64-bit, ano jiste, je to naprosto v pohode, pokud pouzivate takovy mainstreamovy OS jako Gentoo, atp. a vasi hlavni pracovni naplni je vypocet PI, nebo neco takoveho obdobneho !
Co se tyce HT, nehodlam je ani hajit, ani hanit. Me proste funguje a vyhovuje, nekomu mozna ne, kazdopadne neni pravda, ze kazdy vykonnostne narocny program bude pri HT jen ztracet, naprosto bezne muze napr. paralelne bezet proces vyuzivajici SSE jednotky + druhy pracujici jen s beznou integer aritmetikou (napr. komunikace s radicem disku). Takze napr. pri zpracovani (kompresi audia, resp. videa) bude jeden thread makat na 100% na kompresi a druhy bude s prehledem vyuzivat jinak nepouzitych jednotek CPU pro zajisteni nacitani/ukladani dat a OS ulohy (rizeni procesu, obsluha GUI, atd.). Narozdil od ne HT reseni sice nedojde k narustu vykonu, protoze samotna komprese dat se nezrychli, ovsem dojde k zrychleni celeho OS jako takoveho, kazda reakce uzivate bude hned obslouzena "volnym" druhym CPU a nebude vubec postizena 100%-ni zatezi na prvnim CPU, takze celkove bude OS "zivejsi", tj. snizi se latence. A to je treba pro mne daleko dulezitejsi, nez jestli v super-PI budu mit o par desetinych mist vice, ci mene !