Ars Technica bespreekt Power5, UltraSparc IV en Efficeon

Op Ars Technica is een verhaal verschenen over drie processors waar op het Microprocessor Forum van vorige maand veel informatie naar buiten is gebracht, te weten: IBM Power5, Sun UltraSparc IV en Transmeta Efficeon. Naast het bespreken van de technische aspecten wil de schrijver ook een bepaalde rode draad blootleggen over de industrie in het algemeen.

IBM Power5

De meest interessante nieuwe onthulling de op het MPF werd gedaan over de Power5 is dat deze chip een geavanceerde implementatie van SMT bevat, waarmee ten koste van 24% meer transistors significant betere prestaties behaald zouden worden. Anders dan bij x86 is de Power-architectuur gebaseerd op groepen van vijf instructies, en Power5 wordt de eerste generatie die twee van deze bundels tegelijk uit zijn L1-cache kan trekken. Door interne beperkingen kunnen er alsnog maar vijf operaties tegelijk uitgevoerd worden, maar omdat de processor nu dubbel zoveel opdrachten achter de hand heeft om zijn rekeneenheden mee bezig te houden, kunnen de prestaties met wel 40% toenemen. Een andere reden waarom er meer verwacht wordt van deze vorm van SMT dan van Intel's HyperThreading, is het feit dat IBM operating systemen de mogelijkheid geeft om invloed uit te oefenen op de werking van de feature, door threads prioriteiten toe te wijzen of zelfs het multithreading tijdelijk uit te schakelen, zodat alle rekenkracht voor één thread beschikbaar is.

Sun UltraSparc IV

Sun pakt het iets minder subtiel aan plakt gewoon twee UltraSparc III-cores naast elkaar in een chip die op het bestaande socket past. Hoewel processors met meerdere cores al geruime tijd geleverd worden door IBM en HP, en deze zet dus vanuit het standpunt van de chipontwerper een stuk minder vernuftig of vernieuwend is, wil dat niet zeggen dat de aanpak niet werkt. Vooral omdat Sun zowel de hardware als het OS en de applicaties levert, heeft het bedrijf de mogelijkheid om maximaal te optimaliseren voor de gekozen route.

Transmeta Efficeon

Transmeta heeft met Efficieon het basisconcept van de Crusoë verder uitgewerkt. De chip is qua architectuur simpel gehouden door zo veel complexiteit naar de code-morphing software te verplaatsen. Hoewel het idee op zich leuk is en het ook gelukt is om een product neer te zetten dat in ieder geval op sommige gebieden kan concurreren met Intel Centrino, worden er grote vraagtekens gezet bij de toekomst van deze aanpak. De code-morphing software zelf gebruikt immers ook de nodige rekenkracht. Hoe meer optimalisaties nodig zijn, hoe meer de processor zichzelf bezig moet houden met een bijtaak waar andere chips gewoon aparte circuits voor hebben. Zeker omdat de snelheid en zuinigheid van een chip tegenwoordig meer afhankelijk zijn van de productietechnologie dan van de architectuur, vraagt de schrijver zich af of het wel de moeite waard is om het wiel opnieuw uit te vinden.

De overeenkomst tussen deze drie chips is dat ze hun rekenkracht ieder op hun eigen manier zo goed mogelijk proberen gebruiken. Van de drie stappen die iedere chip volgt (data ophalen, iets ermee doen, data wegschrijven), is het gedeelte dat "iets doet" al vele jaren het makkelijkste om te bouwen. Het wegschrijven is weliswaar relatief traag, maar omdat daar meestal niet op gewacht hoeft te worden is dat niet zo'n probleem voor de performance. De latency bij het ophalen van data is dat echter wel, en een groeiend ook. De creatieve oplossingen die bedacht worden om ervoor te zorgen dat de processor toch genoeg werk heeft, zullen steeds meer tekenend zijn voor toekomstige generaties hardware en software:

