Sun komt met 64 threads tellende Niagara 2

Komende week onthult Sun de Niagara 2-chip, die over acht cores beschikt die elk in staat zijn acht threads tegelijk af te werken. De opvolger van de UltraSparc T1 moet, net als zijn voorganger, uitblinken in parallelle berekeningen.

De chip zal officieel onder de naam UltraSparc T2 door het leven gaan en moet in staat zijn 64 threads tegelijkertijd in behandeling te hebben door deze over acht verschillende cores op één plakje silicium te verdelen. Hoewel deze parallelle verwerking heel wat voordelen kan bieden, is de doelgroep eerder beperkt. Het lijkt Sun dan ook niet te doen om het veroveren van een groot marktaandeel, maar vooral om het bekendmaken van zijn naam in de servermarkt. In het vierde kwartaal maakte het bedrijf maar liefst 329 miljoen dollar winst op zijn serverdivisie, waarmee het de op drie na grootste serververkoper is. Het merendeel van die inkomsten komt op rekening van de Opteron-servers die het bedrijf aanbiedt. Toch biedt de Niagara 2 een interessant alternatief.

Als eerste valt op dat de chip voor zijn acht cores beschikt over een totaal van vier megabyte L2-cache. Elke core beschikt bovendien over een geïntegreerde fpu, waarmee volgens Sun bij floating-point-berekeningen tien keer betere prestaties dan met de Niagara 1 gehaald kunnen worden. Dit is alvast veelbelovend nieuws, want de UltraSparc T1, die door Tweakers.net is getest, beschikte slechts over één floating-point-unit per chip, waardoor de prestaties in diverse toepassingen ernstig gelimiteerd werden. De T2 is verder voorzien van twee 10Gb Ethernet-poorten en acht cryptografische units, die het verkeer over de netwerkpoorten kunnen versleutelen. Tot slot beschikt de chip ook over een pci-express x8-controller voor uitbreidingen, waarmee hij de eerste serverchip is die standaard ondersteuning voor dergelijke uitbreidingen biedt. Ondanks al deze verbeteringen zou de nieuwe generatie de prestaties per watt weten te verdubbelen ten opzichte van de T1: de T2 verbruikt volgens Sun slechts twee watt per core, met een totale energieconsumptie van minder dan 95W.

Sun beweert met zijn T2 alvast twee single-socketwereldrecords te kunnen vestigen. In de SPECint_rate2006 en SPECfp_rate2006 claimt het bedrijf respectievelijk een score van naar schatting 78,3 en 61,5 te kunnen realiseren. Op zich zijn dat behoorlijk indrukwekkende resultaten, al mocht van dit ontwerp eigenlijk niet anders verwacht worden. De hoge verwachtingen worden onder andere ingegeven door de bandbreedte van ruim zestig gigabyte per seconde voor communicatie met het werkgeheugen. Concreet komt het erop neer dat er met 42GB per seconde gelezen kan worden uit het geheugen, terwijl tezelfdertijd met 21GB per seconde naar het ram geschreven wordt. Dit werkgeheugen kan dankzij de vier controllers uitgebreid worden tot een maximum van 64 FB-DIMM-modules. Hoewel Sun de cijfers nog niet officieel heeft bevestigd en dus hardnekkig van 'schattingen' spreekt, lijken de cijfers op concrete benchmarkresultaten te wijzen. Duidelijk is in elk geval wel dat Sun met zijn nieuwe krachtpatser voor een flinke stroomversnelling zal zorgen.

Reacties (23)

Wat ik even niet snap, met al dat gepraat over cores, dat het nu over de threads gaat. Kan bijvoorbeeld een Intel Core Duo per core maar een thread? En zijn de threads in zo'n Niagara echt gelijktijdig uitgevoerd of zitten ze elkaar ergens nog in de weg?

Omdat ik bij berichten van Intel en AMD nooit lees over het aantal threads, vraag ik mij ten slotte nog af: wat weet Sun dat die anderen niet weten?

Desktopcpu's kunnen 'meerdere threads per core hebben' maar niet gelijk uitvoeren.

En Sun doet dit omdat een bedrijf dat zoiets nodig heeft, er ook het geld voor heeft. Wij zouden er niet voor betalen omdat de meesten van ons al het geld niet hebben maar vooral omdat het het niet waard is voor thuis.

Desktopcpu's kunnen 'meerdere threads per core hebben' maar niet gelijk uitvoeren.

Met HyperThreading kan dat dus wel (een vorm van Symmetric MultiThreading, SMT).
Sun heeft dus ook een eigen SMT-variant. In dit geval kan iedere core dus 8 threads tegelijk verwerken, op een vergelijkbare manier als de Pentium HT 2 cores met 1 thread kan verwerken.
In totaal kom je dan dus op 8x8 = 64 threads op deze 8-core processor.

