[Algemeen] x86 Instructie-set

[killingdjef]

Ik zat laatst het een en ander te lezen over de geschiedenis van de processor en hoe het ontwikkeld en geevolueerd is in de loop der tijd en kwam erachter dat de meese de x86-architectuur redelijk troep vinden.

Met andere woorden, als men nu een nieuwe architectuur zou maken zou dat vele malen sneller zijn dan de snelste processor die we nu kennen. Een nadeel zou zijn dat alle software wat er bestaat niet meer kan draaien.

Nu vroeg ik mij dus af, waarom wordt er niet een architectuur ontwikkeld die vele malen superieur is aan de x86 en de mogelijkheid biedt om de x86 set te emuleren? Al het software zou dan nog steeds kunnen draaien (trager misschien?), er is een nieuwe betere architectuur wat men kan uitbouwen en de processors worden sneller en de programma's dus ook. Uiteindelijk zullen de x86 programma van de markt verdreven zijn en heb je een betere architectuur.

Is dit logisch of zie ik wat over het hoofd?
Maar nog belangrijker, waarom wordt er niks aan gedaan?

[Vinnienerd]

x64?

[Nvidiot]

Vinnienerd schreef op zaterdag 03 december 2005 @ 20:15:
x64?

Is nog steeds x86, maar dan met 64-bit extensies.

Waarom men niet opnieuw begint? Heel simpel: dan draait de huidige software niet meer. Zeker in het bedrijfsleven is dat met oudere software een probleem, die valt niet even eenvoudig te vervangen door een nieuwe versie.

Emuleren is leuk, maar tot nu toe is dat altijd knap traag gebleken. Kijk maar naar Bochs, VMWare & VirtualPC. Apple schijnt het beter te doen met Rosetta die PowerPC emuleert onder x86 trouwens.

[Murcielago]

Iemand zegt het straks wel, dus ik noem nu al vast: Cell

[killingdjef]

Klopt, Cell is inderdaad een compleet nieuwe instructie en de vele cores op de processor (8 geloof ik?) kan voor een onvoorstelbare snelheidswinst zorgen in vergelijking met de x86. Al krijg ik de indruk dat men er niet in durft te investeren, naast de PS3 dan uiteraard.

Maar als Cell de "opvolger" zou worden dan is mijn vraag eigelijk al beantwoord.

[ThunderNet]

Intel is rond 1993/1994 opnieuw begonnen.. Resultaat hiervan is de Itanium serie processoren. Echter bleek de markt hiervoor te star. IA-64 is nooit geaccepteerd als vervanger voor de IA-32(x86) juist om deze hekelpunten.

[TheBorg]

Ik vraag me af hoe dat dan zit met de Alpha processoren. Daar kun je wel NT 3.51 op draaien (speciale versie). Had je daarvoor ook speciale Alpha software nodig? Volgensmij was dat niet het geval.

[alx]

Het idee van Intel was idd IA-64, oftewel Itanium. De x86 arch was een CISC arch, te complex met weinig GPRs (general purpose registers (GPRs)), moeilijk om sequentiele instructies parallel uit te voeren (uitgebreide analyse nodig), geen/nauwelijks branch afhankelijke instructies (later wel CMOV), wat uitgebreide branch prediction nodig maakt en als dat faalt, een hoge penalty (o.a. diepe pipeline flush). Verder vrij lastig uit te breiden naar 64 bits dat op een dag toch nodig is en dat zie je terug in de 64 bits extensie die er nu is: Vaak nog 32 bits operands om cache en mem bandbreedte te sparen, prefix instructies nodig om dat indien nodig te overriden, etc. Als je gaat zoeken, kun je nog wel even door gaan.
RISC achtige architecturen zouden de toekomst hebben. Intel kwam met IA-64 en introduceerde de term EPIC (Extreme parallel instruction computing). Gericht op parallel instr processing, en oplossingen biedend voor branch problemen, zou dit de toekomst zijn. Helaas zorgde compatibiliteit met x86 voor een probleem. Itanium kon wel x86 code uitvoeren, maar dat was erg traag. Pas veel en veel later realiseerden ze bij Intel dat een JIT compiler in een run-time systeem (vergelijk JVM) veel betere prestaties gaf, maar toen was het kwaad al geschied: IA-64 werd niet wat het had moeten worden.
Zie ook http://en.wikipedia.org/wiki/IA-64

