Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 24 reacties
Bron: AnandTech

AnandTech heeft een artikel gepubliceerd waarin de onlangs geïntroduceerde Sun UltraSparc T1-processor, beter bekend onder de naam 'Niagara', onder de loep wordt genomen. Deze nieuwe processor omschrijft de auteur van AnandTech als 'net iets minder dan een revolutie' aangezien de processor in staat is om op een kloksnelheid van 1,2GHz en met een stroomverbruik van 72 Watt prestaties neer te zetten die drie keer zo hoog zijn als vier Xeon-cores op een kloksnelheid van 2,8GHz en een energieconsumptie van 300W. Uiteraard zitten er wat haken en ogen aan de Sun-processor, aangezien deze topprestaties alleen bij een beperkt aantal specifieke toepassingen worden behaald en in bovengenoemd voorbeeld is dit SpecWeb2005.

Sun Fire T2000 (klein)De Sun UltraSparc T1 is geoptimaliseerd voor 'commerciële servers', waarmee met name webservers worden bedoeld. Deze systemen stellen in vergelijking met desktopsystemen of servers die worden gebruikt voor rekenintensieve toepassingen, duidelijk andere eisen aan de processor. Zo is de tijd dat de processor wordt belast op webservers aanzienlijk lager dan het geval is bij bijvoorbeeld een processor die een video aan het encoderen is. De voornaamste tijdbesteding van dergelijke servers bestaat namelijk uit het verplaatsen van data en het zogenaamde 'context switching' wat nodig is wanneer er van een thread wordt gewisseld. Precies op deze twee punten hebben de Sun-ingenieurs geprobeerd de T1-processor te laten schitteren.

De UltraSparc T1 beschikt over acht cores die allemaal vier threads tegelijk 'in leven kunnen houden' - in totaal dus 32 threads voor de hele processor. Alle acht de cores beschikken over 640 64-bit registers (5,7KB) waarin ze de gegevens van de vier threads kunnen opslaan. Deze relatief grote hoeveelheid registers kunnen in één klokcycle worden benaderd. Elke core heeft één pipeline die elke klokcycle een instructie verwerkt van één van de vier threads waar de core aan werkt. Elke kloktik wordt er aan een andere thread 'gewerkt' dan bij de vorige kloktik het geval was volgens een round-robin schema. Dit is een aanzienlijk andere situatie dan bij de huidige gangbare processors het geval is, aangezien het veranderen van een thread daarbij een zogenaamde contextswitch tot gevolg heeft, waarbij de registers van de oude thread moeten worden bewaard in het (cache)geheugen en de registers van de nieuwe thread moeten worden geladen. Zo'n contextswitch kost meerdere kloktikken, wat dus een aanzienlijk snelheidsverlies betekent in vergelijking met de Niagara.

Sun UltraSparc T1 'Niagara' schema

Een voordeel van deze aanpak is dat wanneer één thread gegevens uit het geheugen wil laden, de Niagara dit kan doen zonder dat hiervoor de processor moet wachten tot het laden gereed is. Ondertussen kan hij namelijk gewoon werken aan de overgebleven drie threads, en de thread die gegevens wil laden 'overslaan'. Bij branches geldt precies hetzelfde; de Niagara heeft dan ook geen branch prediction aan boord, zoals de meeste andere gangbare processors. Om ervoor te zorgen dat de processorcores bezig blijven, is de Niagara uitgerust met 3MB L2-cache die wordt gedeeld tussen de acht cores. De toegang tot het werkgeheugen gebeurt via vier DDR-geheugencontrollers. De communicatie tussen de cores en het L2-cachegeheugen gebeurt via een high-speed cross-bar interconnect.

Nadelen heeft het ontwerp van de UltraSparc T1 uiteraard ook. Zo is door het 'eenvoudige' ontwerp de kloksnelheid beperkt tot 1,2GHz op 90nm, terwijl de concurrentie op kloksnelheden tussen 2 en 3GHz zit. De acht cores moeten slechts één Floating Point Unit (FPU) delen, waardoor de prestaties van de processor drastisch afnemen als meer dan één procent van de instructies uit floating-point-instructies bestaan. Ook beschikt elke core over een Modular Arithmetic Unit (MAU) die delingen en machtsverheffingen verwerken om de verwerking van SSL-encryptie te versnellen. De prestaties op dit gebied blijft ondanks deze MAU achter bij de concurrentie. AnandTech heeft geen eigen benchmarks gedraaid op de UltraSparc T1 processors en heeft daarom alleen de benchmarkresultaten die zijn vrijgegeven om de snelheid van het systeem te beoordelen. Ook gaat het artikel nog in op de virtualisatie in combinatie met de UltraSparc T1 en over de opvolger van de processor, de Niagara 2.

Moderatie-faq Wijzig weergave

Reacties (24)

