Meer details over Suns Niagara-processor

Vier ontwerpers van Sun zullen in augustus op het Hot Chips symposium een paper presenteren over de Niagara-processor, waarvan het ontwerp onlangs is afgerond. Van deze paper is ondertussen al een samenvatting verschenen, zodat bezoekers van het symposium van te voren kunnen bepalen welke presentatie ze bij zullen wonen. InfoWorld heeft deze samenvatting kunnen bemachtigen, waardoor een aantal details van de Niagara-processor bekend zijn geworden.

De Niagara zal bestaan uit acht core's. Deze kunnen elk vier threads tegelijkertijd uitvoeren. Hierdoor kan de Niagara in theorie maar liefst 32 threads tegelijkertijd uitvoeren. De diepte van de pipeline van elke core is gelimiteerd tot zes niveaus. Dit betekent dat de klokfrequentie van de processor relatief laag zal zijn, waarschijnlijk rond de 1GHz. Dit heeft echter wel weer een gunstig effect op het energieverbruik. Ook heeft dit voordelen als er meerdere threads tegelijkertijd uitgevoerd moeten worden. Elke core van Niagara heeft de beschikking over een eigen cryptografische co-processor, een FPU en 3MB aan L2-cachegeheugen.

Als er alleen naar de specificaties van de Niagara wordt gekeken, dan is het snel duidelijk dat deze processor is ontworpen voor webservers. Deze moeten namelijk veel kleine threads, het serveren van een pagina, tegelijkertijd uitvoeren. Kevin Krewell, hoofdredacteur van The Microprocessor Report, is van mening dat de Niagara hiermee erg geschikt zal zijn voor zoekmachines zoals Google. De processor zal door Texas Instruments worden geproduceerd en ten tijde van de presentatie zullen de eerste exemplaren al beschikbaar zijn. Sun wilde geen commentaar geven, maar wist wel te vertellen dat de eerste systemen met Niagara-processors begin 2006 op de markt zullen verschijnen.

Reacties (36)

[NaliXL]

Ik kan me ook voorstellen dat zo'n processor extreem geschikt is voor cluster projecten, omdat cluster-software sowieso al gemaakt word om verdeeld te worden over verschillende threads en/of machines.

[procede]

Lijkt mij eerlijk gezegd niet. Clusters doen vaak berekening die ze over meerdere computers verdelen. De machines werken parallel, maar de processen binnen elke machine kunnen prima serieel lopen. Het heeft totaal geen zin om ze nog binnen afzonderlijke machines op te delen.

[Anoniem: 75364]

Het heeft totaal geen zin om ze nog binnen afzonderlijke machines op te delen

Zeker wel. Maar alleen als het algoritme gebruik kan maken van de 'locality' van de data.

[hardwareaddict]

Deze processor is niet geschikt voor clusters omdat hij te duur is per Ghz prestatie. Bij clusters is de node prijs erg belangrijk.

Ik gok een quad niagara is rond de 100k dollar.

Daar kun je bij een cluster dus zeker 16 nodes voor betalen (duals).

[n4m3l355]

de complete sun fire reeks is gebaseerd op clustering daarom zou het heel logisch zijn om deze ook in clusters tegen te komen. natuurlijk is deze duur maar als je sun koopt weet je wat je krijgt; namelijk kwaliteit en stabiliteit wat het dan ook wel waard is
een andere reden dat deze geschikt is voor clustering is dat ie weinig warmte en energie slurpt. dit betekent dat je veel van deze procs in een ruimte kan stoppen zonder je zorgen te gaan maken om extreme afzuiging. nog een reden is dat je veel ruimte gaat besparen. neem 8 cores in 1 systeem of een octa systeem tegenover 4 dual of in het ergste geval 8 single systemen.
deze 8 core systeem zou je goed kunnen stoppen in een 3u kastje terwijl 8 single systemen minimaal 8u nodig hebben.

