ludvik píše:Latencemi myslíš co? To jsi někde vyčetl? Ty jádra mají mesh architekturu. Neexistuje pojem první a poslední v řadě. Jediný, co by ti mohlo vadit je údaj "1 cycle per hop". Jakou latenci má intel při přístupu do L3 cache?
Porovnávat dvě dost odlišné architektury (atom - tilera) rozdílného zaměření je poměrně dost ošidné. Zavrhnout jednu jenom proto, že má nízkou frekvenci a nemá FPU, to je docela tvrdé. Nemluvě o tom, že FPU se dost přeceňuje. Pokud potřebuješ šoupat bajty sem tam, tak nevím, proč bych potřeboval násobičku a děličku v reálných číslech.
Naopak je tady obrovská výhoda integrace síťových věcí, dokonce včetně jakési podpory shapingu.
Pokud je něco multicore, musíš mít software který to umí využít. Budeš-li porovnávat výkon prográmkem superpi, nic nezjistíš.
co myslim latencemi? ty jádra jsou v mřížce. Jedno komunikuje přes druhý nebo spíš přes switchovanou zběrnici. Pokud chce prostřední jádro komunikovat s ramkou, musí skrz několik switchů než se tam dostane. Jedno to sice má k ramce blízko ale jiný na druhá straně mřížky to má hrozně daleko ale má to blíž k ethernetu
a naopak. Každej ten switch má 1 cykl zpoždění. To neni zpoždění L3 cache ale samotný zběrnice a k tomu se ještě počítá latence L3. Jo ok, je to prd nicméně přes to teče uplně vše protože jiný zběrnice ty jádra nemají.
jo hele, FPU je důležitá, vždycky byla. U RB333 byla jako externí část procesoru nebo co protože to důležitý je. Bohužel běžela na pomalejšim taktu než ALU část procesoru. RB333 byl propadák. V dnešní době se i defakto APU instrukce počítaji v FPU části protože je natolik složitá, že jich zvládne za takt víc než samotná ALU.
Prediktivní jednotka je to co vyzvyhuje intela a jeho core2 architekturu případně sandy bridge atd.. mimo jiná vylepšení. Ona předpokládá co se bude dít a načítá si předem data z ramky a podobně. Všimni si že při nástupu code2duo intel výrazně máknul na prediktivní jednotce. Tuším že byla vymakaná takovym způsobem že dokázala předpokládat a připravovat data o pěknou řádku instrukcí dopředu takže výpočetní jednotky nečekaly na nic. Tušim dokoce že 4x víc než tehdy konkurenční amd a proto je tak masivně rozdrtily. Jasně, vylepšený APU, FPU atd. kolem taky byly to je jasný. No ale tady neni nic takže se na všechno bude čekat.
Ano, šoupat bitama je ok, ale co shaping? hmm?
jo a mimochodem, tyhle sítový věci maji i RB1xxx a nikdy kromě chybný implementace šifrování mikrotik nepoužil. Nakonec to šifrování musely vypnout a nevim jestli ho někdy rozchodily ale dělávalo to bordel.
No schválně, spoj si tisíc procesorů 486 a uvidíme jak na tom budeš s výkonem. Myslim že tě dnešní xeony rozdrtí na polovičním taktu
in-order byla vždycky chyba viz atom. dnešní mipsi v rbčkách máš out-of-order což je podstaně výkonově lepší.
Jo ano, když budu počítat nějaký poligony, vemu si multicore ale ne miliony core kde každý je o výkonu kalkulačky. Některý operace se multicorově dělit nedaji a na tomhle to vyhnije. Jo ten procesor je pro hostingový cloudy kdy člověk po tom chce poslat nějakej soubor, obrázek nebo tak, tak tam chápu že malej výkon per core stačí kde se webserver dokáže posadit na jednotlivá core a obsluhovat víc klientů na jednou. Ale rozdělovat práci pro zpracování paketů mezi 36 slabích jader kde jenom na to rozdělení bude potřeba využít tak 5 jader, nějaký zpracování shapingu který určitě nebude tak efektivní jak by jsme si přáli a jakmile dojde k přetížení jednoho z těch jader, celí to pude k zemi tak jak se to děje teď.
Já říkám že to je špatná cesta ale nechme se překvapit. Určení toho procesoru je jiný než použít ho do routeru i když sítový operace by měl zvládat výborně. Nicméně neni navržen na to aby shapoval tisíc lidí na 500Mbit. Toho chce MKčko docílit silou ale nějak nevim kde jí chtěji vzít když zpracování paketu pro naše účeli je více méně seriová záležitost a jestli si myslíte že tam bude 36 jader a každý o výkonu jednoho jádra xeonu, tak budete asi sklamáni.
