Toekomstvisie Intel: many-core en virtuele platforms

Justin Rattner, Intel Senior Fellow and Director Corporate Technology Group, heeft in zijn keynote op het Intel Developer Forum een kijkje in de toekomst gegeven. Deze toekomst bestaat volgens Intel uit processors met meerdere cores en virtuele platforms. Daarnaast zouden chips in de toekomst niet meer met elektrische signalen, maar met licht met elkaar communiceren.

Virtuele platformen

Een virtueel platform is het beste te vergelijken met VMWare. Deze software maakt het mogelijk om een virtuele computer te creëren die zijn eigen besturingssysteem draait. Op dit moment is de oplossing nog steeds geheel in software geïmplementeerd, maar in de toekomst moet de hardware een virtueel platform ook mogelijk maken. Een eerste stap in die richting is Virtualisation Technologie (Vanderpool) die hardwarematige ondersteuning voor virtuele platformen in processors mogelijk maakt. Net zoals met VMWare kan een processor met behulp van deze techniek meerdere besturingssystemen tegelijkertijd draaien. Volgens Intel is dit niet alleen nuttig voor bedrijven, die op een server meerdere besturingssystemen willen draaien, maar ook voor de gebruiker thuis. Met behulp van Vanderpool en bijvoorbeeld een USB-stick zou deze op een andere computer zijn eigen besturingssysteem kunnen draaien en in zijn eigen vertrouwde omgeving kunnen werken. Intel demonstreerde deze technologie en liet ook zien dat het mogelijk is om een virtuele videokaart te maken. Intel heeft ook plannen om virtualisatie voor opslag en netwerken toe te passen.

Many-core

De toekomst is volgens Intel natuurlijk het gebruik van meerdere cores op een processor. In de nabije toekomst zullen dit er twee zijn. Later worden dat er vier of acht, maar de kans is groot dat dit er tientallen zijn in het jaar 2015. Hoewel dit op het eerste gezicht een goede methode lijkt om de snelheid van processors te verhogen, brengt het ook een aantal problemen met zich mee. Als eerste is het veel moeilijker om een programma te schrijven dat gebruikt maakt van meerdere processors. Daarnaast zal de honger naar geheugenbandbreedte die de cores gezamenlijk hebben, gestild moeten worden.

Om het eerste probleem aan te pakken werkt Intel aan nieuwe programmeertalen voor specifieke toepassingen. Met behulp van deze nieuwe talen zou het makkelijker moeten zijn om parallelle code te schrijven. Een nieuwe programmeertaal vereist ook een nieuwe compiler, waar Intel dus ook aan werkt. In de toekomst moet deze combinatie het dus mogelijk maken om makkelijker multi-threaded applicaties te schrijven, waarbij elke thread op een aparte core kan draaien.

Voor het tweede probleem komt Intel met een combinatie van oplossingen. Naast een eigen cache voor elke core krijgt de processor ook een gezamenlijk cache dat gebruikt kan worden door alle cores. Dit lost echter maar een gedeelte van het probleem op, want uiteindelijk zullen de gegevens toch uit het geheugen moeten komen. Er is dus meer bandbreedte voor de FSB nodig. Dit kan bereikt worden door de processor te voorzien van meer pinnen, maar die kant wil Intel eigenlijk niet op. Projecties geven namelijk aan dat er alleen al voor de gegevens 600 tot 1800 pinnen in de toekomst nodig zijn. Hier moeten dan ook nog de pinnen voor de energievoorziening worden bijgeteld. Intel kijkt daarom of het niet mogelijk is om de processor met het geheugen te combineren. Met behulp van 3D wafer stacking kan bijvoorbeeld een complete DRAM-wafer bovenop een processor-wafer worden geplaatst die doormiddel van miljoenen contactpunten met elkaar verbonden kunnen worden. Dit is echter niet echt flexibel. Daarom kijkt Intel ook naar de mogelijkheden van 3D die-stacking, waarbij losse chips in plaats van wafers op elkaar worden geplaatst in dezelfde behuizing.

