Předpokládal jsem, že se bavíme o SMP architektuře, nikoliv o NUMA. V SMP je vše sdílené, proto také výkon neroste lineárně s počtem procesorů. Dost narůstá režie.
Ale z hlediska OS je opravdu fuk, kolik je tam jader a jak uspořádaných. Pokud není, je to umělé omezení. Nesnaž se to nijak okecávat. Navenek je vztah mezi jádry na jednom křemíku naprosto stejný, jako mezi těmi spojenými venkem přes čipovou sadu. Předpokládám také, že se nebavíme o DOSu.
To, že jeden fyzický procesor s více jádry je lepší, než stejný počet jader ve více "paticích" pravda je. Ale není nijak extra pravda, že by to byl až tak výrazný rozdíl. Zvlášť od doby, co se opustila FSB. Ono také PC je od toho, aby počítalo, ne aby přesouvalo pakety sem tam po sběrnicích ... Pokud jsou data v cache jednoho procesoru a potřebuje s nimi pracovat ten druhý, je z toho poměrně logická výkonnostní penalizace. Ovšem ani u vícejádrových procesorů není/nebývala jedna cache pro všechny, podle toho jaký slepenec to ve skutečnosti byl.
Proto je také pro naše (síťové) potřeby lepší menší počet jader, ale raději vyšší frekvence. Kdyby ale tohle dokázal řešit OS (optimální obsluhu procesorů), jak si myslíš, tak není potřeba např. u síťových karet vymýšlet takové věci, jako vícenásobné rx-queues - kdy sám HW karty doručuje pakety stále na stejné jádro dle konexe (dle nějakého hashe) a tím zajistí právě konzistenci cache, nejsou pak nutné jakékoliv přesuny, jednu konexi řeší stále stejný proces/thread. Ale je pravděpodobné, že takový paket odchází po odroutování jinou síťovkou, tedy vysoce pravděpodobně i jiným jádrem :-)
Šoupání dat se vlastně nevyhneš vlastně ani u nových CPU - L1 i L2 cache má každé jádro svou, společná je pouze L3, která je ovšem znatelně pomalejší ... Je ale také pravdou, že technologie u Intel Nehalem architektury to trochu řeší - co je v L1+L2 je zároveň i v L3, takže mají všechny jádra shodný přístup i k datům těch ostatních. A u víceprocesorových systémů (fyzických) má každá CPU vlastní nesdílený spoj na ostatní (přes QPI). Takže penalizace tam sice je, ale rozhodně ne tak hrozná jako v dobách P4. Viz http://www.pcper.com/reviews/Processors ... terface-an
Nebudu daleko od pravdy, když řeknu, že žádný OS neřeší rozhazování procesů a threadů na jádra podle toho, kde se to jádro fyzicky vyskytuje (lze to ovšem řešit ručním zásahem). Jeho prací je vytěžovat to rovnoměrně. Proto jsou také případy, kdy HT přinese pokles výkonu - prostě se to snaží používat jako skutečné jádro, ale už neví o tom, že to není celé jádro a spoustu věcí (především výpočetních) sdílí s ostatními - a ty pak musí vlastně čekat. Zářný příklad byl pokus ve windows, kde se pustil jeden proces třeba SETI. Myslely si, že mají 50% volného výkonu, byl to jenom jeden proces ... jenže s kompem se nedalo pracovat, to jádro prostě přestalo být použitelné (mluvím o jednojádru s HT). Podobně jsem na tom byl s MS SQL 2000. A u routovací mašiny je dle mě vhodné HT vypnout stoprocentně. Byť u nových systémů už to prý tak hrozné není, ale už jsem to netestoval a moc mi nejde na rozum, jak by dokázal práci s HT optimalizovat.
U MK bude také pravda, že používají nějaké starší jádro. A tam bývalo v defaultu nastavená kompilace pro málo jader (nějakou paměť to šetřilo). U kernelu 2.6.24 to bylo jen 4 (alespoň u archlinuxu), takže v podstatě mělo smysl jen dvoujádro s HT, víc bylo zbytečné (pokud sis to nepřekompiloval sám, nebo to neudělal distributor za tebe). Blbé je, že tuhle informaci mikrotik nedává ... A je to také důvod, proč na tvrdší nasazení NENÍ mikrotik vhodný - prostě do toho není vidět a dokumentace stojí za prd (o supportu ani nemluvě). S čistým linuxem je podstatně lepší šance, že je HW využitý dobře a že si nenaběhneš. Jo, je to větší dřina. Máš ovšem možnost vadný či nevyhovující kousek software vyměnit ... příkladem je např. routing - quagga. A třeba PCQ queues mi tam dost chybí (i když existuje projekt něčeho podobného, ale nevím v jakém je to stadiu). Jednoduchost obnovy MK (resp konfigurace) po nějaké poruše má také něco do sebe.
Vy se tu všichni a všude bavíte o "vysokorychlostním routeru" a přitom je řeč o tocích v řádu pár set megabit maximálně (200+). To jsem dělal na obyčejné P4 2.4GHz s neoptimalizovaným QOS a NAT. U těchto rychlostí je tedy vlastně fuk, jaký HW se pořídí (pokud to není RB).
Ale zkuste si mikrotikem vyřešit toky pro 2500 uživatelů, 700Mbit ve špičkách - na jedné mašině, co dělá NAT i QOS (co uživatel, to třída) zároveň. S vytížením prakticky zanedbatelným ... stačí linux, Xeon X3470 a síťové karty od intelu (s podporou MSI-X). Věříte tomu, že s MK to nepůjde? A to netvrdím, že jsme nějak přehnaně velká síť ... naopak.
Jo, co by mě zajímalo je, jak se dostat na rychlosti tak 2Gbit a výše ... ale takové informace se už hledají blbě a ještě hůř se to testuje.