[Anoniem: 96788]

Te Duur...en die stabiliteit, dat gaat misschien op bij een kantoor omgeving ....maar niet in een technische automatiserings gebeuren waar SUNS diverse machines moeten aansturen (met heel veel data verkeer) Als dan door eigen programmeurs drivers geschreven moeten worden, dan zijn ook SUN workstations niet echt super stabiel.

Wel heeft SUN een hele goede ondersteuning aan deze programmeurs, en dat is iets dat uiteindelijk veel problemen oplost. Maar of dit al dat geld waard is?

[hardwareaddict]

Hoeveel grote Sun clusters staan er in Europa?

0?

Harde data zegt iets van 2048 processor power3 systeem in UK. Een 1024 processor R14000 in NL. Binnenkort verschillende machines van IBM met in Dwingeloo rond de 12288 processors en in spanje is het onduidelijk maar naar ik herinner me vaag 2.5 racks (5120 processors). In Duitsland verschillende T3E's (Alpha processors momenteel en in toekomst opterons). Dan hier en daar nog kleine clustertjes bestaande uit P4's en in Amsterdam een SGI cluster van 416 processors bestaande uit 'nodes' van 64 processors (en 32 processors). Voorheen genaamd 'partities' Altix3800 Itanium2 Madison 1.3ghz (bugfixed budget release van itanium2).

Kortom, in heel europa komt Sun eigenlijk nauwelijks aan bod. Prijs ligt *veel* te hoog. Dan zeg ik het heel voorzichtig.

[Anoniem: 96788]

Ja...het blijft een SUN he....altijd lekker duur.

Werk zelf veel met SUN workstations en als ik die prijzen vergelijk met Intel/AMD architektuur, dan zou ik het wel weten.

Maar ja, mijn Linux lobby wordt door het vastgeroestte management nog niet begrepen.

Maar ik zou overstappen op HP proliant servers.
Met een mooi ASM500 HD kluster.

[TheEmperor]

Het lijkt me ook dat programma's als 3d studio (programma's die goed taken parrallel kunnen uitvoeren) ook veel baat hebben bij dit soort architectuur.

[reactie op desktop]
Klopt maar het idee is dat processors niet op steeds meer GHz kunnen draaien, die grenzen komen langzaam in zicht. Om de programma's toch sneller te laten werken is dit een prima oplossing. 32*1 Ghz = 32 Ghz. Ik weet dat dit niet een realistische vergelijking is, maar het toont wel de kracht van dit concept aan. Ik denk dat in de toekomst dit heel gewoon wordt, omdat met dit ontwerp het vermogen dat nodig is, veeel lager is dan een 32Ghz cpu

[Anoniem: 114684]

Dat denk ik niet...

Een webserver moet per definitie veel taken parallel uitvoeren.

Bij 3Drendering hoeft dat niet. Als je de taken onnodig onderverdeeld, heb je onnodig veel overhead.

Dus 4 processors/cores die samen 8 GHz opbrengen zijn voor 3Drendering sneller dan 8 processors/cores die 8 GHz opbrengen...

[Anoniem: 78237]

Wat een onzin.
Wat denk je dat het nut is van een renderfarm?

[Anoniem: 114684]

Dat is heel simpel...

100 pc's van 3GHz zijn veel goedkoper dan 1 supersnelle PC van 300GHz

[Ralph Smeets]

Het is zeker geen onzin dat Desktop zegt. Sterker nog, ik durf mijn hand ervoor in het vuur te steken dat wat hij zegt klopt. Ergens moet er namelijk synchronisatie tussen de verschillende core's optreden en dat betekent overhead in zowel hardware als software.

Zelf ben ik aan het experimenteren met SimCluster, dit is een programma dat het toelaat om bijvoorbeeld NCSim simulaties in stukken te hakken en deze over meerdere CPU's te verdelen. Uit de eerste resultaten blijkt dat je met drie CPU's iets meer dan twee keer zo snel bent. Voor regressiewerk (het runnen van honderden simulaties in batchmode) is SimCluster dus niet interessant.