Chip-to-chip communicatie

Niet alleen de processor zal in de toekomst behoefte hebben aan een enorme bandbreedte. Ook chips zullen in de toekomst steeds sneller met elkaar moeten kunnen communiceren. Op dit moment worden daar nog steeds elektrische signalen voor gebruikt, maar hier zijn een aantal problemen mee. Zo zijn elektrische signalen nogal gevoelig voor storing. Licht is dat echter niet en Intel werkt er dan ook hard aan om ervoor te zorgen dat chips in de toekomst via lichtsignalen met elkaar kunnen 'praten'. Hiervoor moeten de chips wel worden uitgerust met een laser om te zenden en een lichtgevoelige diode of transistor om te ontvangen. Op dit gebied ligt Intel ver voor op de concurrentie, getuige een grote doorbraak eerder dit jaar met de realisatie van de eerste silicium laser.

Reacties (45)

[Verwijderd]

Intel programmeertalen ( I++ ), Intel Compilers, zometeen nog een heel Intel OS in hardware... Die mensen zijn ook niet een beetje ambitieus.

Wat die parallelle programmeer taal betreft: Er wordt al decennia onderzoek gedaan naar deze Heilige Graal van het parallel rekenen, maar niemand heeft ooit iets kunnen verzinnen waardoor het bouwen van een parallel programma doenlijk wordt. Zelfs voor wetenschappelijke toepassingen die veel processor kracht vereisen is de drempel om over te stappen naar parallelle algoritmen erg hoog.

Veel cores in 1 machine is natuurlijk wel erg leuk voor Linux machines (en UNIX in het algemeen natuurlijk), waar vaak tientallen of soms zelfs honderden mensen tegelijk op 1 machine werken. Met veel cores kan dit aantal nog verder omhoog waardoor het aantal computers dat je per gebruiker nodig hebt nog verder omlaag kan. Dat kan aardig in beheers en onderhoud kosten schelen.

[Verwijderd]

Je moet wel duidelijk onderscheid maken tussen 'parallel rekenen' en 'parallel programmeren'.

Om bijvoorbeeld spelletjes multitreaded te laten werken hoef je helemaal geen algoritmes te splitsen om parallel uit te laten voeren, het zijn namelijk grotendeels kleine onafhankelijke bewerkingen die uitgevoerd worden.

Jij stelde al dat UNIX met veel gebruikers wel effectief gebruik kan maken van multicore-cpu's. Kijk eens goed naar een multiplayer-spel, daar heb je ook meerdere gebruikers met meerdere computers. Stel je voor dat op al die computers ipv een mens een programma dat spel aan het spelen is. Stel je voor dat ipv van losse computers in een netwerk, diezelfde programma's als een losse thread op een aparte core in 1 computer draaien... voila, een multithreaded computerspel.

Het is jammer dat zoveel programmeurs zo'n hekel denken te hebben aan multithreaded programmeren, want zelfs op een single-core/cpu computer zijn er zeer grote winsten te behalen met multithreaded-programmeren.

[Verwijderd]

Computerspellen waar iedere 'bot' of spelende partij een apart proces is zijn natuurlijk wel voorbeelden van programma's die van nature al parallel van aard zijn, of makkelijk parallel te maken. Voor de meeste software ligt dit veel gecompliceerder. Ik hoop toch niet dat Intel het hier alleen op de gamers voorzien heeft..

Het is jammer dat zoveel programmeurs zo'n hekel denken te hebben aan multithreaded programmeren

