Sun geeft Niagara 16 cores met ieder 16 threads

De opvolger van Suns Niagara 2-processor, de Niagara 3, wordt eind volgend jaar leverbaar en zal zestien cores aan boord hebben. Elke kern kan zestien threads tegelijk uitvoeren, zodat een processor 256 threads simultaan kan verwerken.

Website The Register meldt dat het ontwerp van de Niagara 3 over ongeveer zes maanden afgerond is en dan naar productiefabrieken gestuurd wordt. Als deze zogeheten tape-out goed verloopt, zal de nieuwe Ultrasparc-chip eind 2009 beschikbaar zijn. In eerste instantie komen processors beschikbaar die gebruikt kunnen worden in systemen met twee sockets.

Sun werkt ook aan systemen die plaats bieden aan vier sockets. Volgens El Reg hebben die systemen de codenaam 'Botaka' gekregen. The Register weet ook te melden dat Sun ook nog een systeem met acht sockets op de planning heeft staan, maar meer informatie daarover ontbreekt vooralsnog. Als een dergelijk systeem met acht Niagara 3-processors wordt uitgerust, kan het maar liefst 2048 processen tegelijkertijd verwerken.

De Niagara 3 heeft bijna dezelfde specificaties als de Rock-processor. Beide cpu's hebben zestien kernen aan boord, maar de Rock kan 'maar' vier threads per core aan. De laatstgenoemde processor is bedoeld voor gebruik in highperformancecomputing, terwijl de Niagara 3 wordt ontwikkeld voor gebruik in webservers.

Reacties (53)

[Rob Coops]

2048 threads dat wordt een flinke hoeveelheid concurent requests op een webserver. Ik vraag me alleen af hoe ze het probleem van IO gaan oplossen als ik namelijk 2048 threads een web applicatie laat draaien dan zal mijn arme schijf systeem dat toch echt niet bijhouden. Ook flash disks zullen hier een bottleneck zijn.

Met andere woorden ik kan niet wachten tot dit systeem beschikbaar is dan kunnen we eindelijk eens uitgaan kijken naar "Niagara 3 ready" disks die niet alleen een lage seek time hebben en een hoge read/write snelheid maar die daar naast ook instaad zijn om meerdere data streams tegelijk te kunnen lezen/schrijven. Dat zou best moeten kunnen met een goede interface en een solid state disk.

[Fiander]

Van de 16 threads die elke core af kan handelen, is er uiterraard telkens maar één echt actief. Er zit in elke core logica welke de registers van 16 threads snel kan opslaan, en de volgende set laden. Hierdoor kan er telkens waneer een thread op IO moet wachten ( Disk, netwerk, oid ), snel gesprongen worden naar een thread die wel de core nuttig gebruikt.

thread 1 vraagt aan het disk systeem om wat data op te halen, thread 2 doet daarna php dingen, thread 1 krijgt seintje dat IO klaar is, en gaat verder als het weer zijn beurt is.

natuurlijk kan dit ook al in x86 / x64 processoren, echter worden daar de registers in het cache opgeslagen ipv in een speciaal segment. hierdoor is het een stuk kostbaarder. Het stelt ansich niet zo veel voor, echter is een x64 core zo groot dat het teveel extra datapaden in de core, en te veel transistors zou kosten om het sneller te maken dan dat het zoals nu via de cache gaat.

[Jaco69]

Als 1 thread wil optellen en een ander thread wil vermenigvuldigen en deze twee acties gebruiken verschillende hardware... Kunnen de threads dan wel tegelijk een actie doen?

[Fiander]

que ?
snap niet helemaal wat je bedoelt ?

In jou vraag heb je twee threads welke alle twee andere hardware gebruiken ?
waarom zou de een dan niet kunnen optellen terwijl de ander vermenigvuldigt ?

[loodgieter]

Mocht dit inderdaad dusdanig veel I/O van je Disk (storage units) vragen dan kan er altijd nog gekeken worden naar een RAMSAN van Texas Memory.

Tera-RamSan

Tot 24GB/sec data bandbreedte.

@ Fainder

thread 1 vraagt aan het disk systeem om wat data op te halen, thread 2 doet daarna php dingen, thread 1 krijgt seintje dat IO klaar is, en gaat verder als het weer zijn beurt is.

