IDF 2004 dag 3: Toekomstschets chiparchitectuur

IDF 2004 dag 3: Toekomstschets chiparchitectuur

Op de derde en laatste dag van IDF hield Intels Chief Technical Officer Patrick Gelsinger een presentatie over "The Era of Tera", waarin hij een nieuw tijdperk in de geschiedenis van computers aankondigde. In de historie van de pc is het altijd al zo geweest dat de snelheid en capaciteit van de hardware gestaag toenam, maar dat mensen zich om de zoveel jaar begonnen af te vragen waarom ze nòg snellere chips, of nòg meer geheugen en schijfruimte nodig zouden hebben. De bekende uitspraak "640K should be enough for anyone" wordt aangehaald, maar er zijn ook veel recentere voorbeelden van zulke momenten te noemen. In 1999 schreef Information Week bijvoorbeeld nog dat 400MHz genoeg zou zijn voor iedere toepassing.

Het blijft natuurlijk altijd moeilijk om te voorzien welke processorintensieve applicaties er in de toekomst voor zullen gaan zorgen dat mensen en bedrijven willen upgraden, maar "the best way to predict the future, is to invent it", aldus Gelsinger, die hiermee een bekende uitspraak van pc-pionier Alan Kay aanhaalt. Kay was onder andere verantwoordelijk voor de eerste Windows-achtige GUI en stond aan de wieg van object oriented programmeertalen. Volgens Intel kan de hele wereld beschouwd worden als data: ieder aspect van ons leven kan wel op een of andere manier in bytes worden uitgedrukt. Het probleem is alleen dat data verzamelen of vastleggen op zich nutteloos is zolang je er niets of weinig mee kunt doen, en Intel ziet de toekomst dus in RMS-applicaties: Recognition, Mining en Synthesis.

Recognition betekent letterlijk "herkenning", en daarbij kun je dus denken aan het herkennen van spraak voor de beveiliging of besturing van de computer, maar ook aan het zoeken naar verdachte figuren op (live) videobeelden of het vinden van afwijkingen in röntgenfoto's. Mining is het gebruiken van data uit verschillende bronnen, zoals een database met criminelen combineren met videoherkenning, statistieken uit iemands complete medische geschiedenis kunnen halen om betere diagnoses te kunnen stellen of het automatisch verzamelen van informatie over een onderwerp op internet. Synthesis staat voor het uitvoeren of weergeven van data op verschillende manieren. Fotorealistische beelden, animaties, natuurlijk klinkende spraak en automatisch gegeneerde documenten. Hoewel dit natuurlijk vrijwel allemaal dingen zijn waar vooral een berg slimme software voor nodig is, moeten toekomstige generaties hardware met dit soort applicaties in het achterhoofd worden ontworpen om het echt soepel te laten lopen.

Een voorbeeld dat wordt gegeven is graphics. De laatste jaren zijn videokaarten met sprongen vooruit gegaan, maar nog steeds is duidelijk zichtbaar dat realtime gerenderde beelden nep zijn. Dr. Philip Slusallek van inTrace legt uit dat dit een fundamenteel probleem is van de huidige aanpak. Een videokaart verwerkt één triangle per keer en er worden allerlei trucs gebruikt om te zorgen voor effecten als schaduw. Dit is misschien wel acceptabel voor spellen, maar een bekende autofabrikant baalde toch flink toen bleek dat het dashboard van het prototype bleek te reflecteren op de voorruit, iets wat de "tricks" van standaard rendermethodes niet hadden laten zien. inTrace ziet de toekomst liggen in raytracing, een techniek waarbij de fotons die door de scene vliegen gevolgd worden waardoor een extreem nauwkeurig en realistisch plaatje ontstaat inclusief natuurkundig verantwoorde schaduwen, spiegelingen en (indirecte) belichting.

Het nadeel van raytracen is dat het extreem langzaam is op de huidige hardware. Het bedrijf van Slusallek is volledig toegewijd aan het optimaliseren van de algoritmes, maar heeft nog steeds een cluster van 23 dual 2,2GHz Xeon-servers (400 gigaflops) nodig om een VW New Beetle een beperkte resolutie te kunnen renderen met een framerate die wij tussen de 10 en 20 schatten. Het voordeel is daarentegen dat de raytracer extreem goed schaalt. Ten eerste maakt het nauwelijks uit of er nou 1 miljoen of 1 miljard polygonen zichtbaar zijn in een bepaalde scene, terwijl een traditionele GPU eigenlijk alleen maar goed presteert als het aantal polygonen klein genoeg gehouden wordt. Ten tweede kan de raytracer iedere extra processor die wordt ingezet bijna voor de volle 100% benutten, waardoor de techniek zeker op het moment dat Intel meerdere cores per processor gaat leveren steeds aantrekkelijker wordt.