Dat komt doordat multithreaded applicaties vaak zeer vervelende bugs kunnen hebben die moeilijk oplosbaar zijn. Deze bugs zijn ook typisch niet reproduceerbaar, lijken willekeurig op te treden en zijn heel moeilijk op te lossen. Threads kunnen 'verstrengeld' raken op manieren die de programmeur nauwelijks kan voorzien, waardoor er in geval van een random crash of lockup niet begrepen wordt hoe ze precies in de knoop zijn gekomen. Niet vreemd dat veel programmeurs hier geen zin aan hebben.

[Verwijderd]

Dat is inderdaad wel een nadeel van multithreaded programmeren, het debuggen wordt een stuk moeilijker. De ernstige debugproblemen treden vooral op bij de zogenaamde debugger-programmeurs (die single-threaded ook geen goed programma kunnen maken zonder hulp van een debugger).

Het is bij multithreaded belangrijker om van te voren duidelijk uit te stippelen wat het programma gaat doen en hoe, en niet zoals een hoop 'programmeurs' zomaar beginnen en maar kijken waar problemen zich voordoen en die dan oplossen.

Ik gebruik debuggers alleen om te kijken of m'n programma's helemaal goed lopen, en nooit om problemen op te lossen.

En 'deadlocks' zijn voornamelijk een gevolg van het falen van de logica van de programmeur. Als je duidelijke en stricte logica gebruikt, is een deadlock bijna onmogelijk. Het is echt niet zo dat deadlocks random ontstaan, ze zijn altijd duidelijk (hoewel niet makkelijk) te herleiden naar een denkfout.

[Verwijderd]

doet je denken aan Apple he

edit: dit is eigenlijk een reactie op de eerste zin van Mr Dik...

[Arcane Apex]

Wat gaat dit allemaal betekenen voor oudere maar nog steeds zeer veel gebruikte talen als C en C++ ?
Zullen de libraries worden aangepast en uitgebreid zodat deze talen ook gebruik kunnen maken van multicore processoren of zullen deze talen uitsterven?(Wat ik niet hoop)

Hoe zit het trouwens met multithreading voor C++, ik heb geluiden gehoord dat dat nooit van de grond is gekomen...voor Java wel, maar C++ niet, of althans niet in elegante vorm.

Wat ook een mogelijkheid is, is dat de talen C/C++ helemaal niet aangepast worden aan multicore CPU's en multithreading, maar slechts de compilers, wordt dat niet als een optie gezien om deze talen geschikt te maken voor deze nieuwe (hardware)features?

Tevens, als men steeds meer virtuele platvormen zal gaan creeeren en virtual machines(Java VM, .NET VM etc) zal de bruikbaarheid van C/C++ dan ook verminderen?
Of zullen programmeurs er dan nog steeds voor kunnen kiezen om alles te doen in C/C++, ondanks dat men alles pushed wat virtual is en high-level?
Immers het lijkt alsof men de dingen zo wil pushen zodat men gedwongen lijkt te worden higher-level languages te gebruiken.

Heeft iemand hier informatie over of artikelen of een eigen visie?

[dancingdoorman]

Intel levert geoptimaliseerde libs voor C++ en andere talen.
In principe kan je binnen C++ gewoon assembly/machinecode opnemen om het te optimalisern.

Multitreaded programming voorzieningen zijn er overigens genoeg maar programmeurs zijn er bang voor. Er kunnen race conditions en starvation van treats ontstaan en dat is hell om te debuggen.

Desalnietemin was BeOS (nu PalmOS en Opensource Haiku) geheel gemultitread en was de gehele communitie daarvan doordrongen.
Daardoor was het OS en de apps supperresponsive en voelde het gewoon goed.

Helaas is dit voor de normale programeur niet weggelegt omdat functionaleit en deadlines ver boven design en performance gaan.

Het beste is om de performance en geavanceerde features weg te stoppen in tools en libraries zodat je ze gebruikt zonder het te weten, waardoor je er effectief een hoger niveau taal van maakt.
Met mijn overstap van C++ naar C# zag ik dit ook gebeuren. Grotendeels zelfde syntax maar totaal andere motor.

[Verwijderd]

