Mac a 4 Intel CPU

HT je fakt "skvela" vec, jedine rozumne nastaveni HT jej jej vypnout, protoze prenasi rezii SMP za dvou virt CPU na fizicky jeden, takze pri I/O operacich je 2x tak vytezovan rezii SMP, u sdilenych knihoven zere 2x rak RAM .... fakt skvela feature.

Pisatel clanku je asy hezky amater.

V praxi bude HT asi do budoucna opravdu k nicemu, protoze dvoujadrove procesory zastanou totez lepe (navic u dvoujadrovych procesoru prinasi maximalne ztratu vykonu).

a kvuli dvoujadrovemu procesoru nemuseli k intelu...

Zaujimava skusenost. Ja som zase nejaky cas pracoval na P4 Celerone 2.4GHz s HT, a ked bol stroj niecim zatazeny (napr. kompilaciou jadra), tak ledva slo pracovat -este aj mys sa prekreslovala pomaly. Moj stary Duron 1100 na KT133A chipsete nemal ani pri omnoho vacsej zatazi take problemy, ako som narazil na spominanom HT Celerone, a este aj kompiluje porovnatelnou rychlostou (!). Distribucia rovnaka (vtedy Debian Woody), pamat rovnako, IDE disky.. Neviem, ci HT zohralo v tomto pripade nejaku ulohu (kladnu alebo zapornu), fakt je, ze toho stroja som sa zbavil hned ako to slo.

Suhlasim, ze problematiku HT by chcelo sirsie rozviest, ale asi je to uz mrtva tema, pretoze skutocne dvojjadrovy procesor alebo dualna zostava je nepochybne lepsou volbou. Myslim, ze HT skonci na smetisku dejin ako marketingovy pojem.

a kde ze se takovy Celerony s HT prodavaj?

mno jestli spravce procesu mluvil pravdu, pak neslo pri zaplem HT prinutit proces pracovat na co nejvetsi vykon - proste byl zatizen jen "jeden" procesor a "druhy" jel na prazdno ... nikdy se mi nechtelo davat si tu praci rozjet stejny task se zapnutym a vypnutym HT abych porovnal dobu trvani (doma intel nemam a jinde jsem na to nemel cas) ... pokud chci jet nejaky CPU-zerouci proces tak mu dam 'idle' prioritu a vesele u toho muzu delat neco jineho ...

HT pomuze a uskodi jak kdy. Pri ulohach, ktere nedelaji mnoho
syscallu do kernelu a bezi nezavisle na sobe HT pomuze
(kompilace s HT se zrychli asi o 15%, kdysi jsem to meril).
Pri ulohach, ktere porad delaji nejake operace v kernelu,
HT zase naopak hodne uskodi (na FreeBSD 4 to bylo asi o 1/3
pomalejsi, jinde jsem to nezkousel) --- protoze se v tom
kernelu musi zamykat a instrukce zamku trva v nejlepsim
pripade 120 cyklu...

Na SMP nebo Dual core procesorech se zamky v kernelu musi
stejne delat at tam je HT nebo neni, ale HT muze uskodit,
pokud nemate scheduler podporujici HT --- muze se pak totiz
stat, ze dva procesy pusti paralelne na jednom fyzickem
procesoru a celkove to bezi 2x pomaleji nez kdyby bylo HT
vypnuto a oba procesy se pustily na jinych fyzickych
procesorech.

nevim proc ale mam blby pocit ze ibm 970 = g5 procesor je vyrobne levnejsi nez intel a je i ve dvoujadrovych variantach.....

Jsem hodně zvědav, co bude dál, především s čím Intel přijde, protože P4 není nijak valný procesor, předpokládám, že Apple vidí víc do laboratoří Intelu, že se k tomuto kroku rozhodl. O cenách to moc nebude, protože na výrobě počítačů má Apple slušnou marži, kdyby chtěl snížit ceny, tak mu v tom nic nebrání (kromě nižších dividend pro akcionáře). Na prvním místě asi bude spolehlivost dodavatele, protože jak Motorola (dnes Freescale), tak IBM nestačili vyvíjet a vyrábět tak rychle, jak si Apple přál.

Pokud se nepletu, pristi generace procesoru Intel (dvou- a vicejaderne) nema byt evoluci jader P4/Netburst (Northwood, Prescot...), ale evoluci jader Pentium M (tj. pribuzny Baniasu a Dothanu), tj. potomkem Pentia III. Potazmo, nevim jaky je aktualni stav, ale sveho casu se tvrdilo, ze dedictvi P-III znemoznuje na techto planovanych procesorech HT. Alespon soucasne Dothany HT nepodporuji. Mozna to neni ani tak "designovou zabrzdenosti, zpatecnictvim nebo nesystematicnosti" P-III, jako spis tim, ze P-III a Pentium M maji kratsi instrukcni pipeline nez P4 (mensi pocet stages), takze se u nich HT _nevyplati_. Dalsim dusledkem kratsi pipeline je mene bolestiva branch misprediction, potazmo vyssi realny pocet instrukci/takt v mnoha typech aplikaci (v aplikacich, ktere spise provadeji slozita vetveni, nez aby ve smycce chroupaly data).
Puvodne planovana dalsi evoluce architektury P4 byla zastavena - nedarilo se planovanym tempem zvysovat takt jadra, takze Pentium M i pri nizsim taktu vazne slapalo P4kam na paty. (tusimze se to tykalo projektu Tejas)