Een renderfarm is niet veel anders dan elk te renderen frame naar een andere cpu te sturen. Dit is dus niet hetzelfde als parallel werken, waarbij een frame door alle cpu's op hetzelfde moment wordt verwerkt.

Een webserver is vergelijkbaar met een renderfarm omdat er vele onafhankelijke taken (webpagina's serveren) tegelijkertijd uitgevoerd moeten worden. Door elk een eigen cpu te geven kan dat makkelijk parallel worden opgelost. Echter als de taken met elkaar samenhangen, dan is een snellere CPU een stuk sneller.

[hardwareaddict]

Renderfarm moet goedkoop werken met name. Dat gaat niet op voor deze papieren cpu.

Bij wijze van spreke een quad itanium van nu loopt voor dezelfde prijs tegen die tijd een niagara eruit op 3d modelling gebied.

Laat staan een quad opteron dual core tegen die tijd.

[Anoniem: 14038]

8 cores met elk 3Mb L2 cache is 24Mb Cache in totaal.
En ik gok even dat die L2 cache zo'n 75% van het aantal torretjes in beslag neemt. En ik schat dat 1Mb L2 cache zo'n 40M transistors nodig heeft.
24*40*1.333..=1240M transistors.
Hoe in hemelsnaam willen ze zo'n grote plak bakken?

Kunnen ze dan ook cores uitschakelen als die niet goed getest worden zodat je nog cores overhoudt om het werk te laten doen en je een budget versie van die CPU hebt?

Nu maken ze nog plakken met zo'n 200 a 300M torretjes max. Maar zelfs als ik overdrijf zou je toch nog meer dan 600M mogen verwachten of zelfs het dubbele.
Dan moeten ze hem wel laag klokken want anders krijg je zoveel watten dat zelfs vloeistofkoeling het niet meer aan zou kunnen.

Nou ja, als het ze lukt om zoiets te maken dan neem ik daar m'n petje voor af hoor. Het geeft aan dat we qua ontwikkelingen nog in razensnel tempo doorgaan en het aantal transtoren in de buurt van de 10^9 komt.

[hardwareaddict]

3MB per core gaat te weinig zijn. Je hebt zeker

2MB per thread nodig en wel met name 1 per thread, omdat je anders bij zoveel threads (te weten: 4) enorme problemen krijgt met exponentiele resource wachttijden. Dat werkt als volgt.

1 thread heeft resource nodig, de thread moet op een andere thread wachten. Terwijl deze wacht komen de andere 2 threads daar ook aan en dan wachten de threads op het laatst alleen nog op elkaar.

Dat is dus exponentieel problematisch bij het ontwerp van de chip.

Dus 8MB L3 cache per core lijkt me zeker een minimum. Kom je uit op 64MB. Om resources niet al te veel te belasten lijkt me echter 256 of 512MB handiger. Elke memory access betekent namelijk dat de overige 31 threads op die ene thread moeten wachten

Dat stop je dan in 0.09 natuurlijk, in 0.13 kun je 't wel vergeten.

Maar dan heb je ook wat voor de Sun verzamelaars

Op het moment dat er 1 shared L3 cache komt voor alle threads tegelijk, dan heb je 1 en al ellende en vreselijke wachttijden. Heel weinig software gaat dan goed lopen op zo'n cpu.

Ik vraag me ook af welk OS ze willen gaan draaien op die CPU. Linux gaat niet goed lukken. 4 threads per core, hoe ga je dat schedulen?

[Anoniem: 87964]

Hmm, wat een onzin. Als een thread moet wachten op een andere thread omdat die wat nodig heeft zal cache niet veel verschil uit maken. Cache geheugen is ontzettend duur en dus 512 mb aan cache lijkt me ENORM duur. cache is alleen zodat cpu gegevens opnieuw snel uit kan lezen en ram latency kan omzeilen. De truuc van de cpu is juist om verschillende threats parallel te laten lopen. Zoals een dual/quad/etc. config. Zoals hier beschreven staat. Voornamelijk voor webservers. Kunnen verschillende threads tegelijk uitvoeren, geen cpu latency omdat een andere thread nog bezig is..

[hardwareaddict]

Wat denk jij dat webservers doen.

Data binnen de L1 cache verwerken?

Of denk je net als ik dat die data vanuit de RAM verwerken, namelijk data die via het network binnenkomt en dan verwerkt dient te worden?

In dat laatste geval is meerdere threads draaien op 1 processor een vreselijk risico. De niagara wil er maar liefst 8 gaan draaien...

Webservers kun je prachtig gedistribueerd aan de praat zetten. Dus op goedkope systemen. Als er 1 uitvalt heb je de resterende quads nog die het prima opvangen.

Zo doen enige communicatiegiganten het al *momenteel*.

Dus 100% reliability voor een webserver is echt niet nodig omdat de kans dat al je quads uitvallen natuurlijk superklein is.

Alleen je netwerk moet dus superbetrouwbaar zijn.

Er is dus weinig behoefte aan superdure processors.

[Anoniem: 93545]

Dus 8MB L3 cache per core lijkt me zeker een minimum. Kom je uit op 64MB. Om resources niet al te veel te belasten lijkt me echter 256 of 512MB handiger.

als er 8mb op zo'n cpu komt wordt'ie ergens richting de 6000 euro (minstens) en dan nog: waarom moet hread 2 wachten op thread 1? als thread 1 zijn meuk uit het geheugen moet halen omdat het niet in de cache staat kan thread 2 zijn data toch wel uit de cache halen? NIet vergeten dat dit ding de threads tegelijk uitvoert en niet eerst 1, dan 2 etc..

[hardwareaddict]

Volgens de meest recente informatie kunnen er maximaal 8 threads draaien.

De 8 threads kunnen niet simultaan shared resources bewerken. Dat is het probleem van meerdere threads op 1 cpu.

Bij CMP is het probleem iets kleiner, maar als het gaat om de memory is het probleem net zo. Dus dual core oplossingen zijn geniaal voor applicaties die *niet* veel met RAM doen.

De statistische kans dat van je 8 threads er een aantal tegelijk bewerkingen op de RAM doen is natuurlijk levensgroot.

Er kan er maar 1 dus tegelijk schrijven naar de RAM.

Met wat geluk kunnen ze wel parallel lezen.

Dat schrijven is overigens supertraag. Dus de overige 7 cpu's kunnen enorm veel instructies verwerken en als ze *dan* een access doen naar de RAM, dan dienen ze te wachten omdat er een andere bezig is te schrijven in de RAM.

Erg belangrijk wordt dus of lezen in parallel kan.

Bij erg dure cpu's kan dat soms, maar ik betwijfel of dat voor Niagara ook zo gaat werken.

Reacties elders lezend op andere sites van 'hardware experts' is dat niet het geval.

Daar het gros van de bewerkingen van databases met name te maken heeft met RAM en DISK operaties, is deze chip dus doomed.

Natuurlijk is het wel zo dat JAVA applets vreselijk traag zijn t.o.v. andere programmeertalen. Dus daar 'win' je dan zogenaamd enige efficiency terug.

Op die manier kan SUN zijn hardware nog redelijk laten lijken...

[CaineTanathos]

Zolang er geen benchmarks van zijn kun je niet weten wat deze processor gaat doen (kijk maar naar de prescott, eerst dachten ze dat ie sneller ging zijn, maar in de realiteit mocht ie al blij zijn dat al even snel was als een Northwood (op basis van dezelfde kloksnelheid).

btw. Deze processors zullen ook wel niet goedkoop zijn en de moederborden ook niet.

[Anoniem: 75364]

En de prijs per core dan? Of zelfs: De prijs per pipeline?

[hardwareaddict]

Ha ik heb een nog grappigere rekendefinitie voor je, databases moet je per cpu voor betalen. 1 core van die niagara is wel *erg* traag.

Dus dat worden dure databeestjes...

[stewie]

reken maar op een 1.5 en 1.8Ghz.
SUN heeft gezegd dat ze nu zullen focusen op een iets hogere clock snelheid.

[hardwareaddict]

Dat zouden ze al jaren tevoren aankondigen.

[Dekaasboer]

Bij een renderfarm hebben ze speciale software die computer 1 frame 1 laat rendere, comp 2 frame 2 enz.

Het wordt niet realtime gerendered (1 frame van gollum in lotr duurde 5-7 minuten om te renderen, treebeard duurde uren per frame)

[hardwareaddict]

Meer zo van: "wow, deze processor is *werkelijk* gebouwd om te laten zien hoe goed Sun is op papier".

Wat een papieren processor zeg.

Dit gaat natuurlijk met een kans van 1/32 gebouwd worden. 4 threads per cpu is gewoon niet realistisch, want we weten al van de P4 hoe slecht het werkt om er 2 per cpu te doen.

Laten we eens realistisch zijn.

256 registers per thread voor van die highend cpu's.

Dus zo'n cpu heeft nodig voor 1 core al iets van 1024 registers.

Die cpu gaat dus nooit gebouwd worden.

Maar marketing technisch gezien klinkt het leuk hoor.

[fallen_angel]

Ik weet het er mijne niet van, maar zitten er tussen RISC en CISC processoren ook niet een verschil in het aantal registers dat nodig is?
Naar mijn weten zijn intel processoren CISC gebaseerd en SUN processoren RISC gebaseerd.

Maar goed, zoals ik al zei, ik weet er niet zo heel veel van.

[reactie op hardware addict]
Thanks voor de opheldering.
Toch blijf ik het vreemd vinden dat men dan alleskunners (combi RISC/CISC) produceert terwijl men een applicatie (webserver) voor ogen heeft waar deze processor voor moet gaan dienen.

helemaal offtopic natuurlijk.

[hardwareaddict]

CISC en RISC verschillen zijn volledig komen te vervallen de afgelopen jaren.

Deze jaren 80 definities zullen we het maar niet over hebben.

De huidige processors zijn zowel CISC als RISC.

Daar er nog heel erg heetgebakerde personen zijn die zweren bij RISC en een andere weer bij CISC, lijkt het me ook niet handig om een standpunt in te nemen of het nu meer CISC of RISC is.

Maar Linus noemt ze allemaal CISC als je het niet erg vindt en die quote ik dus maar. Zelf zou ik namelijk meer als 1 instructie per clock onder CISC willen scharen. De meest recente Ultra doet er 3-4 per cycle.

Daar dit de prestatie het meeste beinvloedt noemt Linus het "x86 has won".

[hardwareaddict]

Naar aanleiding van reactie :

Natuurlijk dient elke zichzelf respecterende fabrikant alleskunners te maken voor zware applicaties als webservers, anders draait het te traag.

Belangrijk bij webservers is grote caches bijvoorbeeld.

Een andere is dat er (te veel) threads lopen veel random access latency nodig is en een hele goede connectie naar diskarrays.

[hardwareaddict]

Laten we nog iets meer wow zeggen.

1 Ghz zie ik nu. *erg* ambitieus weer gekozen hoor.

Laten we eens rekenen. Dat moet dus minimaal in 0.09 geschieden met zoveel registers.

Dan is de vraag hoe groot de die wordt, want je zult ook wel fiks wat L2 of L3 cache nodig hebben.

Laten we zeggen een MB of 128 aan L3 cache.

Ik gok de diegrootte op 1000 mm^2

Dan zijn de yields enorm laag en is de cpu dus uiterst traag (1Ghz). De productieprijs moet miminaal dan rond de 1000 dollar per core bedragen.

Dat betekent een verkoop prijs van minimaal 10000 dollar per cpu.

Wow.

Dus voor 1 zo'n chip kun je een quad opteron dual core 3Ghz halen ook.

Dat is bij elkaar 8 x 3Ghz = 24Ghz

Alternatief is zo'n zielig 1Ghz geclockte niagara die 32 threads kan laten lopen en allemaal op supertrage snelheid.

Laten we zeggen heel optimistisch elke thread op 30% snelheid.

0.3 * 32 = 10.6Ghz

En je kunt *nu* een quad opteron 2.0Ghz halen voor 10000 euro.

Dat is dus inclusief alles (memory, harddisk etc).

Verkoopprijs per processor ligt onder de 1000 dollar.

Daar kunnen ze die niagara niet eens voor *drukken*.

[_Thanatos_]

Misschien is één core van een Niagara wel 2x zo snel als jouw 3GHz Opteron. Dat kun je nooit zo 1-2-3 zeggen.

Bovendien mag je gigahertzen NOOIT bij elkaar optellen. Dat moet je toch inmiddels weten.

En wat is er zielig aan 1GHz? Je gaat toch ook niet zeggen dat AMD's 2,2GHz zielig is tov Intels 3,6GHz...

[hardwareaddict]

Laten we even realistisch zijn he

1 Ghz met 4 threads = 1 core.

Dus effectief praat je over iets van 30% efficiency x 4 threads per processor x 1Ghz = 1.2Ghz

Dus een dual core itanium of dual core opteron zit daar qua prestatie *ruim* boven. Ik gok op rond de factor 4 minimaal. Echt *minimaal*.

Dat hele SMT idee is totaal achterhaalt. Multicore is wel heel interessant.

IPV geklier met 4 threads die alle resources moeten sharen natuurlijk (ellende ellende, 3 threads die op 1 thread moeten wachten tot deze resources vrijgeeft is wat er continue gebeuren gaat met de bekende exponentiele wachtrij ellende) is het veel handiger een goede 64 bits processor hoog te clocken natuurlijk.

Principe van Seymour Cray is sterk van toepassing hier: "If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens?"

[_Thanatos_]

Maar je probeert nu nog steeds te concluderen over de snelheid van de Niagara, terwijl je NIET weet hoe snel ie zal zijn. Dat staat nml nergens vermeld. Als je zo Gigahertz-geil bent, waarom vergelijk je dan met AMD?

En hoe kom je erbij dat SMT achterhaald is? Het blijkt in veel gevallen een stuk responsiever en zelfs sneller te werken met HTT. Veel taken komen enkele procenten sneller uit, terwijl het zelden is HTT trager.

[hardwareaddict]

Er is iets meer bekend over nu.

Er kunnen maximaal 8 threads uitgevoerd worden. Het is geen Simultaneous multithreading maar Switch on event multithreading wat Niagara gaat aanbieden.

Kortom deze CPU is trager als een dual core opteron/itanium in 2006 zal zijn.

Op grond van Ghz alleen al.

3MB L2 cache gaan dat ook niet corrigeren natuurlijk. Hooguit maskeren. Overigens, intel had al jaren geleden aangekondigd 24MB L3 cache te stoppen op hun itanium series op 1 van de toekomstige multicore processors...

Je mag aangeven welke cpu je niet wilt met er achter gegokte prijzen tegen die tijd voor de 4 processor capable series in euro's voor kleine bedrijven (dus niet als je er 1000 afneemt van producent zelf):
- dual core AMD 3.6Ghz opteron 1500
- dual core INTEL itanium2 2.2Ghz 10000
- dual core IBM powerX 2.6Ghz 10000
- 8 core SUN 1Ghz Niagara 10000

Iedereen streept dan die Niagara weg natuurlijk