Chips in de hoogte opbouwen zou heel goed tot snellere en betere processors/systemen kunnen leiden, maar heeft waarschijnlijk als consequentie dat de chips ook meer warmte zullen ontwikkelen en daarnaast een slechtere warmte afvoer.

Met de komst van de Pentium 1 (en AMD 80586) is ook de CPU - fan gekomen. Zou waterkoeling hiermee standaard gaan worden? Of zijn er nog andere mogelijkheden?

[Croga]

Gezien de ontwikkelingen in de Pentium-M lijkt mij dat het warmte probleem een tijdje uitgesteld is...

Ook Cool'n'Quiet en Intel's tegenhanger hiervan in de P4 J series en de doorontwikkeling van ultra-low voltage processoren geeft duidelijk aan dat het beperken van de warmte ontwikkeling al enige tijd de focus van de processor fabrikanten heeft.

Ook de overstap naar 65nm technieken zou de warmte ontwikkeling weer verder moeten beperken.

En als laatste: wanneer lasers ingezet kunnen worden in bepaalde delen van de processor, hoeft daar geen stroom gebruikt te worden. Aangezien warmte ontwikkeling nagenoeg volledig ontstaat door inefficient stroom gebruik, zullen die delen van de processor dus ook minder warm worden.

Je hebt gelijk als je zegt dat de warmte ontwikkeling bij dit soort stacks een probleem zal gaan worden, maar waterkoeling is de eerste tijd zeker nog niet nodig.

[Verwijderd]

Tuurlijk.. Voltage nog veel verder omlaag. En dat kan makkelijk als ze de lichttechniek verder doorzetten.

De eerste Pentium 1 werkten nog op 5 volt.
Tegenwoordig minder dan 2 volt.

Als ze die voltage zouden gebruiken bij de P1, of de P2, en misschien wel de P3, dan hadden die wellicht al genoeg gehad aan een passieve koeler.

[Niles]

Die lichttechniek gaat meer over transport van data tussen chipset en cpu, dat zijn relatief gezien enorme afstanden. Daar is lichttechniek voorlopig nog wel rendabel omdat bij kortere afstanden het omzetten van elektronisch naar lichtsignaal langer duurd dan de behaalde winst die je haalt met de snelheid van het licht itt elektriciteit. Binnen in de cpu is dus alles nog steeds elektrisch, en dus zal het voltage blijven hangen rond waar we nu zitten omdat dit gewoon erg moeilijk omlaag te brengen valt.

Als ze die voltage zouden gebruiken bij de P1, of de P2, en misschien wel de P3, dan hadden die wellicht al genoeg gehad aan een passieve koeler.

Dat voltage hadden ze niet voor niets. met een Vcore van < 2 Volt hadden de cpu's destijds NOOIT op die voor die tijd hoge frequenties kunnen lopen. Dat we tegenwoordig veel beter doorschalen op lagere voltages komt meer vanwege verbeterde productietechnieken en technieken zoals SoI (Silicon on Insulator), Strained Silicon maar ook gebruik van andere en betere materialen (mix van germanium en silicium ipv enkel silicium) of zelfs compleet andere methodes.

De Pentium 3 had trouwens al voltages van rond de 1,5 Volt, athans voor de Tualatin P3 (FCPGA-2 package). En hier hebben we dan gelijk een goed voorbeeld: Voorgaande cores Coppermine en Katmai eiste een hoger voltage, maar waren ook gemaakt op 180nm. Tualatin was gefabriceerd op 130nm en meteen kon het voltage iets omlaag, en de klok omhoog, dat noemt men vooruitgang. Daarom had Tualatin dus ook een nieuw package nodig: FCPGA-2 tov standaard FCPGA-package, het nieuwe package leverde een lager voltage, en in die tijd (socket 370) moest je dan ook goed uitkijken wat voor cpu en mobo combi je nam.

[Verwijderd]