I think that all three of the architectures I mentioned above illustrate in one way or another the ways in which increasing load latencies affect the entire hardware-software ecosystem, from the motherboard and CPU all the way up to the OS and end-user applications. I suppose that on some level, this is perhaps an obvious and almost trivial observation, but it's still remarkable to me just how these effects are working themselves out. And this is happening at all levels of system design as more and more devices get more and more connected while feature sizes continue to shrink. Latency matters at the level of the network, at the level of microprocessor layout due to wire delay, and at every level in between.

Reacties (12)

[silentsnow]

"... en Power5 wordt de eerste generatie die twee van deze bundels tegelijk uit zijn L1-cache kan trekken. Door interne beperkingen kunnen er alsnog maar vijf operaties tegelijk uitgevoerd worden ..."

In het bronartikel staat een quote waarin staat dat de Power5 juist twee groepen per clock cycle kan uitvoeren. De schrijven weerlegt dit later weer door te beweren dat de acht execution units logischerwijs maximaal acht instructies per clock cycle kunnen uitvoeren. Maar dit gaat uit van groepen met vijf instructies. Kortom, de Power5 kan wel bijvoorbeeld twee groepen met elk vier instructies in een enkele clock cycle uitvoeren. SMT dus, maar alleen in een select aantal gevallen.

zelfs het multithreading tijdelijk uit te schakelen, zodat alle rekenkracht voor één thread beschikbaar is.

Erg handig, maar ik vraag mij af hoe de soft/hardware beslist of SMT aan of uit moet. Ik vraag mij af of het wel efficient is om SMT uit te doen als de processor slechts één thread, of een serie enkele threads, uit gaat voeren. Er zijn namelijk applicaties die beter presteren zonder SMT, maar er zijn ook single threads die de processor sneller kan verwerken met SMT aan. Dit haal ik overigens uit deze quote:

Some of the things that we’ve done for SMT even have benefits for what we call single threaded mode. Our enhancements to make SMT work improved the performance of single threads for applications like platform computing

bron

Zoals we de laatste tijd meer zien lijkt het erop dat we de komende steeds meer en beter ontwikkelde multi-threaded en multiprocessing gaan zien. Het lijkt mij een relatief makkelijke manier om de processorkracht te verhogen, want je kan oude processor architecturen gebruiken als basis. Daarnaast is een extra processor core per chip natuurlijk ook een makkelijke manier om meer kracht uit een chip te halen.

[Verwijderd]

In het bronartikel staat een quote waarin staat dat de Power5 juist twee groepen per clock cycle kan uitvoeren. De schrijven weerlegt dit later weer door te beweren dat de acht execution units logischerwijs maximaal acht instructies per clock cycle kunnen uitvoeren. Maar dit gaat uit van groepen met vijf instructies. Kortom, de Power5 kan wel bijvoorbeeld twee groepen met elk vier instructies in een enkele clock cycle uitvoeren. SMT dus, maar alleen in een select aantal gevallen.

die "twee groepen per cycle" zitten in het fetch frontend. vergeet niet dat SMT een techniek is waardoor de executionunits minder "stallen" door geheugenlatency. door 2 groepen per cycle te fetchen worden de executionresources (units en renameregisters) beter benut.

de zgn. "utilizationrate" wordt verhoogd. de verbeterde utilizationrate zorgt ervoor dat de processor dichter bij de 5 way superscalar limiet komt.

Erg handig, maar ik vraag mij af hoe de soft/hardware beslist of SMT aan of uit moet. Ik vraag mij af of het wel efficient is om SMT uit te doen als de processor slechts één thread, of een serie enkele threads, uit gaat voeren. Er zijn namelijk applicaties die beter presteren zonder SMT, maar er zijn ook single threads die de processor sneller kan verwerken met SMT aan. Dit haal ik overigens uit deze quote:

"""Some of the things that we’ve done for SMT even have benefits for what we call single threaded mode. Our enhancements to make SMT work improved the performance of single threads for applications like platform computing"""

ik denk dat je de oorspronkelijk quote verkeert interpreteert. wat bedoelt wordt imho is dat, afgezien van SMT technieken, de core verder verbetert is. ik kan me voorstellen dat er meer renameregisters zijn toegevoegd waardoor de performance ook met SMT effectief uitgeschakeld (single threading mode) beter is dan de POWER4