Ga er wel vanuit dat dit met een gigantisch snelheid gaat en die 16 hreads misschien wel afgeleverd worden maar er net zo snel 1024 andere klaar staan om ook afgeleverd te worden (bij wijze van). Dus snelheid is zeker wel van belang op de "achter kant" zoals HDD`s.

[SKiLLa]

Daar hebben we allang SANs voor ... Kom je dan nog performance/IOps tekort, dan moet je simpelweg upscalen (betere performance per unit, denk aan meer HDDs) en/of outscalen (meer units, denk aan 2e IO controller, etc.) ...

[Verwijderd]

Waarom zou je dit willen als webserver?

Een webfarm is dan toch beter
-geen single point of failure
-goedkoper (meedere goedkopere servers)

ik zie dus geen voordelen!

[SKiLLa]

Nou als je een heel 42" rack aan webservers kunt vervangen door 2 of 3 van die machines, dan bespaart dat je aardig wat ruimte en stroom (en dus potentieel veel kosten). En wat als je DC "vol zit", dan zal je wel moeten, een "uitbouw" gaat niet zo makkelijk in de meeste DCs.

Natuurlijk zijn ze bij de introductie duur en mogelijk financieel niet direct aantrekkelijk, maar dat geldt voor bijna alle produkt-introducties. En ja, een single-point of failure kan meer impact hebben (maar wie zegt dat de hele CPU meteen stuk is, misschien is het maar 1 core, houdt je er 15 van de 16 over).

PS: Of vind je moderne dual-cores/quad-cores ook "slechter" dan 2 of 4 oude single-core bakken ? Een quad-core bak onderhouden is immers "goedkoper" dan 4 losse bakken ....
En zo is een Niagra ook niet "absoluut de beste oplossing in elke situatie", maar in veel gevallen heeft het weldegelijk voordelen ...

[Reactie gewijzigd door SKiLLa op 23 juli 2024 13:34]

[Little Penguin]

Volgens mij is er wel minder energieverbruik, dus je kunt meer gebruikers (klanten) bedienen met eenzelfde hoeveelheid verbruikte elektriciteit.

Aangezien de kans erg klein is dat energie goedkoper wordt (eerder het tegendeel) kan de inverstering in 1 of 2 van dit soort systemen zich heel snel terug verdienen...

[i-chat]

daarnaast gaat ie voorbij aan het feit dat er toch wel farm worden g0ebouwd,

het verschil zit hem echter in of je nu 2 racks of 20racks moet huren...

de prijzen van ruimte, energie, koeling, en aantal te onderhouden systemen gelden daarbij zeker. want houd in je eentje maar eens 20 racks aan servers bij .. ovendien zal ook je netwerk goedkoper worden, denk maar eens aan routering, etc. (hang je liever 10 pc's aan een switch of liever 1 ultrasparc3 aan je rootswitch

[Smuggler]

als ik dit nu allemaal zo lees, zal er binnenkort geadverteerd worden met het aantal cores/threads ipv, het aantal Ghz waar ze lange tijd mee geadverteerd hebben.
een intressante ontwikkeling ook voor ons als eindgebruiker. zijn er trouwens al veel programma's die een "oneindige" hoeveelheid cores ondersteunen?

[silentsnake]

Apache. Die maakt gewoon een aparte worker process aan voor elke connectie. Dit kan door een aparte thread uitgevoerd worden, dus zolang Apache schaalt met grote hoeveelheden worker processes zal hij "oneindig" hoeveelheid threads ondersteunen.

Zo een systeem is geweldig voor webservers die heel veel connecties voor hun mik krijgen. De UltraSPARC T2 is gemaakt echt gemaakt webservers als we SPECweb geloven, daar veegt ie echt de vloer aan met elk ander hardware platform. Maar uiteraard kan ie genoeg andere dingen ook doen

[Snake]

Dat snap ik dus niet, waarom er nog geen x86-64 chips zijn die simultaan meerdere threads / core kunnen afhandelen.

[Verwijderd]

Ummm die komen er aan? Nehalem krijgt ze(4 cores 8 threads). En sja... P4 met HT(1 core 2 threads) was er al...

@hier onder, dat vraag ie ook niet.... simultaan meerdere threads / core houd ook gewoon 2 threads de core in.

@Dasiro:
Ummm, Dacht je van de P4 630 tot 670? HT en Intel 64?
http://www.intel.com/prod...number/chart/pentium4.htm

[Reactie gewijzigd door Verwijderd op 23 juli 2024 13:34]

[dasiro]

P4 was geen x86-64 chip, maar een x86-32

[knirfie244]

Er was ook weldegelijk een 64bit Pentium 4, volgens mij de 600 serie.

@Snake - Sparc is een hele andere architectuur dan x86, een RISC kern is veel kleiner, en daardoor kunnen er makkelijker meerdere op één die gezet worden, ook is een enkele core om deze reden makkelijker uit te breiden om meerdere threads te kunnen draaien.

De Niagara 2 met 8 cores en 8 threads per core telt maar 500 miljoen transistors, dat is nog geen 100 miljoen meer als een Core2Duo.

Daarnaast, wat voor nut zou het hebben als een desktop zoveel threads aan zou kunnen? Fatsoenlijke multithreaded software is er toch nog niet (buiten enkele spefieke toepassingen dan)...

[Reactie gewijzigd door knirfie244 op 23 juli 2024 13:34]

[justice strike]

alle x86 tegenwoordig zijn intern gewoon risc. de cisc gedeeltes worden gewoon ergens vertaald naar risc commando's waarna ze door een risc core uitgevoerd kunnen worden.

[knirfie244]

Met al die SIMD extensies kan je de huidige processors echt geen RISC noemen. Het is waar dat (vooral de eerste P4's) er verschillende gedachtengangen uit de RISC architectuur (overgesprongen zijn naar x86 processors (zoals de micro-ops). Maar dat maakt het absoluut nog geen RISC core.

Het grootste probleem is dat huidige CISC's veel ideeën achter RISC gebruiken, en dat er geen goede definitie is voor RISC, behalve waar het een afkorting van is: Reduced Instruction Set Computer. Hierdoor is vervaagt de grens tussen CISC en RISC een beetje. Daarom zie je afentoe ook de naam Load-Store architecture voorbij komen, wat een veel betere omschrijving is voor het gros van de "RISC" architecturen.

Het schijnt trouwens naar geruchten wel dat de Pentium4 is een RISC-achtige modus kan draaien als je alleen de RISC instructieset gebruikt.

[Reactie gewijzigd door knirfie244 op 23 juli 2024 13:34]

[Verwijderd]

Mijn laatste reactie op deze thread:

De PIV is geen echte CISC processor. Nu spreek ik mezelf tegen vergeleken met wat ik beneden schreef (met een reden=>)... Er kan tegenwoordig geen heldere onderscheid gemaakt worden tussen RISC en CISC... De PIV is een met een alles erop en eraan processor... Intel heeft gewoon een zeer krachtige RISC engine dat de Pentium instructies decoded in een of meerdere RISC microinstructies, en ze dan op een hoge snelheid uitvoert. Intel heeft gewoon op een logische en wijze manier de x86 instructies geconcentreerd en geoptimaliseerd die door de 'wijd' gebruikte compilers gebruikt word. En nu komt het, er zitten er geen Opcodes REP SCAS en REP STOS instructies in bijvoorbeeld.

Link van 80368 programmer reference:
http://pdos.csail.mit.edu/6.828/2004/readings/i386/REP.htm

Het idee achter een RISC was om geen gestroomlijn chip te maken met kleinere transistoren maar meer de onnodige delen eruit te halen van de CISC microcode en de vrijgekomen plaats te gebruiken om extra transistoren in te steken om de chip rapper/sneller te maken.
Je maakt een auto ook niet rapper door de achterzetel eruit te gooien, maar wel door het eruit te gooien en er bv een ongeveer even zware supercharger als de achterzetel erin te steken...

[Verwijderd]

RISC = Reduced instruction set computer, dat is geen zo een processor met instructies zoals wij kennen, deze zijn 'reduced' zodat de processor als en alleen als de instructies uitvoert die de OS welke voor de instructies gemaakt is nodig heeft...

[Jaco69]

Hoezo niet zoals wij die kennen? Buiten the x86 is bijna alles RISC.

In CISC wordt 80% van de instructies bijna nooit gebruikt en dus is bij RISC gekozen om minder maar (krachtigere) instructies te implementeren en daardoor kleiner en sneller te zijn.

[Verwijderd]

en er wordt niet gekozen om risc of cisc processing units te gebruiken...µ
Er zijn 3 grote soorten systemen, de Servers Workstations en PC's, ik ken geen normale gebruiker die in zijn/haar pc een risc unit draait voor word processing, of gaming...
Daarintegen zijn de Xeons meer RISC te noemen (waarom 'meer' omdat zoals hierboven staat de grens sterk aan het vervagen ios tussen risc en cisc) omdat men geen Xeon nodig heeft voor een huis/tuin/keuken pc'tje, maar wel bv. in Cad modeling, in Workstations, Servers... enz enz...

[drahca]

RISC heeft niks te maken met de performance die je kan halen uit een processor. RISC is ontwikkeld als alternatief voor CISC omdat het men was opgevallen dat op bestaande CISC processoren sommige taken sneller waren bij het gerbuik van meerdere, simpele instructies, dan een complexe instructies.

RISC houdt in dat:
- Load / Store architectuur. Memory read en write zijn expliciete instructies. Alle andere instructies werken op registers
- simpele instructies (liefst geen microcode) Zo had bijv. de Alpha niet eens een fdiv instructie! Dit is belangrijk i.v.m. pipelinen van de processor.
- Fixed instrution size. In tegenstelling tot x86 die variabele instructie grootte gebruikt. Hierdoor weet je precies waar de grenzen zijn tussen instructies en dit maakt het "parsen" van de instructiestream een stuk eenvoudiger waardoor super scalar execution een stuk makkelijker te bereiken is. (super scalar is meer dan een instructie parallel tegelijk uitvoeren)

Het x86 instructieset is CISC, maar de moderne implementatie heeft veel van RISC afgekeken. Zo worden complexe x86 instructies opgezet naar u-ops die veel weghebben van RISC instructies. Hierdoor is onder andere het pipelinen van de processor een stuk eenvoudiger.

Goed de rest mag je zelf opzoeken.

[psychicist]

en er wordt niet gekozen om risc of cisc processing units te gebruiken...µ
Er zijn 3 grote soorten systemen, de Servers Workstations en PC's, ik ken geen normale gebruiker die in zijn/haar pc een risc unit draait voor word processing, of gaming...

Dan ben je waarschijnlijk niet veel Mac gebruikers tegengekomen. Tot enkele jaren geleden was de gehele Apple hardwarelijn namelijk uitgerust met PowerPC processoren (en daarvoor met Motorola 68000 CISC processoren). Ik heb er zelf nog een paar staan met OS X 10.4 en GNU/Linux erop draaiend.

Mijn familie werkt bovendien al een jaar met een MIPS desktop voor webbrowsen, e-mail en tekstverwerken en zelfs internetspellen werken erop. Uiteraard werken Windows of Linux/x86 spellen er (nog) niet op, maar dat is voor hen ook niet nodig, want die spelen ze toch niet.

[Verwijderd]

Ken jij een 'gewone' thuisgebruiker die een RISC heeft? zijn er mensen die zitten te gamen op een sparc of een sun niagara??
Kleiner en krachtiger inderdaad, rapper ook, zonder een hoop instructiesets kan de processing unit rapper (de nodige) instructies vinden, en is er veel meer plaats om extra cores bv te integreren...

[drahca]

XBOX 360: PowerPC RISC
Nintendo Wii: PowerPC RISC
PS3: PowerPC RISC

Vrijwel alle mobiele telefoons: ARM RISC
iPod: ARM RISC

zonder een hoop instructiesets kan de processing unit rapper (de nodige) instructies vinden, en is er veel meer plaats om extra cores bv te integreren...

Jij weet echt niet waar je het over hebt of wel?

[Verwijderd]

de 6xx - ... van de PIV series is met de x86-64 (EM64T) technologie... wat zeg jij nou

[sjans]

Maar geen 8 threads per core maar slechts 2 per core. En dit is totaal onvergelijkbaar met elkaar omdat de architectuur heel anders met taken omgaat.

[Reactie gewijzigd door sjans op 23 juli 2024 13:34]

[gassiepaart]

omdat dit een andere architectuur is....

[Verwijderd]

HyperThreading in de Pentium 4 was exact dat. Het probleem is echter dat de threads elkaar kunnen tegenwerken (elk de helft van de cache is soms trager dan één thread de hele cache laten gebruiken, etc). Nehalem, de nieuwe architectuur die eind dit jaar gereleased wordt, zal terug HyperThreading ondersteunen, en zou maatregelen hebben die de nadelen minimaliseren.

[Verwijderd]

hopelijk beginnen ontwikkelaars alvast programmeren voor de huidige hardware , laat ze die eerst optimaal benutten.
Het is imho beter dat je 2x2threads optimaal benut ipv 4 threads per core in een quadcore waarvan je maar 1 kern benut

[demonite]

In het geval van apache kun je met deze processor dus 256 demons tegelijk draaien.

[Jaco69]

Dat kan met elke processor.

[_Thanatos_]

Er valt niks voor te programmeren. Een multithreaded applicatie die CPU-intensief is, gebruikt zoveel threads als dat er fysieke cores aanwezig zijn. Enige verandering is dat er dus gekeken moet worden naar logische cores, mits dat snelheidswinst oplevert. Maar in theorie zit er voor multithreaded software geen verschil tussen een singlecore, een quadcore, of een hexadeca-core zoals deze.

Software die hardcoded bijvoorbeeld 2 threads gebruikt, of die een maximum van 4 heeft, die moeten herzien worden. Maar software die gemaakt is voor zware servers met 16+ logische cores, hebben deze schalingsmogelijken gewoon al.

Het is vooral multithreaded desktop software waar nu dat soort 4-core limieten in voorkomen. Denk aan CoreAVC, om maar een cpu-intensief desktop-iets te noemen te noemen.

[Reactie gewijzigd door _Thanatos_ op 23 juli 2024 13:34]

[ATS]

Nou, dat is niet helemaal waar natuurlijk. Er zijn gewoon situaties in programma's die niet goed schalen naar het inzetten van meer cores, ook al zijn ze nu al multithreaded. Je kan daarbij denken aan een centraal deel van het programma dat je worker threads stukjes werk geeft en de resultaten van je worker threads verwerkt dat bij een te groot aantal worker threads een bottleneck wordt.

[AndrewF]

Inderdaad, als programmeur is het helemaal niet zo vanzelfsprekend om applicaties "volledig" multithreaded te schrijven. Ik kan met inbeelden dat als je 2048 threads gebruikt je ook veel geheugen nodig hebt voor al die threads, en makkelijk met concurrency issues te maken krijgt..

Ik denk dat de bottleneck vlugger in de IO / geheugen / "master"-thread zal liggen.

[graey]

En dan nog. Als een bepaald proces niet gestart kan worden voordat het vorige proces af is heeft het weinig zin om dit proces in een andere thread te gaan draaien. Threading is leuk, maar niet DE oplossing voor ALLE problemen die ALLES eindeloos zal versnellen

[AlexanderB]

RISC.. tja, die is minder "zwaar" dan x86 of x64..
dus kan je dit makkelijker doen, zonder dat je een processor krijgt die 500w verstookt in zn eentje

[Verwijderd]

Heeft geen bal met RISC te maken. Larrabee krijgt een 24-tal x86-gebaseerde cores die elk 4 threads kunnen draaien. Het verschil met desktopchips is dat die cores in-order zijn en daardoor eenvoudiger/kleiner. Echter de prestaties per core liggen lager, wat voor desktopchips geen optie is zolang single-threaded code domineert. Reken maar een jaar of tien voor die situatie er volledig anders uitziet...

[Little Penguin]

Heeft geen bal met RISC te maken.

Het is echter wel zo dat een RISC ontwerp over het algemeen eenvoudiger is en er dus sneller gecombineerd kan worden. Nu kan ik niet spreken over de (Ultra)-Sparc architectuur, maar ik weet bijvoorbeeld dat de ARM-architectuur van origine geheel hardwired was (geen microcode dus). Inmiddels zal dat wel wat minder zijn, maar ik denk dat bij ARM een groot deel nog steeds hardwired is.

Wellicht dat de (Ultra-)Sparc architectuur ook zo opgezet is...

[QinX]

Uhm Larrabee zou dan ook rond de 300W verstoken Oo

bron:Klik

[bart0l0meus]

De vraag is, zeker als ze gebruikt gaan worden in webservers wat het energieverbruik van deze cpu`s gaat worden...
Jammer dat hier niks over gezegd wordt!

