Op zicht wel een intressante hersen spinsel, maar je kan het ook op een andere manier bekijken.
x86 is eigenlijk alleen maar zo groot geworden omdat het zo idioot porgrammeur vriendelijk is en dus werd er veel software voor geschreven, nadelen van x86 is dat het vergleken bij andere ISA's niet zo snel zijn, en amd heeft niet voor niets units in hun K8 gebouwd die geen andere functie hebben dan x86's nadelen 'omzeilen'. En nu lijkt een einde te komen aan de programmeur vriendelijkheid van de x86 computer, nu moeten programmeurs ineens multithreaded programmeren. x86 heeft altijd stand gehouden door de gigantische hoeveelheid software, en destijds de druk IBM.
Nu zou dit weleens het einde kunnen betekenen voor x86, zou ik neit erg vinden...
Aan de technische kant van het verhaal, op het moment kunnen ze niet meer units toevoegen om het sneller te laten gaan, de extra complexiteit zou het langzamer maken, mogelijker wijs wel mogelijk maken om hogere clocksnelheden te bereiken, maar dat doen ze gelukkig niet.
In plaats van 1 core sneller proberen te maken, wat nu bijn niet mer mogelijk is (meer stages in pipeline maken het langzamer, meer cache werkt langzamer) dus juist door Moore's Law, er kunnen meer componenten op de die, (zoals dus ook een memory controller), is er ruimte op de die, en op het moment weten ze even niet precies wat ze ermee moeten doen, dus zetten ze 2 cores op die die, om hem 2x zoveel ruwe rekenkracht te geven, is dis slecht? Ik dacht het niet.....
Een alternatief, zou zijn geweest system-on-a-die, meer intergreren dan alleen de memory controller. AMD heeft dat dus een klein beetje gedaan, en in de toekomst zal meer naar de die worden verplaatst, als blijkt dat quad-core niet zo makkelijk te realiseren is, en mogelijkwijs hebben we in de toekomst iets wat in de buurt komt van de Cell processor voor onze desktops.
Zolang de grote van transistors nog verminderd kan worden, zolang het voltage nog omlaag gaat, zolang de clocksnelheid langzaam toeneemt (zie AMD clocksnelheden, intel is buiten gewone clocksnelheid wegen gaan lopen) en zolang het verbruik van processor langzaam toeneemt, zijn de huidige techniken nog genoeg. En anders komt er iets in de richting van optronische computer
.
@Thamind,
Dat x86-64 backwards compatible is met x86 is niet helemaal waar, want dat klopt alleen binnen een OS wat de compatibility mode gebruikt, effectief zul je er weinig van merken maar eigenlijk is die compatibility slechts schijn.
Ze maken er geen RISC code van, want dan waren er maar een stuk of 6 stages in een pipeline, hooguit. Wat AMD bijvoorbeeld doet is van te voren de instrucites deels decoderen, en de extra info op slaan als meta data, x86 had als voordeel dat instructies geen vaste grootte innamen in het instructie cache, dus was er minder cache nodig, AMD's oplossing omzeilt die hele eigenschap, en kost transistors. Bijna elke nieuwe processor heeft tal van x86 omzeil technieken, AMD heeft wel een paar van de meest extreme, ze hebben een unit die probeerd pagetable look-ups in het ram (vanwege virtual memory) te ontlopen.
Ze hebben wel degelijk plaats, er is wel degelijk een reeele grootte van de die zorgt voor een goede kosten/opbrengts verhouding, ik zou niet weten waarom, maar de wet van Moore gaat daar juist over, en die wet houd al best lang stand, tehnisch kan het vanwege de transistors die steeds kleiner worden, maar waarom ze ook werkelijk continue ongeveer even grootte die's maken, geen idee.....
Vanaf de eerste Pentium x86 al de vooruitgang in processor performance op, maar, die werd een succes juist omdat hij x86 nog ondersteunde. Ondanks dat ik persoonlijk lciht gezegd niet zo'n fan ben van x86, het heeft weinig te maken met multithreading, er zijn genoeg multithreaded apps op gewone x86, en voor x86-64 zullen er nog wel meer komen.
@MeMoRy
Met Multicores kan gedeelt cache de boel JUIST extra versnellen, IBM heeft dit al een gedaan. Het idee van meerdere processors is ook niet dat ze aan 1 thread werken, dus dan ben je meteen van dat probleem af, iedere proc zijn eigen thread, als er dan toch op geheugen of of cache van andere cpu's moet worden gelezen, komt er inderdaad een aardige performance drop....Geen cache is puur een ontwerppers keuze, het vector systeem waar jij op doelt zal niet toevallig Cell zijn? Die heeft namelijk wel degelijk iets dergelijks dat op cache lijkt, iedere vector processor (SPU) heeft zijn eigen local ram, dat is ultra snel SRAM, hetzelfde spul als waar ze cache van maken, dit geheugen is alleen voor die ene vector processor, en daar mogen de ander niet bij, dus als je er een goed systeem in brengt, zal het met cache ook wel moeten lukken. Bij de Cell hebben om andere redenen geen cache gebruikt....
@Olaf van der Spek
Destijds waren er al veel x86 apps toen intel besloot de pentium ook compatible te maken met x86, het leverde ze toen al meteen een heel scala aan software op. Verder heeft windows ervoor gezorgt dat we ook nog wat konden met die x86 troep, dat heeft geleid tot een erg stabiel ontwikkel platform...
niet x86 is erg veel sneller, destijds was RISC al sneller, maar AMD en Intel hebben beide erg veel manieren bedacht om RISC na te doen. Ook hebben MMX SSE SSE2 en SSE3 een enorm bij gedragen aan de snelheid van x86, maar ik denk echt, dat het sneller kan op andere ISA's. bijvoorbeeld op Altivec....Maar met zekerheid kan ik dit natuurlijk niet zeggen, wat ik wel weet, x86 vanzichzelf, dat is dus zonder SSE, zonder AMD's en Intel trukendoos, is dramatisch langzaam.
Het idee van cache is ook eigenlijk niet bedoelt voor meerdere processors, maar het zou nog wel kunnen, localram is een prima vervanger van cache, cache zorgt er alleen maar voor die niet elke keer in dat trage DRAM gekeken hoeft worden, local ram doet effectief hetzelfde, maar dat is weer niet gedeeld.
AMD's Opterons met NUMA hebben niet alleen hun eigen cache, maar ook hun eigen geheugen, en toch gaat dat nog redelijk snel....het OS lost in dat geval het probleem op.
EDIT;
En nee, mijn kennis van supercomputers is, ligt gezegd, beperkt....
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
De twee videokaarten zullen communiceren via een externe kabel, vergelijkbaar met wat we vroeger zagen bij de Voodoo2. Dit is in tegenstelling met eerdere berichten waarin geclaimd werd dat de communicatie via de PCI Express-bus zou lopen. Hexus.net suggereert dat de externe kabel wellicht gebruikt zal worden bij de high-end modellen om de PCI Express-bus niet te zwaar te belasten terwijl de low-end modellen wel gebruik kunnen maken van de PCI Express-bus.
20:35
11:06
Door 