De x86 arch is tegelijkertijd enorm opgerekt, zowel in prestaties als in lage kosten. Hier kunnen weinigen tegenop. De laatste decennia zijn velen gestopt de productie van CPUs voor algemene doeleinden (denk HP PA-RISC, SGI is gestopt met MIPS in hun systemen, DEC Alpha, Motorola M68k als algemene processor, maar ook SPARC heeft het ontegenzeggenlijk moeilijk op het moment).

Er was idd een NT3.51 geschikt gemaakt voor de Alpha processor. Volgens mij had je hier geen speciale software voor nodig (ja, andere versie van NT3.51); NT3.51 voor de Alpha draaide native.

Wellicht gaat Cell meer success opleveren, maar Cell is volgens mij (nog) niet gericht als algemene processor voor allerhande computersystemen. Het zal in ieder geval de desktop nog niet direct veroveren.
Wat ik interessant vind, is of de Cell ontwikkelaars erin slagen om programmeurs te overtuigen hoe je software bouwt die snel draait op de Cell. Tot nu toe hoor ik ze zeggen dat je wat anders moet programmeren om goede prestaties te halen, terwijl programmeurs klagen dat de Cell niet al te vlot is. Daar lijkt een oorzaak/gevolg te liggen, maar is dat ook zo? Valt hier wat te verbeteren? Of komt het doordat Cell en dev tools nog verbeterd moeten worden?

[killingdjef]

Wat ik ervan begrepen heb is dat Cell, door zijn multi-cores, alleen echt rendabel is als ze ook daadwerkelijk gebruikt worden.

Dit betekend multi-thread programming en laat dit nou net ongelooflijk complex zijn (in de huidige staat van schrijven!). De support voor programmers over multi-thread programming is beroerend slecht, terwijl de techniek er is is het gewoon nog moeilijk om toe te passen. Als dit opgelost is dan zie ik zelf zeker wel de toekomst in Cell.

Ik heb me wijs laten maken dat de Cell processor in de de prestaties kan leveren, wanneer hij optimaal benut wordt, die gelijk zijn aan 8 Pentium 4 3 GHz processors. Laat staan als de Cell ook als GPU gebruikt kan worden.

Het is dus eigelijk de devtools van Cell maar daarnaast ook het Multi-threading in algemeen. Om te programmeren in Multi-threading zal er weer een andere denkwijze nodig zijn die geleerd is met Object oriented.. en ja, die is er net eindelijk na een aantal jaren ingebakken.

Tot slot, Cell is inderdaad nog lang niet in "desktop" vorm maar met een aantal jaar als er meer vraag is? Who knows

[ Voor 9% gewijzigd door killingdjef op 03-12-2005 22:45 ]

[dion_b]

Als korte antwoord op de vraag:
Er werd en wordt meer dan genoeg gedaan aan andere architecturen die op papier en vaak in silicon veel efficienter zijn dan x86. Toch zorgt marktwerking ervoor dat x86 dominant blijft - althans op de desktop. Er is meer software voor x86, dus gebruiken mensen x86. En omdat er meer gebruikers zijn voor x86, wordt er ook meer software voor geschreven...


Fundamenteel gezien zijn er 3 soorten CPU archtectuur:

CISC (veel instructies, waarvan sommigen meerdere cycles nodig hebben om uitgevoerd te worden, daarnaast geen instructies in de registers)
RISC (reduced instruction set, minder instructies die allemaal in een enkele cycle uitgevoerd kunnen worden. Bovendien worden alle instructies in de registers bewaard)
EPIC (meerdere instructies worden door de compiler in lange 64b opdrachten omgezet)