Het is niet alleen het afwezig zijn van complexiteit dat zorgt voor een begrenzing bij 1.2GHz. Simpelere chips zouden namelijk juist sneller kunnen schakelen. Het probleem zit hem veel meer in het als maar groter wordende oppervlak van de chip en de lengte van de crossbar interconnects voor 8 cores. Wil je over die lange interconnects binnen 1 cycle communiceren dan leidt dat tot een langere cycle time en dus lagere maximaal haalbare klokfreqentie. Het oppervlak van de interconnect neemt kwadratiesch toe met het aantal cores, de register file area zelfs tot de derde macht. Daarom is dit ontwerp (voor deze specifieke applicatie) ook veel slimmer dan bijvoorbeeld 32 cores met elke 1 thread.

Reactie op RuLor:
Ook als je in meerdere cycles via de cross bar communiceert (wat hier ook best het geval zou kunnen zijn) dan nog heb je schalingsproblemen bij steeds meer cores die je niet oplost met bijvoorbeeld de complexiteit van een pipeline. Deze cores kunnen trouwens net zo goed een pipeline hebben. Het is juist de specifieke toepassing van redelijk onafhankelijke threads op een web server die de complexe instruction cache logic overbodig maakt. Maar het is niet zo dat als je die toevoegd dat de klokfrequentie dan automatisch omhoog zou kunnen. En een pipeline verhoogt in eerste instantie het aantal instructies per clock cycle en niet de cycle frequentie.
Het is niet alleen het afwezig zijn van complexiteit dat zorgt voor een begrenzing bij 1.2GHz. Simpelere chips zouden namelijk juist sneller kunnen schakelen.
Een CPU met meer pipelines (en dus een complexere cpu) clockt sneller dan een met weinig pipelines.

En in de rest van je verhaal beschrijf je hoe alles zo brak loopt als je vanalles in 1 cycle probeert te doen.
Vandaar dat je de boel in stukjes "knipt" en meerdere cycles gebruikt, en daar wordt de chip toch echt een stukje complexer van.
Het enige wat 'ie zegt is dat het formaat van de chip ervoor zorgt dat communicatie niet meer binnen 1 klokcycle zou kunnen plaatsvinden wanneer de klokfrequentie opgeschroeft zou worden.
In het artikel geven ze aan dat er extreem veel registers zijn en dat de CPU erg goed in staat is om verschillende threads netjes om-en-om uit te voeren.
Ik (en waarschijnlijk delaregulus ook) vermoed dat die verschillende threads allemaal bij diezelfde verzameling registers kunnen. (waarschijnlijk door het OS of een ander mechanisme afgeschermd ivm veiligheid) Om het een beetje fatsoenlijk met een round-robin scheduler te kunnen omschakelen kan het volgens mij voorkomen dat je thread telkens door een andere core behandeld wordt en dus is de (maximale) afstand tot die registers zeker een rol die meespeelt.

Het opdelen van je code in kleine stukjes hoeft niet te leiden tot een complexere processor, want dat zou je de compiler ook kunnen laten doen.
Het enige wat 'ie zegt is dat het formaat van de chip ervoor zorgt dat communicatie niet meer binnen 1 klokcycle zou kunnen plaatsvinden wanneer de klokfrequentie opgeschroeft zou worden.
hij zegt toch duidelijk dat een simpelere cpu sneller kan schakelen.
Het opdelen van je code in kleine stukjes hoeft niet te leiden tot een complexere processor, want dat zou je de compiler ook kunnen laten doen.
Een compiler die het aantal pipeline stages van een cpu kan verhogen heb ik nog nooit gezien.
Eigenlijk doet Anandtech niets anders dan de perspublicatie van Sun herhalen. Op zich wel jammer want juist van zo'n nieuw processor ontwerp is een echte review interessant. In ieder geval een stuk meer dan dat we zodra AMD of Intel een chip 100 MHz sneller maken overspoelt worden met Doom3 benchmarks.
Hoe goed zou zoiets zijn in terminal server werk? Ben met een project bezig met Linux terminal servers.(details moeten nog uitgewerkt worden)
Edit: In een portacabin met zonnepanelen, voor de duidelijkheid;).
Edit 2: Ik zie het al, dit is bepaald geen budget proc.
Edit @benoni:
Het gaat om grafische thin-clients (NX waarschijnlijk) waar dingen als Firefox en OpenOffice op zullen draaien. Maar het lijkt me dat een proc die erg veel threads aankan als deze daar inderdaad wel voor geschikt is.. Staat op het lijstje :).
Systemen van ¤ 2000,- of meer lijken mij niet echt geschikt als Thin Client. :)
Ik gok dat hij hem wil inzetten als CPU in de server, niet in de client.
Ligt volgens mij ook aan de aard van de programma's die vanuit de terminals het meest worden gebruikt.
Wat in ieder geval beter werkt is dat je als je server onder piekbelasting staat te puffen, je toch lekker snel een sessie kunt openen om bv. de uit de hand gelopen processen te kunnen afbreken. Bij een single processor server heb ik wel eens gehad dat het minutenlang duurde voordat ik een ssh-verbinding kreeg.
Heb je al gekeken naar de Sun Ray ultra-thin client?
Heb een demo gezien op de Linuxworld in Utrecht, afgelopen November. Was erg onder de indruk. Weet alleen niet of het geschikt is voor budget toepassingen want de server voor thin clients *moet* een Sun zijn, e.d.
De clients zelf zijn enorm simpel maar wel grafisch sterk genoeg voor window managers en -toepassingen...
zeggus, dit is toch al redelijk oud nieuws? die nieuwe proc is er al bijna, en daar ze daarin het FloatingPoint probleem hebben opgelost en de clock wat omhoogdraaien is dat volgens mij een veel interesanter processor...
Als alles goed gaat zou Sun deze Niagara II in 2007 op de markt willen zetten.
Meer dan een jaar is niet bijna... Das nog een eeuwigheid in dit wereldje...
Er is geen floating point probleem, de floating point prestaties zijn laag maar die zijn ook niet nodig voor een processor die voor webservers bedoeld is.
Quote: "Zo is door het 'eenvoudige' ontwerp de kloksnelheid beperkt tot 1,2GHz "