Het leveren van extra performance voor dit soort applicaties wordt een steeds grotere uitdaging. Kloksnelheid verhogen wordt een steeds groter probleem. Ten eerste vanwege het stroomverbruik, iets wat wel blijkt uit de TDP-waardes van Prescott (103 Watt) en Tejas (115 Watt). Ten tweede vanwege de immer groter wordende latency richting het geheugen: een 486 had nog maar 10 cycles nodig om iets uit het geheugen te halen, maar op een modern Pentium 4-systeem is dat al 220 cycles. Ook de snelheid waarop signalen zich verplaatsen binnen de chip is een beperkende factor geworden. Op 65nm duurt het al 15 cycles puur om iets van de ene naar de andere kant van de chip te krijgen. De meeste methodes om deze effecten te verbergen of compenseren zijn al afgekeken van mainframes, maar de ideeën uit die hoek zijn nu zo ongeveer op. Nu gaat men dus een hele andere kant op kijken; de HPC (high-performance computing) markt, parallellisme dus. HyperThreading was slechts een kleine stap in die richting, in de toekomst gaat alles "multi" worden: cores, geheugens, bussen, caches, noem maar op.

Er is een prototype compiler ontwikkeld om plaatsen in de code waar geheugenlatency een probleem wordt te herkennen en op die plaatsen helper threads aan te maken die data alvast beginnen te cachen. Er is weinig extra complexiteit in de hardware nodig, maar een demonstratie van IBM DB2 op een sample van een toekomstige Itanium laat een performancewinst van 10% zien. Het aantal keren dat er voor het doorzoeken van de enorme database naar het geheugen gegrepen moest worden omdat iets niet in het cache stond was bijna gehalveerd van 411 naar 214 miljoen keer dankzij de helper threads, en er is nog ruimte voor verbetering aangezien de techniek zich nog in het beta-stadium bevindt.

De architectuur zal zich op meerdere manieren moeten kunnen aanpassen aan het soort applicatie dat erop gedraaid wordt. Op chip-niveau kan dat gerealiseerd worden met behulp van Adaptive Body Biasing. Door extra stroom op een transistor te zetten kan hij (tijdelijk) even snel schakelen als een transistor van de volgende generatie ten koste van meer hitte. Andersom is echter ook mogelijk: lekstromen - tegenwoordig verantwoordelijk voor 30 tot 40% van het totale opgenomen vermogen - kunnen met Reverse Body Biasing (tijdelijk) tegengehouden worden ten koste van performance. Ook heeft men chips waarvan de elementen op meerdere manieren met elkaar verbonden kunnen worden om verschillende functionaliteiten te realiseren. Zo heeft men een gecombineerde 802.11b/a/g en GPRS-chip gemaakt die twee keer kleiner en zuiniger is dan de concurrentie, en ook hier ging het nog om een vroege, niet geoptimaliseerde, versie.

Ook op hoger niveau valt er nog genoeg te optimaliseren, zodat er een maximaal aantal CPU-cycles beschikbaar is voor applicaties van de gebruiker. Iets als het verwerken van TCP/IP-pakketten is bijvoorbeeld een noodzakelijk kwaad, eigenlijk zou zoiets gewoon moeten werken zonder dat het processortijd opeet. Er zijn wel hardwarematige TCP/IP-engines beschikbaar, maar die pakken de echte problemen niet aan, want van de 2100 cycles die een gemiddeld pakket in beslag neemt is maar 22% daadwerkelijk TCP/IP-verwerking. 23% van de cycles gaat verloren aan geheugentoegang en maar liefst 58% is overhead van het OS. Samen met de eerder beschreven helper threads kan Direct Cache Access (een afgeleide van Direct Memory Access - DMA) en een geoptimaliseerde stack de performance met wel tien keer verhogen.

Omdat dit soort dingen natuurlijk wel per toepassing verschilt zal het belangrijk worden om hardware en software op elkaar te laten inspelen. Niet alleen moet de software een bepaalde architectuur kunnen herkennen om optimaal gebruik te maken van de mogelijkheden, maar het moet ook mogelijk worden voor software om zijn wensen op het gebied van performance naar de hardware te sturen, zodat zaken als processorcores, caches en bussen dynamisch geconfigureerd kunnen worden.

IDF reportages

>>

>>

>>

>>

>>

>>

Wo 22:24 - We vervolgen onze verslaggeving van het IDF met reportages over nieuwe koeloplossingen voor de Pentium 4, demonstraties van 2,5 inch Serial Attached SCSI-schijven en foto's van de XDR DRAM-technologie van Rambus.