Takze momentalni Pentium-D je IMO dual-core P4 (Netburst) s podporou HT, cili mate v jednom pouzdre 4 logicke CPU. Pristi generace dvoujadernych intelu bude mit jenom 2 logicke CPU, a nebude to P4 Netburst. A tusimze se pripravuje Xeon se 4 nebo 5 jadry odvozenymi od Pentia M.

Prominte, ze necituji zdroje - vyse uvedene si zhruba pamatuju z nekolika clanku na TheRegistru z letosniho prvniho pololeti. Vybavuju si podtitulky jako "Ukradli nam Mooruv zakon, kdo si s nim hral naposledy?".

"...we have decided to release 2 screenshots sent to us by an anonymous source...", bylo nebylo, stahl si Franta woprsalek Gimpa a zkusil co to umi :)))

Nekde jsem cetl, ze u intelovske verze multiprocesorovych stroju je obrovsky problem pri IO operacich to, ze vsechny probihaji pres jeden bridge. Tzn. pamet , PCI i CPU mezi sebou pres jeden kanal. Diky tomu vykon na jeden procesor pri rustu poctu procesoru vyrazne KLESA. Pry. Vi o tom nekdo vice?

Zkušenosti mám jen empirické

1) Na WXP máme ještě DOS úlohu, v jakémsi RDBMS Dataflex, který WXP neumí přerušit i když se třeba čeká na klávesu (někde v Dataflexu se cyklí dokola). Pokud se pustí, WXP to nechutně zpomalí (i vykreslování oken atd.) Když jsme tam normální Celeron vyměnili za Celeron D s HT, problém byl vyřešen (to té doby, než kolegu napadlo pustit si dvě instance :)).

2) Mám dva systémy s intel duál CPU server deskou intel (SE7520BD2) v tom Xeon 3.0GHz/800, 1MB Cache, v jednom 2x. S nějakým starým jádrem 2.6.6asi s podporou SMP byl výkon DOST slabý (bežná činost), slabší než s defaultním jádrem z debiana. S 2.6.12 s podporou SMP+HT výkon hodně narostl, tak jsem to tak nechal.

Nijak jsem to neměřil, ani nezkoumal, jsou to opravdu spíše dojmy

Ano, vykon na jeden procesor v SMP systemech obecne klesa, protoze celkovy vykon se s pridavanim poctu procesoru zvysuje mene nez primo umerne. Jak spravne rikate, je to zpusobeno sdilenim kapacity sbernic (FSB, PCI, RAM) pres spolecny PCI host bridge a spolecny radic pameti, a taky nutnosti udrzovat koherenci on-chip cachi navzajem mezi procesory. Plus k tomu pristupuje obecna problematika paralelizace vypocetnich uloh.

Pokud se nepletu, od tohoto intelskeho modelu se ve svete PC odchylila pouze firma AMD, ktera ma pametovy radic integrovany v procesoru. Takze SMP system od AMD se chova trochu jako NUMA. Ale osobne si vubec nejsem jist, jestli si toho je vedomo napriklad Linuxove nebo wokenni jadro, a jestli podle toho mapuje lokalnim procesum lokalni stranky fyzicke RAM, nebo jestli to vsecko chroupe jednotnymi schedulery a strankovanim, ktere jsou kompatibilni s "Intel MPS Spec" a na zvlastnosti architektury AMD neberou ohled.

Pokud bychom uvazovali o zavedeni nekolika paralelnich PCI host bridgu do SMP systemu, nevim, jak by takovy system vypadal, a zda by se takova vec dala implantovat do monoisticke PC architektury. Spis bych laickyma ocima videl moznost pouzit v north bridgi nejakou neblokujici matici (M segmentu FSB x N segmentu PCI x O segmentu RAM). Zkuste se mrknout do datasheetu Intelskeho cipsetu 8500...

V podstate tak nejak jsem si to predstavoval. Ta informace byla, tusim, z toms' hardware. Testovali tam vykon multiprocesorovych stanic Intel vs. AMD a podle vysledku toho testu (tusim ze na Suse Linuxu) to vypada, ze linuxovy scheduler je na AMD optimalizovany. Z toho, pomerne hrubeho, vysvetleni tam vyplynulo to co pisete vyse o Intelu a co se tyka AMD tam to spise pripominalo usporadani do matice, kdy procesory komunikovaly primo s pameti a i naprimo navzajem sami se sebou. Pres jejich specifickou sbernici HyperTransport. Tenhle clanek byl impuls k tomu abychom pozdeji poridili server na AMD Opteron, ktery ted bez vetsich problemu provozujeme. Pisu "bez vetsich" protoze nejake drobnejsi se objevily s PHP.