[miw]

Interessant commentaar. Toch vind ik het vreemd om SMT of virtuele SMT aan te duiden als een oplossing voor de "Von Neuman bottleneck".

Er zijn bij SMT namelijk meerdere executie units die dezelfde datapaden naar het geheugen gebruiken. ALs die allemaal instructies uitvoeren, moet er meer data door die bottleneck. De winst van SMT zit dus ergens anders!

Latency is op zich ook geen probleem, want een flink diepe pipeline kan ervoor zorgen dat een processor voldoende werk heeft tijdens de instructie fetch latency. De winst van SMT zit dus ergens anders!

Het probleem dat processor ontwerpers moeten zien op te lossen is dat een processor te maken heeft met een tamelijk onvoorspelbare aanvoer van instructies. Conditionele instructies en sprong instructies zorgen voor een onvoorspelbare volgorde van instructies. Caches zorgen voor een onvoorspelbare aanvoer van instructies en data, omdat je niet weet waar de geheugeninhoud vandaan moet komen (variabele latency). Het resultaat van al deze onvoorspelbaarheid is dat zowel de processor als de geheugen bandbreedte niet efficient benut worden. Vandaar dat je allerlei technieken ziet opduiken om de efficientie van het gebruik van de processor en van de geheugenbandbreedte te verbeteren.

[Verwijderd]

Ik zou graag eens met een transmeta cpu spelen,om te zien wat de prestaties zijn,en wat het allemaal aan kan.Ik lees de berichten ivm transmeta altijd en ben blij dat er nog andere fabrikanten zijn,die het niet zo op snelheid hebben gezien,maar op een mengeling van snelheid en verbruik.

[mjl]