>>

>>

>>

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (14)

Hmmmz vooral dat ray tracing lijkt mij uber-interessant, ook in grote mate voor verwoede gamers zoals ik
Stel je eens voor spellen zoals halflife 6 in een volledig virtuele wereld te kunnen spelen waar je dingen zou kunnen aanraken en ruiken en noem maar op..... maar oke nogal vergezocht mss en niet helemaal ontopic.

Het is dan alleen vreselijk jammer om te horen dat er een klein "leger" aan Xeon procs voor nodig is om iets vrij simpels te renderen en dan nog loopt het voor geen meter.
Dan kun je al raden dat dit toch ver vooruit in de toekomst ingevoerd gaat worden

Maar ik vind het nu toch wel frapant te lezen dat er in de toekomst nog hopen cache multibussen en weet ik niet wat ingevoerd gaan worden terwijl sommige mensen Intel nu afbranden vanwege de grotere cache...zo zie je maar

Die hogere cache is >>op dit moment<< niet nodig, er zijn nl. amper verschillen tussen de Northwood en de Prescott en tussen de Newcastle en de Clawhammer. In de toekomst zullen we uiteraard meer nodig hebben (dat is bij alles zo) maar dat duurt nog wel ff.

23 dual 2,2GHz Xeon-servers (400 gigaflops)

23x2.2GHz=50.6Ghz Dus voor 400 GFlops zou een xeon 8 flop per klok doen? ik geloof er niets van.
/edit: oja, dual... maar dan nog..

Waarom niet? Die algoritmes zijn natuurlijk zwaar geoptimaliseerd voor SSE. De tweede S van die afkorting staat voor SIMD, wat weer staat voor Single Instruction, Multiple Data. Oftewel dezelfde handeling op meerdere registers tegelijk uitvoeren. De Pentium 4 / Xeon haalt dan wel geen vier instructies per kloktik, maar op deze manier kom je best aan vier fp-operations per kloktik.

Ergens is dit een mooi artikel, maar de meeste mensen voelen dit zelf ook aan.

Zeker hier op Tweakers is het verschijnsel van de hogere latencies wel bekend volgens mij.

Overigens denk ik dat het misschien wel eens goed zou zijn als de hardware ontwikkelingen een paar jaar stil zouden staan. En dan bedoel ik niet dat dit goed is voor de ontwikkelingen op zich.
Het zou wel ontzettend positief invloed hebben om de software-technische ontwikkelingen. De Hardware is echt razendsnel, maar veel processen en codes/scripts zijn nog verre van optimaal als je het mij vraagt. En hoewel ik liever lui dan moe ben en daarom voor een economische en niet technische studie gekozen heb lijkt het me wel een geweldige uitdaging om eens actief te werken aan het optimaliseren van programma-codes.
Ik zeg niet dat er oneindig veel winst is te halen op dit gebied, maar er is nog ruimte over.
Als je bijvoorbeeld kijkt wat men toch nog uit een Playstation 1 wist te persen aan het einde van haar bestaan dan is dat toch opvallend en prettig te noemen.

paar jar geleden sprak ik al regelmatig met iemand die een game aan het programmeren was met een raytracing engine..

Het gaat hier om gigaflops, dit is heel wat anders dan teraflops waar ze hier over praten: http://www.tweakers.net/nieuws/31259
1 miljard keer zo weinig als ik het goed heb?


1 2,2GHz Xeon levert dus inderdaad 4 gigaflops op

Nee, het verschil tussen giga en tera is een factor 1000 of 1024.

In 1999 schreef Information Week bijvoorbeeld nog dat 400MHz genoeg zou zijn voor iedere toepassing.

Binnenkort zullen de eerste HDTV-Divx rips komen, dan zul je toch wel een 1ghz proc nodig hebben om die films op 1920 * 1200 @ 60fps af te kunnen spelen..

Voor gewone DivX heb je dat al nodig, voor HDTV zul je dus iets in de richting van 2000/2500+ nodig hebben.

Misschien een beetje een n00b vraag maar wat bedoelen ze met object georienteerde programmeertaal? wat moet ik me daarbij voorstellen?

Je kan gewoon een reeks instructies onder mekaar zetten, die dan worden uitgevoerd.

Maar je kan ook een "verzameling" van functies maken, die je dan kan hergebruiken op andere plekken. Zodoende is het makkelijker om code uit te breiden en het overzicht erin te houden.

Gesnapt?

Een interessante samenvatting

Typo in 1 na laatste paragraaf:

Er zijn wel hardwarematige TCP/IP-engines beschikbaar, maar die pakket de echte problemen niet aan,

leuk rekenen 22% + 23% + 58% = ....