Tsja what is new. Ik ken iemand die twee procossors op elkaar gestapeld had op zijn acron atom of electron. (geen idee welke het was) En dat al een stevig effect op de performance. Maar ok dit was in het 1 tot 8 Mhz tijdperk en geheugenbandbreedte was toentertijd waarschijnlijk een non-issue.

Maar toch is het leuk dat men nu om andere redenenen kijkt naar een oplossing die overeenkomt hobby oplossingen uit vroeger tijden.

[Verwijderd]

Weet je zeker dat 'ie 2 processoren gestapeld had?
Geheugenchips 'piggy-backen' was toen wel gebruikelijk, maar bij processoren ben ik dat toen nooit tegengekomen.
Het enige Acorn systeem wat daar een beetje bij in de buurt kwam was een Acorn BBC met extra Z80-kaart. Het normale IO-werk deed de 6502, en het rekenwerk kon je overlaten aan die Z80. Maar daar had je wel speciale software voor nodig...

[raphidae]

Het is even wachten totdat processors in staat zijn hun eigen warmte te recyclen en als power source te gebruiken.

Microchip can turn heat into electricity

[Verwijderd]

De silicium-laser zal alleen voor bepaalde doeleinde toegepast worden neem ik aan. Waar heeft deze vooral nut? Het lijkt mij dat als de licht-transmissie alleen maar voordelen zou hebben deze overal toegepast zou worden maar dat wordt hij niet. Trouwens een hele mooie vooruitgang light on chips...

[rapture]

De huidige verbindingen in chips en tussen chips zijn gemaakt van parallelle draden. Hoe meer draden naast elkaar, hoe meer dat bitjes dat je per klokpuls kan doorsturen. Met veel draden heb je last van crosstalk (overspraak) en skew (scheefloop) bij hogere klokfrequenties. 2 draadjes naast elkaar hebben beetje condensator effect en hoe hoger de klokfrequentie, hoe lager de impedantie. Hierdoor kan er signaal overspringen naar andere draden en kortsluitingachtigeffect geven zodat er veel verzwakking is, dit is het crosstalk-probleem. Als er veel draden naast elkaar zijn, dan kunnen de bitjes in de ene draad sneller aankomen dan de bitjes in een andere draad. Hoe sneller de klok tikt, hoe minder tolerantie hierop mogelijk is. Als men te snel klokt, dan kunnen bitjes te vroeg of te laat aankomen en dus verkeerd uitgelezen worden, dit is het skew-probleem.

Men lost dat nu op door het aantal parallelle draden te verminderen en het boeltje serieus hoog op te klokken: zie PCI-Express, HyperTransport, Sata, USB,... Bij PCI-Express zien we dat het niet genoeg is en men zet er een hoop parallelle lanes erbij. Men blijft proberen sneller te gaan en we gaan steeds dichter bij de grens.

Licht-datatransmissie heeft geen crosstalk en skew, dus erg interessant. Bij de netwerken zien we ook dat glasvezels sneller gaan dan koper. Dankzij de Silicium-laser kan men aan licht-datatransmissie in een chip doen.

[scn]

Even iets rechtzetten, licht door een glasvezel gaat niet zo snel als licht door een vacuum (Iwaar de lichtsnelheid op gebaseerd is) zodat de snelheid van een signaal door koper gelijk kan worden beschouwd aan de snelheid van licht door een glasvezel.
Het grote voordeel is inderdaad dat er geen overspraak is bij licht en door middel van meerdere kleuren gebruik wordt de bandtbreedte enorm opgekrikt.

[raphidae]

Een single-mode glasvezel is over het algemeen gemaakt SiO2, met een refractieindex van 1.5. Als we de lichtsnelheid door vacuum als 300000m/s nemen is de snelheid van licht door een glasvezel 2/3 daarvan, dus 200000m/s.