Is het bij een eenvoudiger ontwerp juist niet eenvoudiger om de clocksnelheid hoog te krijgen? Zeer simpele circuits kunnen immers clocksnelheden halen die complexe processors niet kunnen evenaren.
De 'eenvoud' zit hem in de zeer brede parallele verwerking van alles. En het nadeel daarvan is dat dit niet zomaar heel snel omhoog te schalen is.
mooie benadering voor commercieele toepassingen.
webserver databases hebben niet zo veel aan veel FPU.

ik ben bezig met een project met php/mysql en heb geen enkele floating point in mijn 1000 regels en 20 db tabellen

voor wetenschappelijk onderzoek is dit apparaat wel uitgesloten.
Misschien niet in reken-intensief onderzoek, maar er is natuurlijk ook genoeg onderzoek in de informatica of robotica waar een dergelijke processor geschikt voor is. Maar het is wel duidelijk dat de doelgroep web/mail-servers zijn.
Deze processor kan echt een revolutie betekenen. De keuze om de dure contextwissels, branch predictors etc er uit te gooien en over te schakelen op een round-robin systeem is echt brillant. Ik wou dat ik het bedacht heb.

De snelheid van een enkele core, of single proc benchmark is inderdaad niet zo goed. Zelfs gerelateerd aan de kloksnelheid en de instructiecomplexiteit zal een single programma daarom minder snel draaien dan een willekeurige andere processor. Maar in plaats van dat op te lossen door de complexiteit te verhogen, wordt dit "opgelost" door meerdere threads tegelijk te draaien.

Deze processoren zijn uitermate geschikt als webserver, databaseserver en terminalservers.
Een mooie Linux distributie er op, en ik voorspel een prachtige toekomst voor "LAMP on Niagara" in 2006!

Tweede voorspelling voor 2006:
google vervangt zijn serverpark van 15000 pc's door 1000 Sun servers.

En wat betreft de slechte FPU snelheid:
De opvolger krijgt wel een FPU per core. Lijkt mij niet nodig. Een simpele fp ADD, MUL en MUL+ADD per core en voor de rest van de FPU instructies een gedeelde FPU unit lijkt me voldoende voor de meeste applicaties.
15000?
Zet daar maar een '0' achter! OK, het zijn er eerder 100,000, maar da's in ieder geval een orde groter dan wat jij zegt. Tenzij je het over een server hebt ipv een PC in de grote google index. ;)
Dat meer mhz-en ook meer prestaties neerzetten is al jaren geleden weerlegd toen AMD met hun Athlons kwam.
Terwijl Intell de kloksnelheid alsmaar omhoog gooide,kwam AMD met een processor die op 60%van de intell kloksnelheid liep,maar beter presteerde......
En dat is nu nog steeds.
Het ligt natuurlijk aan welke programma's gedraaid worden.
Daar sommige programma's speciaal voor een bepaalde chip of chipset zijn geoptimaliseerd.
Ikzelf heb pas 7 jaar geleden me Atari 68050 (op 50Mhz)aan de kant gezet voor de PC....
Als ik echter in Cubase met muziek werk is de Atari vele malen sneller als me Athlon 2Ghz.
Het ligt er maar net aan voor welke toepassing een GPU gebouwd is
En dat is met die nieuwe Sun net zo......
Lang leve de vooruitgang en concurrentie waardoor nieuwe technieken betaalbaarder worden.
Fijne jaarwisseling GOT
als je de processor naam iets te snel leest krijg je
Sun Viaga processor :) erg hilarisch (waarschijnlijk een freudiaanse verlezing?)
Bij een freudiaanse verlezing zou je misschien eerder Gun Viagra lezen ;)
Is die niagara server nog niet te koop? want Ik vind dat anand zich er wel erg makkelijk afmaakt. Had graag een wat uitgebreider artikel gelezen. Dit was slechts een rehash van reeds bekende info, weinig toegeboegde waarde.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True