[kalizec]

Er wordt in het artikel gesteld dat de overige specificaties vrijwel gelijk zullen zijn aan de huidige generatie (Rock). Die verbruikt ongeveer 250 watt per processor en heeft 16 cores die aan ieder 4 threads tegelijk kunnen werken. Dat komt dus neer op zo'n 16 Watt per core (als je de gedeelde logica zoals geheugencontrollers mee neemt) en zo'n 4 Watt per thread.

[Loen]

Even een korte opmerking: De rock processor is niet "de huidige generatie". De Rock zou in tegenstelling tot de niagara (weinig load / thread x veel threads) de opvolger worden van de UltraSPARC 4+, dus inderdaad voor high performance (hogere load / thread x relatief weinig threads), alleen is de release van de Rock geloof ik van vorig jaar opgeschoven naar op zn vroegst eind dit jaar...

Beide lijken mij een zeer goede stap in de goede richting na de niagara 2. Ik hoop alleen dat dit verhaal eind volgend jaar nog steeds zo mooi/uniek klinkt als nu...

[Verwijderd]

voor wat voor instructies is processor bedoeld? kan iemand mij dit vertellen.
256taken klinkt indrukwekkend maar is dit specifiek voor servers? en is dit beter als x86 en x64? of is dit vergelijkbaar met IBMs power cpu?