Electrische signalen kunnen inderdaad met bijna de lichtsnelheid verzonden worden, maar dat geld alleen in een supergeleider waar de electronen vrijwel stil staan, in de 'echte' wereld is de snelheid van een signaal door een koperen printbaan ongeveer 1/3 van c.

Dus signalen door fiber zijn effectief toch nog 2x zo snel.

En een quote die misschien informatief is:

In addition to being highly resistive, long wires also act as inductors (varying current flowing through a conductor causes varying magnetic fields), which also attenuate and distort the electrical signal. Because the long wire will run near other wires or the "ground",the wire and the other wire and ground will act as capacitors, also attenuating and distorting the electrical signal, and giving rise to cross talk between the wires that are capacitively coupled - adding another source of noise.

These effects limit the data rate and distance for wires to, say, 200 Megabits/second and 10 meters.

By contrast, an optical fiber (single mode fiber) guides the light with very little attenuation, no inductance or capacitance, and relatively few noise sources, almost no crosstalk.

Another way to think of this is to consider the case of sending signals through cable (as in cable tv), versus through fiber. When we send signals through cable, we use something akin to the modulation that is used in radio transmission through the air: the electrical signal is used to modulate the amplitude and/or frequency of the carrier wave. The carrier wave must be at a much higher frequency than the frequency of the electrical signal that will be modulating the carrier wave.

Let's say that the carrier wave frequency must be at least 10 times the data rate to modulate the carrier wave. Then, the maximum data rate for a 900 MHz carrier wave would be 90 Megabits/second; (10 Megabits/second would be more achievable). In fact, a 900 MHz carrier wave is bordering the microwave frequencies.

By contrast, the carrier waves for optical fibers would be...light...which has a frequency of....of...well, let's calculate it. For the lowest frequency light, red, let's say the wavelength is about 700 nanometers. From the equation, frequency = c / wavelength, where c is the speed of light,

Frequency of light = 3 x 10^8 meters/ second x 1/ (700 x 10^-9) = 4 x 10^14

So, using the previous assumption that you can modulate a carrier wave with a data rate one tenth of the carrier wave frequency, the maximum data rate would be about 4 x 10^13 bits/second, or about 40,000,000 Megabits/second (40,000 Gigabits/second).

[RetepV]

Ehm, 2 maanden geleden heeft Intel voor het eerst verteld dat het kon .

www.tweakers.net/nieuws/35675

Zo snel gaat het ook weer niet .

Ik hoop dat het ze lukt. Met licht kun je een hele hoge datasnelheid halen. Veel meer data/s dan je ooit parallel met een koperen bus zult kunnen halen.