Leuk om te lezen dat je processor relatief niks te doen heeft omdat de data aan en afvoer te traag is |-(

De chipbakkers moeten dus meer en snellere cache ontwerpen. Iets wat je bij intel ook al ziet (wat was dat nou 12-24 MB L3 cache..... helemaal van de gekke als je nog een PIII celeron hebt liggen met 128/256 kb ....).

[Verwijderd]

Die drie stappen heet de 'Neumann cyclus' .

Een processor heeft gewoon een optimale groote voor cache geheugen (hetzij L1,L2 etc). Is het te klein dan kost dat performance en is het te groot dan kost het geld.
En als je met SMT en multicore's meer bewerkingen kan uitvoeren heb je logischerwijze meer cache nodig. En aangezien de CPU 98% in de cache zit te rommelen wil je dat percentage wel zo hoog mogelijk houden.

Maar over dat Transmeta concept. Dat dit achterhaald zou zijn ben ik het niet mee eens eigenlijk. Want hun concept kan ook op die Power5 worden toegepast bijv. Want als je delen van je cores uit kan zetten omdat het toch even niet nodig is lijkt me handig en als hij het dan met code morphing af kan maar nog snel genoeg scheelt dat heel veel qua stroomverbruik en dus warmteontwikkeling. Dus heeft het voor mobile CPU's wel zeker een toekomst.

En de toekomst van multi cores en cache geheugen zal altijd nog wel een afweging blijven van hoeveel cache je voor hoeveel cores nodig hebt. En die ratio is bij de Power5 al 2:1 terwijl dat bij de Intel PIV's ongeveer 1:1 is. En er is dus duidelijk een verschuiving naar meer cache geheugen nodig wat weer duidt dat die bottleneck toch het geheugen is.
Wat vervolgens weer betekend dat je een optimaal aantal cores per CPU kan hebben omdat die allemaal ook gevoed moeten worden met instructies.
En hierdoor wordt de rol van de MMU ook nog veel belangrijker en ook die van de compiler. En al die logische units op de CPU moeten wel optimaal getweaked kunnen worden.
Dat zal nog wel even duren dunkt me eer ze daar het optimum uit weten te halen.

[Beaves]

Want hun concept kan ook op die Power5 worden toegepast bijv. Want als je delen van je cores uit kan zetten omdat het toch even niet nodig is lijkt me handig

Elke moderne CPU kan delen van zijn core op een lager pitje zetten zodat er minder energie verbuikt wordt en CPU's zoals de Pentium-M (de CPU die bij het Centrino platform gebruikt wordt) kan al delen van zijn CPU uitschakelen die toch niet gebruikt worden. Het uit en weer aanzetten gaat met een erg lagere latencie waardoor de gebruiker daar niets van merkt.

Desktop CPU's zoals de P4 en de Athlon hebben zelf ook mechanismen om delen uit te zetten en dat scheelt best veel als daarvan gebruik wordt gemaakt. De temperatuur kan zo 10 graden lager worden. Ook het weer aan zetten gaat zo snel dat je het niet merkt.

Voor die technieken heb je dus geen code morphing voor nodig.

Ik ben het overigens met je eens dat de Transmeta CPU absoluut geen gek figuur slaat, de CPU verbruikt erg weinig en uit testen (wel door Transmeta uitgevoerd) blijkt dat de Efficeon goed mee kan komen als de Pentium-M en de Efficeon evenveel warmte afstoten. Ze hebben de Pentium-M en de Efficeon allebei zo geconfigureerd dat ze 7 W afstoten en toen bleek de Efficeon erg goed mee te kunnen komen kwa prestaties.

Niet gek als je naar de feature's kijkt, ze hebben net zoals de Hammers van AMD een geintegreerde memory controller en daarnaast nog 1MB aan L2 cache.

edit:

Zeg ik ergens dat de Pentium-M de eerste is met de mogelijkheid om delen uit te zetten? Dat er andere zijn die hetzelfde kunnen is logisch, zo speciaal is het niet, ik wil alleen maar aangeven dat die feature niet alleen door Transmeta gebruikt wordt.

[Metal Baron]

Dat 'kunstje' van de centrino is overigens ook al uit, de eerste geeneraties G3 van motorola konden dit ook al.

Ik ben wel benieuwd van de PPC980, de desktop versie van de power5 die in de toekomst in macs gaat verschijnen, gaat doen. De prestatieverbetering zou enorm zijn.

[miw]

En hierdoor wordt de rol van de MMU ook nog veel belangrijker en ook die van de compiler.

Goede observatie. Het blijkt dat de invloed van compilers toch nog behoorlijk onderbelicht is. In een benchmark met een spraakherkenningstest (http://www.techreport.com...huttle-sn45g/index.x?pg=9) waar twee verschillende compilers gebruikt werden, kwamen verschillen van zo'n 4% aan het licht. Het interessante aspect is dat die verschillen tegengesteld waren voor AMD en Intel P4 (de Intel compiler produceert code die sneller draait op een AMD :-)).

[Parody]

Dit is al jaren zo, eigenlijk, en het wordt alleen maar erger omdat de snelheid van de processor t.o.v. het geheugen steeds schever gaat liggen. Meer cache is leuk, maar alleen daarmee kom je er niet. Je moet (1) die cache vullen, wat tijd kost, (2) een cache is altijd te klein, en (3) een grote cache heeft een hogere latency. Daarnaast is cache erg duur omdat het vreselijk veel chipoppervlak vreet.

De kunst is om de execution units bezig te houden terwijl er gewacht wordt op het langzame geheugen. De grenzen van out-of-order en speculative execution zijn wel zo'n beetje bereikt. Met SMT / hyperthreading kun je (met de hulp van je OS) weer een stuk verder komen. Met 10 threads op de wachtlijst is er eigenlijk altijd wel 1 die wel iets zinnigs kan doen in de wachttijd...

[styno]

Het is inderdaad zo dat een paar jaar lang het geheugen een enorme bottleneck vormde voor de CPU. De multiplier is een duidelijke indicator voor het verschil in processor frequentie en geheugen.

De laatste tijd is de ontwikkeling weer sneller gegaan door bijvoorbeeld dual channel DDR geheugen te gebruiken in combinatie met een enorm hoge FSB (bijv. 800 MHz) Hierdoor is het verschil in frequentie (multiplier) weer behoorlijk omlaag gegaan.

[dj.verhulst]

.