Intel is overigens van plan om HyperThreading ook op de Core2-architectuur te introduceren. Dit staat op de agenda voor Nehalem, de opvolger van de Penryn.
Voor zover ik weet is het nog niet bekend of Intel dan ook meer dan 2 threads per core gaat ondersteunen.

[Reactie gewijzigd door ddbruijn op 3 augustus 2007 21:01]

Ik ben benieuwd.. De T1 was een prima doos voor recht-to-recht-aan web-hosten en dergelijke, maar totaal niet geschikt als bijvoorbeeld Java applicatie server (die nogal wat floating point wil gebruiken).
Hopelijk krijgen we deze ook weer een tijdje om te testen en is deze goed genoeg om te blijven.

En die minder dan 95W per CPU.. ik ben benieuwd wat dat per server is. Dat kan nog best wel eens de moeite waard worden om een paar dozen er uit te gooiien, te vervangen door deze, en de rest te besparen op power en koeling.

[Reactie gewijzigd door Sentry23 op 3 augustus 2007 16:54]

. De T1 was een prima doos voor recht-to-recht-aan web-hosten en dergelijke, maar totaal niet geschikt als bijvoorbeeld Java applicatie server (die nogal wat floating point wil gebruiken).

Dat is natuurlijk onzin. Ook de front-end van een Java EE applicatie wordt in Java afgehandeld. Dikwijls zijn veel requesten (ook in Java) simpel van aard. In met name de view-layer wordt nogal was caching toegepast, zodat de meeste requesten eigenlijk neerkomen op wat waardes in het geheugen opzoeken, die als een string formatteren en terug vervolgens terug sturen.

Rekenen, laat staan FP, komt hier dan niet echt bij te pas.

Het probleem is echter dat het plots nogal eens erg druk kan worden. Een snellere CPU kan dan helpen; je handelt een request sneller af zodat je backlog aan requesten sneller slinkt.

De oplossing die Sun hier presenteert kan echter ook zeker helpen; je kunt simpelweg meer simultane requests aan, hoewel zoals ddbruijn hieronder al aangeeft, 1 request niet sneller wordt afgehandeld dan op een 'gewone' CPU.

Het is dus een behoorlijk special purpose ding, maar die special purpose komt toch nog wel heel erg vaak voor in de praktijk, en mensen die met load problemen in de view layer zitten zouden deze CPU best wel eens behoorlijk kunnen waarderen.

HT vult toch alleen "gaatjes" op waardoor het lijkt dat je 2 threads gelijk gebruikt?

Het lijkt niet zo, het is zo.
Binnen een core heb je meerdere rekeneenheden, die tegelijkertijd instructies kunnen uitvoeren (bepaalde typen eenheden zijn ook meerdere malen uitgevoerd, zo heeft een Athlon 3 ALUs, en een Core2 zelfs 4 ALUs per core), net zoals bv bij een moderne videokaart. Met HT kun je meerdere threads tegelijk gebruiken om instructies te voeden aan alle rekeneenheden, waar bij een single-threaded core bepaalde rekeneenheden gewoon niets zitten te doen.
Zowel bij een dualcore als bij een single-core HT processor kun je dus twee threads tegelijkertijd uitvoeren (letterlijk: van beide threads worden tegelijkertijd instructies uitgevoerd).

Ik denk dat we naar een model toe gaan waar het begrip 'core' verdwijnt. Op een processor met zowel SMT als shared caches is het begrip 'core' nog maar heel vaag, omdat data en instructies in principe voor alle cores tegelijk beschikbaar zijn.
Het uiteindelijke resultaat lijkt me dan ook een soort black box waar je gewoon X threads op kunt draaien, en de CPU zoekt zelf wel uit waar ie het op gaat uitvoeren.
Momenteel hebben we nog per core een hele hoop rekeneenheden, waar je eigenlijk niks mee kunt. Meestal worden er maar 2 of 3 instructies tegelijk uitgevoerd, meer kan niet. Dit terwijl een moderne processor meer dan 10 rekeneenheden in een core heeft.
Een ontwerp waar je al die rekeneenheden op 1 hoop veegt (uiteindelijk 1 'core' == 1 rekeneenheid (ALU/FPU/MAD/etc)?), en dan middels SMT een X aantal threads op loslaat, lijkt me in theorie erg efficient. Je hebt dan aan de ene kant een berg instructies, aan de andere kant een berg rekeneenheden, en de logica kan iedere instructie naar iedere rekeneenheid sturen.
Momenteel kan een dergelijke dynamische allocatie alleen binnen een thread verwezenlijkt worden, via out-of-order execution. Maar dat blijkt al jaren niet efficient genoeg meer, en de IPC ligt veel lager dan wat er theoretisch mogelijk zou zijn.
Je loopt tegen het probleem op dat je teveel afhankelijkheden hebt binnen een enkele thread.
Door meerdere threads tegelijk te draaien heb je gegarandeerd meer onafhankelijke instructies in je out-of-order buffer zitten.