Stel je voor dat een moederbord geen databus meer heeft tussen de verschillende chips, maar een glasvezeltje die alle chips met elkaar verbindt. Goed, je zult nog een PCI of PCI-E of AGP bus moeten maken, maar de communicatie tussen de CPU('s) en de buscontroller kan met licht en daarmee vele malen sneller.

Goed, het probleem is natuurlijk nog wel dat alle randapparatuur (USB, IDE, FDD, whatever controller) toch te langzaam is. Maar het moederbord kan wel een stuk kleiner en kan een stuk minder ingewikkeld zijn. En de CPU hoeft bijvoorbeeld alleen nog maar pinnen voor stroom en een glazvezelsocket voor de adres/databus nodig. Hoppa, effe b.v. van 939 pinnen terug naar misschien 100. Dat scheelt wel effe aan printspoortjes op het mobo die je niet meer nodig hebt.

Wacht maar, dit gaat er zeker aan komen. Een revolutie zal het niet worden, maar er zitten zo veel voordelen aan dat het gaat komen. CPU's en CPU bussen hebben geen revolutie nodig, op dit moment. Geheugensnelheid, daar is nu een revolutie nodig.

[microchip]

Geheugensnelheid? Hoeveel scheelde de bandbreedte tussen dual channel en single channel bij de A64? 80%? Hoeveel gingen de prestaties er op vooruit? 2-5%?

[NitroX infinity]

Ik denk dat Intel nog wel weer eens keihard tegen een barriëre op gaat botsen.

In plaats van dat ze zich nou eens gaan concentreren op het drastisch verhogen van het aantal verwerkte instructies per kloktik. Dat lijkt mij een stuk beter dan meer snelheid of meer cores.

[Verwijderd]

Netburst wordt toch ook niet meer verdergezet. Intel heeft dus wel begrepen dat het vrij zinloos is om nog steeds hun nieuwe processoren van meer megahertzen te voorzien, zonder voor de rest veel te veranderen aan de architectuur. Als de Pentium M een mooier plaatsje krijgt in de (desktop)markt, dan zijn ze in mijn ogen al goed bezig.

Je kan ook niet zeggen dat ze niet innovatief zijn. Die techniek om chips met elkaar te laten communiceren door middel van licht spreekt me wel aan.


Om het eerste probleem aan te pakken werkt Intel aan nieuwe programmeertalen voor specifieke toepassingen. Met behulp van deze nieuwe talen zou het makkelijker moeten zijn om parallelle code te schrijven. Een nieuwe programmeertaal vereist ook een nieuwe compiler, waar Intel dus ook aan werkt.
Gaat het hier om een opvolger/vervanger van de x86-structuur?

[Niles]

x86 heeft hier weinig mee van doen. De programmeertaal zelf is gewoon nieuw, en de compiler zet deze nieuwe programmeertaal gewoon om naar informatie waar de cpu wat aan heeft (lees: x86). Ze zorgen alleen dat de nieuwe programmeertaal makkelijker multithreaded te schrijven is zodat de meerdere cores wel benut worden anders heeft het toevoegen van meerdere cores geen zin. Een nieuwe programmeertaal heeft echter ook een nieuwe compiler nodig omdat deze dus de nieuwe programmeertaal om moet zetten naar x86 instructies en dan zodanig dat de verschillende cores zo goed mogelijk benut worden . x86 zelf veranderen ze helemaal niets aan.

[Olaf van der Spek]

In plaats van dat ze zich nou eens gaan concentreren op het drastisch verhogen van het aantal verwerkte instructies per kloktik.

Dat is veel en veel simpeler gezegd dan gedaan. Veel algoritmes laten zich niet makkelijk paralelliseren. Moeilijk automatisch en al helemaal niet on-the-fly in de CPU.

[nAFutro]

Ik denk dat Intel nog wel weer eens keihard tegen een barriëre op gaat botsen.

Klopt en ik ben heel benieuwd wat voor schitterende oplossing ze bedenken zoals meerdere malen in het verleden hebben bewezen te kunnen.

[loodgieter]

Later worden dat er vier of acht, maar de kans is groot dat dit er tientallen zijn in het jaar 2015

dit is weer een heftige uitspreek. want ze zeiden dat in 2007 de 10GHz al lang berijkt zal zijn. Dit zijn echt van die dingen die je eerst moet zien voor da je het ook pas echt gaat geloven.

En natruulijk word het bak procede ook wel stteds kleiner maar tientallen lijkt me niet echt haalbaar. niet op zo`n "kort"termijn.

[Verwijderd]

Bwo, uiteindelijk hebben ze op de laatste 10 jaar een sprong gemaakt van de pentium I 133Mhz naar 4000Mhz.

Ik denk dat vanaf dat ze een manier vinden om 10cores in te bouwen op een efficiënte manier dat daaran het "gemakkelijker" is om er nog meer bij te plaatsen. Momenteel zijn ze nog aan het kijken HOE ze dat juist gaan doen, maar vanaf dat ze een methode hiervoor hebben gevonden is het een kwestie van stilletjesaan steeds meer cores bij te plaatsen, kwestie van de markt stilletjes op te bouwen en de commerce te laten draaien Het blijft natuurlijk gevaarlijk om te voorspellen hoe de snel evoluerende computermarkt er binnen 10jaar gaat uitzien maar het lijkt me niet onmogelijk.

[stewie]

dat noem ik een heel klein sprongetje.
het probleem is dat een 4000Mhz CPU het niet veel beter doet dan een 2400Mhz AMD 64...

leuk hoor Mhz maar het zegt geen hol in de werkelijke wereld.

[Verwijderd]

daarom dus ook dat de visie van de 10 GHz processor eigenlijk WEL correct is, maar we tegen 2007 wellucht gaan 10 GHz gaan zien maar misschien wel een processor die (geschaald dan) de performance haalt van een 10 GHz processor volgens de oude opdracht/kloktik verhouding.

de barriere van de GHz-en is ongevere bereikt door het probleem van warmteontwikkeling, maar de ontwikkeling staat niet stil. een 4000 Mhz proc is wel degelijk een stuk sneller dan een 2400 Mhz proc, en een 4000+ AMD is een stuk sneller dan een 2400+ AMD, iedereen weet onderhand al wel dat MHz-en niet alles meer zeggen, maar het is wel handig om te kunnen spreken over een equivalent 10 GHz systeem zodat de mensen uberhaupt nog een idee hebben van hoe snel dat ding nu eigenlijk wel zou moeten zijn.

[BartOtten]

Vraagje: Als je met licht gaat werken, dan moeten de lichtbundels erg klein zijn zodat er veel van die dingen op het mobo passen. Maar hoe zit het dan met ronddwarrelend stof? Of een stofhoopje op je mobo.....

Vooreerst denk ik niet dat mensen passieve waterkoeling gaan toepassen op grote schaal (lees: standaard consument). Dus de kast blijft altijd 'open'

[erikdenv]

Dat licht gaat wel door een geleider heen en zal niet los op je bord van de ene naar de andere kant schijnen.
Sterker nog, je mag totaal geen licht zien want dat zou betekenen dat er informatie verloren gaat.

[Verwijderd]

Kunnen ze niet 1 core gebruiken die hardware matig alles verdeelt onder de andere cores? dat zou voor programmeurs toch een stuk makkelijker zijn? zeker als je straks procs met verschillende aantallen cores heb om nog maar niet te praten over wat er gebeurt als amd ook met zoiets komt (en verschillende merken, die ook nog eens andere aantallen cores kunnen hanteren).

Of misschien wat tech van videokaarten lenen? die zijn stukken sneller dan CPU's. Nou kunnen gpu's niet zomaar de taken van een cpu doen maar zelfs al zou je de helft van de snelheid van een gpu opofferen om hem goed cpu taken te kunnen laten doen dan kan ie nogsteeds veel meer berekenen dan een CPU of liggen die 2 zover uit elkaar dat dat gewoon niet gaat werken?

[Olaf van der Spek]

Kunnen ze niet 1 core gebruiken die hardware matig alles verdeelt onder de andere cores? dat zou voor programmeurs toch een stuk makkelijker zijn?

Nope, zie Gepost door Olaf van der Spek - donderdag 3 maart 2005 - 23:15.

[Verwijderd]

Kunnen ze niet 1 core gebruiken die hardware matig alles verdeelt onder de andere cores?

Dat kan alleen als je losse instructies (micro-ops) verdeelt over de cores. En dat is alleen zinvol als de cores bij elkaar op 1 chip zitten, anders wordt het nooit snel. Dus dan ben je weet terug bij een single-core chip. Is dus helaas geen optie.

Of misschien wat tech van videokaarten lenen? die zijn stukken sneller dan CPU's

Die zijn zo snel omdat ze voor 1 specifieke taak geoptimaliseerd zijn. Een CPU moet alles snel kunnen.

[Verwijderd]

Multi-core is Cell van IBM. De toekomst van de processor is dus al uitgevonden en komt o.a. in de PS3.