[Loen]

Dit is specifiek voor Solaris (UNIX). Er zijn misschien wel een paar knutselaars die Linux aan de gang krijgen, maar daar is het in principe niet voor bedoeld. Het is dus meer vergelijkbaar met IBM's power cpu, al is die heel anders opgebouwd (meer snelheid per core tov veel cores).

Edit: inderdaad specifiek voor servers trouwens... ala apache zoals hierboven...

[Reactie gewijzigd door Loen op 23 juli 2024 13:34]

[avatar]

Van http://www.sun.com/servers/coolthreads/t5120/

# Ubuntu Linux distribution certified for the Sun SPARC Enterprise T5120 server, providing choice of best open source operating systems available: Solaris and Ubuntu Linux

Linux wordt dus volledige ondersteund op deze machines.

[Loen]

https://lists.ubuntu.com/...ce/2008-March/000400.html

[demonite]

Ik vind dit een beetje de boel neppen. Deze processor kan helemaal geen 256 threads simultaan uitvoeren. Hij heeft maar 16 cores en kan dus maar 16 threads simultaan executen. Dat ze er een truuk in hebben gebouwd die het sneller maakt om per core tussen 16 verschillende threads te switchen is heel wat anders. Dat lijkt erg op intel's hyperthreading en is dus alleen maar effectief in bepaalde situaties. Zoals ze zelf al aangeven, in webservers waar threads staan te wachten op IO.. Maar hoe vaak zal deze situatie plaatsvinden ? Om effectief te zijn zouden 240 vd 256 threads dat dus moeten doen... Beetje vreemd hoor, als ze 'm nou 16 core dualthreaded hadden gemaakt was deze processor inzetbaar in een veel groter toepassingsgebied.