dat klopt. De T2 is bedoeld voor webapplicaties. Daar is het nogal gebruikelijk dat de IP pakketjes onregelmatig binnenkomen. Op deze manier kun je 8 threads efficient één core laten delen. Het maakt weinig uit welk pakketje als eerste komt en welke thread er nodig is, de kans dat de goede thread klaar staat is veel hoger met 8 klaarstaande threads. Anders gezegd: door de onvoorspelbaarheid van webservices zijn er veel gaten te vullen.

SMT werkt wel even op een iets ander niveau dan pakketjes.
Ook een enkele core kan al prima threads laten wachten op het binnenkomen van data, door gewoon de thread in een slaapmodus te zetten, die door een event van de netwerklaag weer tot leven geroepen kan worden.
Het reactieniveau van een kernel is veel lager dan dat van een internetverbinding.

SMT werkt op instructieniveau, en daar gaat het dus juist om de threads die NIET wachten op externe input, maar die instructies uit willen voeren.
Het probleem waar Intel vooral met x86 tegenaan liep, is dat ze eigenlijk veel meer rekenkracht in een processor konden bouwen dan dat je er met een x86-thread uit kunt halen. Ze konden dus wel meer dan 2 ALUs op een processor zetten, maar met een enkele thread kon je zelden meer dan twee ALU-operaties per cycle uitvoeren. Daarvoor had je teveel afhankelijkheden.
Met SMT los je dat probleem op, omdat je extra bronnen van onafhankelijke instructies toevoegt.

Het verschijnsel bij Sun's processor zal dus zijn dat je de requests niet sneller kunt afhandelen, maar je zou er wel meer tegelijk kunnen afhandelen.
Wij hebben op het werk een voorganger van deze CPU in de webserver, die naar ik meen 32 threads kan draaien (quadcore met 8-voudige SMT). We gebruiken ook een test/ontwikkel-machine met 'gewone' x86 processors (beiden met Solaris). Wij merken zelf ook dat de test-machine op zich sneller is, maar onder load houdt de Sun-processor zich beter. Voor een webserver is dat eigenlijk best een mooie eigenschap. De pagina's hoeven niet sneller gegenereerd te worden, maar je kunt er wel meer tegelijk genereren.

Enige voorspelbaarheids-issues zouden dus niet afhangen van eventuele IP-pakketjes die al dan niet binnenkomen, maar van de taken die de requests uit moeten voeren. Terwijl de ene service/thread een stuk geheugen kopieert, kan de ander het een en ander doorrekenen, want dat deel van de core is dan niet in gebruik.

De T2 is verder voorzien van twee 10Gb Ethernet-poorten

"The network is the computer"

[Reactie gewijzigd door Herko_ter_Horst op 3 augustus 2007 16:53]

hmm, unix

Nu alleen nog routers en kabels die het aankunnen.