x86 is in beginsel een CISC ontwerp uit de jaren '70. CISC wordt doorgaans als minder efficient dan RISC bestempeld. Toch is met uitzondering van medio jaren '90 (de vroege Alpha's) nooit een enorm performancegat geweest tussen CISC iha (en x86 in het bijzonder) en RISC. Deels komt dat door aanpassing van x86 met een RISC core (de microcode vertaalt de x86-standaard CISC code naar RISC instructies), maar deels ook doordat RISC simpelweg andere inefficienties toevoegt (om te beginnen dat je meer instructies nodig hebt voor een willekeurige taak). Intel besloot daarom een andere koers in te slaan met EPIC. Dat zou de nadelen van RISC omzeilen en een superieure performance garanderen. Helaas is de Itanium (de enige CPU die gebruik maakt van EPIC) geen enorm succes- de beloofde prestaties blijven uit en daarom slaat het ook nauwelijks aan.


Even een overzichtje (niet volledig) non-x86 architecturen:

CISC:

- Z80: afgeleid van de oudere Intel 8008 8b-ontwerp. Voor de IBM PC was dit de dominante architectuur met Digital's CP/M als OS of choice. Ook gebruikt in veel homecomputers (Sinclair, MSX etc.)

- 68x: Motorola 16/32b CPUs, de directe concurrent van de x86 reeks. Gebruikt in veel Unix workstations als directe opvolger van Z80 systemen, in de Atari ST en Commodore Amiga en vroegere Apple Macintoshes.

- VAX: nooit echt op de desktop beland, VAXen waren in de jaren '80 veruit de meest populaire minicomputers, toentertijds de ruggegraat van het internet. Meest extreme (en laatste grote) CISC ontwerp.


RISC:

- MIPS: de eerste commerciele RISC CPUs, worden nog steeds doorontwikkeld. Vrijwel alle oudere SGI systemen waren MIPS-based, bovendien draaien N64 en Playstation2 consoles hierop. SInds de R10000 64b

- ARM: Archimedes RISC Machine. Aanvankelijk alleen door Acorn gebruikt, later als aparte bedrijf de CPU of choice voor embedded apps. Intel's XScale CPUs gebruiken ARM architectuur. Goede kans dat je mobiele telefoon op een ARM draait

- SPARC: de CPUs waar Sun groot mee werd (vervingen eerdere 68x ontwerpen). Sun ontwikkelt ze nog steeds, momenteel met de 64b UltraSparc IV CPUs

- Power: IBM's tweede RISC ontwerp. Aanvankelijk alleen in mainframes ingezet, maar na modificatie tot PowerPC succesvol als CPU voor nieuwere Apples (en veel auto boordcomputers). Bovendien heeft de Xbox360 een drietal PowerPC cores aan boord, wat vermoedelijk meer dan compenseert voor het wegvallen van Apple als klant.

- PA-RISC: HP had ook een RISC CPU nodig voor high-end apps. De PA-RISC staat er vooral bekend om een wel erg uitgebreide instructieset te hebben, groter dan bij sommige CISC ontwerpen. HP heeft de PA-RISC obsolete verklaard en ontwikkelt samen met Intel aan de Itanium, al is de toekomst van die samenwerking allerminst helder.

- Alpha: het bewijs dat goede techniek niet succes op de markt levert. Digital's Alpha stond vrijwel direct bij introductie kop en schouders boven andere CPUs uit qua performance. De eerste 64b CPU op een enkele chip, 50 tot 100 procent hogere clock speeds dan x86 op dat moment kon leveren en bovendien een beest van een FPU. OS support was ook goed, zowel VMS (van de oudere VAXen), Unix als WIndowsNT (er is zelfs een RC van Win2K voor Alpha verschenen) waren aanwezig. Anno 1995 was de snelste Intel CPU de Pentium 120. Op dat moment kon je een Digital Alphastation 266 kopen die inderdaad op 266MHz draaide - en bovendien clock-for-clock een veel sterkere FPU had. Waarom draaien we niet allemaal Alpha's dan? Omdat Digital de Alpha zo waardeloos in de markt gezet heeft dat niet alleen de architectuur niet breed opgepakt is, maar Digital er zelf aan te gronde ging (wat voor de 20+ jaar lang onbetwistte #2 in computers (achter IBM natuurlijk) opmerkelijk is). Toch heeft de Alpha de val van DEC overleefd. Compaq heeft de CPU afdeling opgekocht en heeft de Alpha mondjesmaat doorontwikkeld, wat x86 en PowerPC (en overigen) de kans gaf de achterstand in te halen. Na de overname van Compaq door HP is de Alpha officieel dood verklaard (HP wil niet aan meerdere CPU architecturen werken en ontwikkelde al de Itanium). Toch leven delen ervan voort. AMD heeft licentie genomen op de FSB van de Alpha, de EV6 bus van Athlon SlA en SoA systemen is gewoon een Alpha bus (en omgekeerd werden AMD 750 'Irongate' chipsets voor Alpha workstations gebruikt). En de FPU van de Athlon die tegen iedereens verwachtingen bij verschijning sterker bleek dan Intels tot dan toe (onder x86) onaantastbare FPU performance is door dezelfde team ontworpen die de Alpha FPU ontwierpen


EPIC:

De Itanium.


Geen ideel hoe het met de Cell zit, heb ik me nog onvoldoende in verdiept hoe het daar met instructieset etc. zit, het concept van parallelle cores zit op een ander vlak en zegt dus weinig over instructieset. Wel zal het door die parallellisme erg afhankelijk zijn van goede compilers (net zoals de Itanium, maar dan om andere redenen).

[Soultaker]

De essentie:
• de IA-32 instructieset blijft bestaan zolang er heel veel software voor is die veel gebruikt wordt;
• moderne IA-32 CPU's zijn niet ontzettend traag, omdat ze die instructies intern omschrijven naar RISC microinstructies alvorens ze uit te voeren.

Dat tweede punt is eigenlijk al de emulatie die je voorstelt; moderne IA-32 processoren voldoen dus al aan jouw voorstel.

[ThunderNet]

Soultaker schreef op zondag 04 december 2005 @ 00:21:
De essentie:
• de IA-86 instructieset blijft bestaan zolang er heel veel software voor is die veel gebruikt wordt;
• moderne IA-86 CPU's zijn niet ontzettend traag, omdat ze die instructies intern omschrijven naar RISC microinstructies alvorens ze uit te voeren.

Dat tweede punt is eigenlijk al de emulatie die je voorstelt; moderne IA-32 processoren voldoen dus al aan jouw voorstel.

fout
je haalt de termen door elkaar

IA32 = Intel Architecture 32 bits. Beter bekend als de i386 en hoger. en ook bekend als x86
IA64 = Intel Architecture 64 bits. Compleet opnieuw ontwerpen, extreem snel (8 instructies parralel uit te voeren) Echter NIET compatibel met IA32, alleen via emulatie wat dus in het begin erg langzaam werkte.

[DaCoTa]

dion_b schreef op zondag 04 december 2005 @ 00:15:
Fundamenteel gezien zijn er 3 soorten CPU archtectuur:
[BLA]

offtopic:
Heb je in je onderbewuste toevallig bedacht dat een artikel over verschillende architecturen heel mooi in de FAQ zou passen?

[dion_b]

DaCoTa schreef op zondag 04 december 2005 @ 00:27:
[...]

offtopic:
Heb je in je onderbewuste toevallig bedacht dat een artikel over verschillende architecturen heel mooi in de FAQ zou passen?

Een artikel zeker, maar dan wel een betere dan mijn (uit de losse pols geblaatte) post hierboven. Er staat trouwens wel een erg mooie artikel over RISC op de Wikipedia:

http://en.wikipedia.org/wiki/RISC

Over CISC is er natuurlijk ook eentje:

http://en.wikipedia.org/wiki/CISC

_{Al liggen de Wiki servers er momenteel uit - jammer, want er waren meer artikelen over CPU architectuur e.d. die ik nog niet gelezen had}

Edit:
Woei, Wiki is weer up. Een link ervandaan naar de moeder aller usenetposts (dat is pas echt een FAQ) over CISC vs RISC:

http://groups.google.com....arch/msg/e86bb8d069bf56a6

Let op dat hoewel die post 8 jaar oud is, op dat moment RISC en CISC al 10 jaar naast elkaar bestaan hadden (en x86 was al 20 jaar oud...)

[ Voor 20% gewijzigd door dion_b op 04-12-2005 01:10 ]

[Soultaker]

ThunderNet schreef op zondag 04 december 2005 @ 00:24:
fout
je haalt de termen door elkaar

Nietus, het was een typefoutje.

IA64 = Intel Architecture 64 bits. Compleet opnieuw ontwerpen, extreem snel (8 instructies parralel uit te voeren) Echter NIET compatibel met IA32, alleen via emulatie wat dus in het begin erg langzaam werkte.

Het probleem met IA-64 is dat het nou niet écht extreem snel is, zeker niet vergeleken met x86-64 processors. Ik vraag me dus sterk af of er echt toekomst in zit.

[dion_b]

Soultaker schreef op zondag 04 december 2005 @ 01:34:
[...]

Nietus, het was een typefoutje.


[...]

Het probleem met IA-64 is dat het nou niet écht extreem snel is, zeker niet vergeleken met x86-64 processors. Ik vraag me dus sterk af of er echt toekomst in zit.

IA64 heeft twee grote problemen die samen een kip-ei situatie maken:

- EPIC/VLIW is erg compiler-afhankelijk. Dat is natuurlijk ieder architectuur, maar bij EPIC gaat het zo ver dat de compiler de volgorde waarin instructies aan de CPU aangeboden worden bepaalt. Zodoende staat of valt de hele performance van de CPU bij de beschikbare compiler. Voor de Itanium is er eigenlijk maar een goed compiler, die van Intel/HP (gcc voor IA64 zit nog in de kinderschoenen). Op zich staat Intel bekend als ontwikkelaar van zowat de beste compilers op de markt, maar zelfs een gigant als Intel heeft tijd nodig om de boel geoptimaliseerd te krijgen. IA64 heeft 20 jaar achterstand op IA32, maar de verwachtingen van klanten zijn gelijk

- klanten zijn in beginsel niet geinteresseerd in wat er onder de motorkap zit, ze willen goede performance voor hun geld. En ze willen niet al hun bestaande software dumpen. IA64 heeft relatief weinig native software (zeker de specialistische, proprietary dingen waar bedrijven prat op gaan) dus is het aangewezen op IA32 emulatie. Die werkt en is gelukkig lang niet meer zo brak als bij de eerste Itanium, maar het blijft veel trager dan native IA64 en trager dan gelijk (of lager!) geprijsde IA32, al dan niet x86-64 , CPUs. Dus zullen de meeste klanten gewoon de goedkopere en/of beter presterende systemen nemen.

Dus kleine user base, dus weinig native apps, dus ook minder investeringen in de compilers, dus achterblijvende performacen dus...

[Soultaker]

dion_b schreef op zondag 04 december 2005 @ 02:45:
- EPIC/VLIW is erg compiler-afhankelijk. Dat is natuurlijk ieder architectuur, maar bij EPIC gaat het zo ver dat de compiler de volgorde waarin instructies aan de CPU aangeboden worden bepaalt. Zodoende staat of valt de hele performance van de CPU bij de beschikbare compiler. Voor de Itanium is er eigenlijk maar een goed compiler, die van Intel/HP (gcc voor IA64 zit nog in de kinderschoenen). Op zich staat Intel bekend als ontwikkelaar van zowat de beste compilers op de markt, maar zelfs een gigant als Intel heeft tijd nodig om de boel geoptimaliseerd te krijgen. IA64 heeft 20 jaar achterstand op IA32, maar de verwachtingen van klanten zijn gelijk

Ik denk dat het een misvatting is om te denken dat je met 20 jaar research de prestaties van een compiler fundamenteel kunt verbeteren. Dat is met de IA-32 architectuur tenslotte ook niet echt gebeurt; maar ik zou daar graag wat bronnen van zien (ik baseer me zelf op mijn eigen ervaringen). De vooruitgang zit 'm vooral in de implementatie van de processoren, die de ouderwetse x86-code op een steeds handigere manier zijn gaan uitvoeren, en natuurlijk de introductie van extra instructiesets en extra registers.

De optimalisaties die jij noemt, die een voordeel zijn van het EPIC ontwerp, zijn ongeveer dezelfde optimalisaties die de IA-32 processors nu in hardware uitvoeren: branch prediction, out of order execution, dat soort dingen. Hoewel de analyse die een Pentium 4 doet voor een processor erg geavanceerd is, is het vanuit optimalisatieoogpunt vrij primitief (zoals élke techniek zal zijn die op de processor geïntegreerd is). Het is vrij makkelijk om de analyse die een Pentium 4 of AMD64 uitvoert in software om te zetten en dan nog flink te verbeteren en ik ben er van overtuigd dat de Intel compiler dat ook doet.

De IA-64 processor hoeft dus alleen nog maar de code uit te voeren en kan de analyse aan de compiler overlaten. Waarom zou de IA-64 dan achterblijven qua prestaties?

[dion_b]

Soultaker schreef op zondag 04 december 2005 @ 15:05:
[...]

Ik denk dat het een misvatting is om te denken dat je met 20 jaar research de prestaties van een compiler fundamenteel kunt verbeteren. Dat is met de IA-32 architectuur tenslotte ook niet echt gebeurt; maar ik zou daar graag wat bronnen van zien (ik baseer me zelf op mijn eigen ervaringen). De vooruitgang zit 'm vooral in de implementatie van de processoren, die de ouderwetse x86-code op een steeds handigere manier zijn gaan uitvoeren, en natuurlijk de introductie van extra instructiesets en extra registers.

De optimalisaties die jij noemt, die een voordeel zijn van het EPIC ontwerp, zijn ongeveer dezelfde optimalisaties die de IA-32 processors nu in hardware uitvoeren: branch prediction, out of order execution, dat soort dingen. Hoewel de analyse die een Pentium 4 doet voor een processor erg geavanceerd is, is het vanuit optimalisatieoogpunt vrij primitief (zoals élke techniek zal zijn die op de processor geïntegreerd is). Het is vrij makkelijk om de analyse die een Pentium 4 of AMD64 uitvoert in software om te zetten en dan nog flink te verbeteren en ik ben er van overtuigd dat de Intel compiler dat ook doet.

De IA-64 processor hoeft dus alleen nog maar de code uit te voeren en kan de analyse aan de compiler overlaten. Waarom zou de IA-64 dan achterblijven qua prestaties?

Bedankt voor de uitdaging dit uit te zoeken

Hier een erg uitgebreid artikel:
http://www.anandtech.com/...s/showdoc.aspx?i=2598&p=2

Probleem met compilers is inderdaad vooral hardwaregerelateerd - omdat de instructies gemiddeld 41.3b lang zijn tegenover ergens net boven de 24b voor x86 is er behoorlijke bloat, dat wordt verergerd door het feit dat bepaalde combinaties van instructies niet samen in een enkele VLIW passen, waardoor soms een of zelfs twee lege 'placeholder' instructies erin moeten. Bij Itanium I leverde dit tot 2.5x grotere executables op (waardoor I/O dus zwaarder belast werd), al is het door meer toegelaten combinaties op de Itanium II minder relevant geworden en zijn de executables 'maar' 50% groter dan x86.

Anantech is in ieder geval optimistisch over Itanium/EPIC op de lange termijn, zolang het maar de korte termijn desinteresse weet te overleven.

[Seal64]

dion_b schreef op zondag 04 december 2005 @ 00:15:- ARM: Archimedes RISC Machine. Aanvankelijk alleen door Acorn gebruikt, later als aparte bedrijf de CPU of choice voor embedded apps. Intel's XScale CPUs gebruiken ARM architectuur. Goede kans dat je mobiele telefoon op een ARM draait

Ik weet in ieder geval één systeem waar ARM processoren in zitten en dat verkoopt als een razende... De Game Boy Advance en de Nintendo DS draaien allebei op een ARM processor. De DS heeft er zelfs twéé.

[Verwijderd]

de Netbook pro (zit tussen palmtop en laptop in) van psion teklogix draait er dacht ik ook op.

[dion_b]

Kleine updateje:

De Cell is wat instructieset betreft 'gewoon' een IBM PowerPC ontwerp, met een normale Power core die alle SPEs aanstuurt en het interface vormt voor OS. Het vernieuwende van de Cell is de secundaire cores met elkaar in contact staan en de load verdelen.

http://en.wikipedia.org/wiki/Cell_%28microprocessor%29

[ShadowLord]

killingdjef schreef op zaterdag 03 december 2005 @ 22:44:
Wat ik ervan begrepen heb is dat Cell, door zijn multi-cores, alleen echt rendabel is als ze ook daadwerkelijk gebruikt worden.

Dit betekend multi-thread programming en laat dit nou net ongelooflijk complex zijn (in de huidige staat van schrijven!). De support voor programmers over multi-thread programming is beroerend slecht, terwijl de techniek er is is het gewoon nog moeilijk om toe te passen. Als dit opgelost is dan zie ik zelf zeker wel de toekomst in Cell.

Het probleem met de Cell is niet zo zeer dat hij multi-threading nodig heeft. Steeds meer devs leren efficient met multithreading om te gaan, zeker nu multi-core processors de norm gaan worden.
Het probleem van de Cell is echter dat hij kieskeurig is met multithreading. De cores van de Cell zijn namelijk niet allemaal gelijk. De theorie erachter is dat je bij processor intensieve taken relatief weinig functionaliteit gebruikt, maar vooral data aan het pushen/transformere bent. Echter kan de programmeur daardoor niet 'willekeurig' code in zijn threads zetten (zoals met een multi-core processor wel kan), maar zal hij rekening moeten houden met welke instructies er in welke thread uitgevoerd gaan worden en wat dit voor impact op de preformance heeft. Dit heeft een erg steile leercurve en het zal dan ook even duren voordat de men de Cell maximaal kan benutten. En ook dan zal het lastig code blijven.

Daarom denk ik zelf dat de Cell niet terug gevonden zal worden in desktop settings. Voor een paar euro meer heb je een (theoretisch) bijna net zo krachtige general purpose processor die je simpel kan programmeren (dus in de praktijk beter zal functioneren, voor minder ontwikkelkosten).