[Fiander]

Als je een webseerver hebt, dan zou deze processor maar één ding moeten hoeven doen. en dat is webpaginas naar de gebruiker sturen.

daarvoor moet de cpu wachten op ontvangen berichten van de netwerkkaart, en wachten op de disk IO. ( databases gaan via netwerk.( hobbisten daargelaten ))

stel php.
komt aanvraag voor pagina binnen.
cpu vraagt aan disk om php pagina. wacht wacht wacht.
cpu krijgt seintje van disk systeem dat data klaar staat.
cpu gaat php parsen.
cpu ziet in php dat er de query uit een database moet komen. wacht wacht wacht.
cpu krijgt seintje van netwerk dat data klaar staat.
cpu gaat verder met parsen.
cpu geeft aan netwerk systeem door dat er data verstuurt moet worden.
cpu wacht op volgende aanvraag voor pagina.

je ziet, bij deze hele simpele pagina is de cpu al twee keer aan het wachten op IO.
en dan vergeet ik voor het gemak alle includes van php even, en doe ik ook net alsof er maar één database aanvraag is. hoe groter / zwaarder de website, hoe meer de cpu op IO momenten zal moeten wachten. Hoeveel taskswitches denk je dat een website als tweakers heeft per pagina, en hoeveel paginas per minuut.

gelukkig zijn het disksysteem en de netwerkkaart tegenwoordig intelligent genoeg om zelfstandig data te kunnen ontvangen / versturen.

Beetje vreemd hoor, als ze 'm nou 16 core dualthreaded hadden gemaakt was deze processor inzetbaar in een veel groter toepassingsgebied.

leg dat eens uit ?

[Jaco69]

16*16 is toch beter dan 16*2? En 256 processen draaien er wel minstens op een modern OS.