Ik vind "The network is the computer" een vage uitspraak. Er moet ergens een keer een computer zijn die alles berekend en alles doorstuurt. Dan vraag ik me af, waarom je eigen computer niet? Dan hoef je tenminste geen gebruik te maken van anderen computers(veiligheidsrisico's?).

Jij redeneert vanuit de enkele (bovengemiddeld technisch onderlegde) gebruiker die misschien de aanbiedende partij niet vertrouwt en daarom dingen in eigen hand wil houden.

De gedachte bij Sun is omgekeerd en redeneert vanuit het perspectief van een (grote) organistatie - die misschien al die afzonderlijke gebruikers niet vertrouwt: waarom zou je allerlei spullen decentraal neerzetten (hardware die je specifiek op een taak moet afstemmen, software die je per gebruiker/machine up-to-date moet houden), als je ook alles centraal kan regelen (op Sun servers, natuurlijk) en het netwerk als virtuele computer gebruikt via een dumb terminal.

Veiligheid aan de gemiddelde gebruiker overlaten is - zoals inmiddels bewezen door de vele virussen en andere malware - geen goed idee. Sun's aanpak gaat er vanuit dat professionals de centrale infrastructuur onderhouden en daarmee de veiligheid van de gebruikers garanderen.

Je ziet dat - zeker in "enterprise" omgevingen - de IT afdeling vaak dit soort ideeen af probeert te dwingen op "gewone" desktops: allemaal dezelfde machines, centrale software distributie (via Novell, of MSS), je mag zelf geen extra software installeren, etc.

Het hele idee van webapplicaties (met technologieen als Ajax als meest recente ontwikkeling) is in feite een uitvloeisel van het "Network is the computer" principe: de gebruiker heeft alleen nog maar een dumb terminal (de browser) en een netwerkverbinding nodig om bij z'n applicatie te kunnen.

Er zijn echter tenminste 8 problemen in het hele "Network is the computer" verhaal, die - grappig genoeg - zijn opgeschreven door James Gosling (een van de founding fathers van Java): http://blogs.sun.com/jag/resource/Fallacies.html

[Reactie gewijzigd door Herko_ter_Horst op 5 augustus 2007 11:52]

de Niagara 2-chip, die over acht cores beschikt

de T2 verbruikt volgens Sun slechts twee watt per core, met een totale energieconsumptie van minder dan 95W.

dus 16 van de 95W zitten in de rekenkracht, en de rest van het zootje (FPU's cache en I/O) vreet 79W? oi oi oi, en dan roepen wij maar dat die 680i stroom zuipt


disclaimert: niet als fipo bedoeld, alleen wachten is ook zo doelloos...

en edit: * iceheart gaat z'n tagjes eindelijk eens leren onthouden

editje 2: en ik durf te *wedden* dat als dit de 5e post geweest was ik twee groene streepjes had gehad. nougoed, whatever

[Reactie gewijzigd door iceheart op 3 augustus 2007 20:58]

Cache vreet stroom en ook de geheugencontrollers zijn best heftig ja

Cache valt eigenlijk wel mee qua stroomgebruik. Ik denk eerder dat het getal van 2 Watt per Core niet klopt of in ieder geval niet het maximum stroomverbruik van die cores is.

Vond een mooi cirkeldiagram dat het een en ander toelicht:

http://www.opensparc.net/pubs/preszo/07/n2isscc.pdf pagina 18/25:

Afgelopen voorjaar zei SUN zelf, dat het worst-kaas scenario 84W@1.1Vx1.4GHz is (nu blijkt die 84W dus iets hoger te zijn geworden; ~95 Watt).
~31,6% daarvan wordt opgesoupeerd door de SPARC cores, wat volgens bc ongeveer overeenkomt met 3,3 Watt per core (worst kaas).

21,6% van die 84 dient als verwarming (lekt weg, maar ik neem aan dat de relatieve lekkage lager is bij lagere belastingen), ~19% zit in de L2.

Gelukkig kan software via het power-management threads uitschakelen en is er power throttling.

Heeft iemand een idee hoe deze machine zich houdt bij multithreading render applicaties als RenderMan en 3dsmax?

Een echt rekenwonder is het niet.
De SPECfp_rate2006 van 61,5 op een enkele socket is op zich best aardig... Maar dat is mede omdat het een octacore is, en de meeste concurrenten zijn nog dualcore.
De Intel Xeon quadcore op 2.66 GHz haalt ook een score van rond de 60.
De score per core is dus wat matig, maar het aantal cores maakt dat weer goed.

Deze CPU is dan ook vooral ontworpen om zoveel mogelijk threads tegelijk 'in de lucht' te hebben, niet zozeer om threads zo snel mogelijk uit te voeren.
Bij applicaties als RenderMan en 3dsmax is het aantal threads dan ook een middel om de prestaties te verbeteren, niet een doel op zich, zoals bij een webserver/database-server (je hebt vrijwel per definitie 1 thread per request, of meer, dus meer threads is meer requests afhandelen).
Doorgaans wil je bij dergelijke applicaties zoveel threads als je cores hebt. HyperThreading heeft al laten zien dat je nog wat extra's kunt winnen door meer threads toe te voegen, maar echt spectaculair is dat niet.
Ik denk dan ook dat je bij dit soort applicaties weinig wint als je over de 8 threads heen gaat. Op een gegeven moment zijn de reken-eenheden gewoon verzadigd, en heeft het toevoegen van meer threads geen nut meer.

Kortom, het lijkt me geen geschikte processor voor rendering. Sneller dan een Intel quadcore zal ie waarschijnlijk niet zijn, afgaande op de specfp-scores.

Je snapt wel dat dit over een CPU gaat?

hij doelt op een complete wafer (ronde schijf ) van deze CPUs...

_{pssst ... hij maakt een grapje}

[Reactie gewijzigd door kalechinees op 3 augustus 2007 19:08]