Intel denkt na over Cell-achtige processors

Intel heeft in een presentatie over zijn strategie met betrekking tot dual- en multiprocessors een interessant idee uiteengezet voor mogelijke toekomstige producten, dat qua concept erg lijkt op hetgeen IBM, Sony en Toshiba met hun Cell-processor gaan doen. De eerste multi-cores die volgend jaar op de markt komen zullen simpelweg één of een paar kopieën van hetzelfde ontwerp bevatten. Vanwege beperkingen op het gebied van warmte kan hier echter niet heel erg ver mee gegaan worden. Om acht cores binnen een 100 Watt TDP te houden mogen deze bijvoorbeeld niet meer dan 12,5 Watt per stuk verstoken. Er zijn nog steeds genoeg technieken in ontwikkeling die toekomstige x86-cores in staat zullen stellen om beter om te gaan met stroom, maar die gaan vrijwel allemaal ten koste van extra transistors. Hierdoor worden de cores steeds groter en complexer, en passen er dus ook minder op een plakje.

Toch denkt Intel dat processors met tientallen of zelfs honderden cores op één chip mogelijk zijn. Dit zou dan bereikt worden door een groot aantal kleine en zuinige, maar vooral ook zeer gespecialiseerde onderdelen aan de chip toe te voegen. Eenheden die van de grond af opgebouwd zijn om één bepaalde taak of berekening zeer snel uit te voeren, om theoretisch aan vele teraflops te komen. De valkuil is natuurlijk dat deze eenheden wel gebruikt moeten worden door de software, en bovendien ook niets anders kunnen dan die ene taak waar ze voor gebouwd zijn. Naast alle gespecialiseerde cores zullen er dus gewone cores blijven bestaan, hoewel er dat in verhouding steeds minder zullen worden.

Hoewel over Cell nog niet alles bekend is, weten we dat het idee in ieder geval overeenkomt met Intels visie over de toekomst van multi-coreprocessors. Hoewel er lange tijd erg vaag is gedaan over de architectuur van Cell en zijn prestaties, weten we nu dat het in wezen een PowerPC-processor is. De geclaimde performance komt vooral op rekening van een aantal extra Altivec-achtige units die rond de hoofdcore zijn geplakt.

Reacties (62)

[Verwijderd]

multicore is allemaal leuk en aardig, maar dit soort extreme multicore chips kunnen toch nooit echt doorbreken? ik verwacht echt niet dat alle applicaties in de toekomst ineens spontaan multithreaded geschreven gaan worden, omdat dat gewoon veel te veel gezeik oplevert in 't ontwikkelproces... dus wat moet je dan met honderden cores als er 30 processen draaien, waarvan 5 echt actief bijvoorbeeld?

kan iemand toelichten waarom dit dan toch interessant zou zijn voor de toekomst? of moet ik 't helemaal niet in de x86 richting zoeken?

[Verwijderd]

Misschien dat nieuwe compilers er voor kunnen zorgen dat applicaties automagisch multithreaded worden. Stel dat je 10 verschillende berekeningen achter elkaar hebt die niks met elkaar te maken hebben. Dan zouden de berekeningen verdeeld kunnen worden over 10 van die kleine processoren.

[Verwijderd]

was 't maar zo makkelijk.. maar helaas, dat is 't niet.. je hebt wel programmeertaalvarianten (Pascal-FC is een mooi voorbeeld) waarin je in een iteratief stuk code kunt aangeven van waar tot waar de volgorde van de code niet uitmaakt (en het dus wellicht tot op zekere hoogte parallel uitgevoert kan worden), maar dit gaat altijd maar om hele miniscule kleine stukjes code en daar wil je echt geen threads voor aanmaken.. het schedulen ervan kost meer tijd dan de winst die je behaalt door het parallel uitvoeren. deze programmeertalen zijn volgens mij ook meer voor studie-doeleinden bedoeld dan voor serieus gebruik.

[knirfie244]

Ik denk dat de voornamelijke markt hierbij de server/workstation markt is, waar je wel degelijk heel veel threads tegelijk kan hebben lopen, en verder kunnen compilers heus nog wel wat aangepast worden om meer gebruik te maken van meerdere threads zonder t veel ingewikkelder te worden...


Volgens jou zou de CELL processor dus ook totaal geen performance leveren,en zouden al die 1000+ CPU supercomputers dus ook helemaal niets kunnen...

[boner]

hoe was de verhouding ook weer? 80% van de tijd is maar 20% van de code actief? Dus als je de moeite zou nemen om dat stukje voor MT te optimaliseren, ben je al een heel eind.

[Mijzelf]

Inderdaad. De Intel c++ compiler kan dat helemaal automagisch. Het wordt dan Auto-Parallelization genoemd.
http://www.intel.com/software/products/compilers/cwin/index.htm

[Superstoned]

ik neem aan dat er ook gewoon meer threads gebruikt kunnen worden door de software. om maar wat te noemen, beos' programmeeromgeving zorgde dat je snel meer threads ging gebruiken voor bijv. delen van de gui zodat het sneller aanvoelde. QT 4 (C++ toolkit van trolltech, gebruikt oa in KDE 3) zal op een vergelijkbare manier werken, en zo als het een beetje meezit je desktop omgeving een stuk lekkerder laten aanvoelen...

[Cybje]

Veel applicaties die dit gaan gebruiken/nodig hebben zijn al multithreaded waarschijnlijk, gezien ze naar nu gewoon SMP systemen of clustering voor gebruiken. In de meeste gevallen heb je anders de CPU power niet nodig, die een multi core oplossing biedt.

[Verwijderd]

voor servers, ideaal, tientallen database threads (of geforkte processen), tientallen webserver threads, etc... maar voor de PC? ik zie 't nut niet echt.

[Verwijderd]

Tsja als je alleen maar surft en af en toe een emailtje tikt, maakt het allemaal niet veel uit, maar ik zou het best lekker vinden als er een aantal cores bijkomen. Eentje die een divx-je sdtaat te renderen eentje voor het geluid, een paar voor p2p een paar voor mijn ftp servertje. enz enz als dat dynamisch gaat, is het allemaal nog beter.

Ik vraag me af wat de vogende gen gaat worden. Maincores en subcores, high priority processen op MC en andere zaken toewijzen aan subcores ofzo. Lijkt me ook wel weer een leuke ontwikkeling.

[bzerk]

ik verwacht echt niet dat alle applicaties in de toekomst ineens spontaan multithreaded geschreven gaan worden, omdat dat gewoon veel te veel gezeik oplevert in 't ontwikkelproces

Spontaan niet. Maar parallelisme is de enige weg naar steeds meer capaciteit. Miniaturisering houdt namelijk een keer op. Het ontwikkelproces zal vanzelf wel de ontwikkeling van de hardware volgen.

[Verwijderd]

ook dsp solutions gaan daar gerust graag gebruik van maken... eindelijk de mogelijkheid om met een proc veel zaken parallel te doen en kan nog competitie worden voor de fpga's ....

[Verwijderd]

ik verwacht echt niet dat alle applicaties in de toekomst ineens spontaan multithreaded geschreven gaan worden, omdat dat gewoon veel te veel gezeik oplevert in 't ontwikkelproces... dus wat moet je dan met honderden cores als er 30 processen draaien, waarvan 5 echt actief bijvoorbeeld?

Het gaat hier niet zo zeer om het aantal processen dat je actief hebt draaien, maar om de taken die de processen uitvoeren. Bepaalde berekeningen/gespecialiseerde taken kunnen worden uitgevoerd door daarvoor gespecialiseerde cores. In de tijd dat die gespecialiseerde cores gebruikt worden, worden de 'standaard' cores niet belast, en doordat deze monder belast worden worden ze minder heet. Zo kan je dus 100den cores op een CPU inbouwen, die 'om en om' hun eigen taakje uitvoeren (waarbij de 'standaard' cores de taken uitvoeren waar geen gespecialiseerde cores voor zijn gebouwd), waardoor de totale CPU niet te warm wordt, maar toch zeer veel berekeningen per seconde kan uitvoeren.
Ik verwacht dat we deze techniek dan ook vooral veel zullen gaan zien in combinatie met een andere ontwikkeling, namelijk variabele clocksnelheden. Over het algemeen kunnen CPUs namelijk op hogere snelheden lopen dan ze op dit moment doen. Alleen niet doorlopend. Zo zou je dus voor korte taken en piektijden je CPU even kort op een twee keer zo hoge cloclsnelheid laten lopen. Dit is zeer goed toe te passen op dergelijke multicore CPUs, waarbij veel cores een groot deel van de tijd op non-actief kunnen worden gezet, en zo ook geen warmte veroorzaken.

[^Mo^]

Hoezo zou het veel gezeik opleveren tijdens het ontwikkelproces? Als het nu voor dual systemen werkt, dan werkt hetzelfde principe ook voor meerdere cores...

[Verwijderd]

multithreaded programmeren is geen pretje. dat is niet mijn mening of zo, 't is gewoon een feit dat de hele wereld zal beamen.

dat geldt voor een dual-cpu systeem net zo zeer als voor een 256-cpu systeem van mijn part..

ik zie 't niet gebeuren dat in de komende 15 jaar een meerderheid van de applicaties multi-threaded gaat worden..

[Mijzelf]

multithreaded programmeren is geen pretje. dat is niet mijn mening of zo, 't is gewoon een feit dat de hele wereld zal beamen.

Nou, ik beaam het niet. Als beroepsprogrammeur heb ik zowel single- als multithreaded programma's geschreven, en ik kan je zeggen dat ik dolblij ben met multithreaden. Wanneer je een een of ander communicatieprotocol moet afhandelen, en ondertussen je gebruikersinterface responsief moet houden moet je in de singlethreaded situatie heel veel werk verrichten qua timing en boekhouding om alles soepel in elkaar te laten lopen, terwijl je tegenwoordig gewoon een aparte thread start om die communicatie netjes af te handelen.

ik zie 't niet gebeuren dat in de komende 15 jaar een meerderheid van de applicaties multi-threaded gaat worden..

Ik weet niet welk OS je gebruikt, maar als het XP is, moet je de taskmanager eens opentrekken. Voeg het kolommetje 'threads' toe, dan kun je zien dat de meeste programma's multithreaded zijn.

[Verwijderd]

Of multithreaded programming een pretje is of niet, hangt ook van de onderliggende hardware en van de development tools af.
Kijk maar 's naar de INMOS Transputer van 20 jaar geleden. Die was helemaal gemaakt voor 'parallel computing' (oftewel multithreading), en met de daarop toegesneden compiler Occam moest je al heel erg je best doen om NIET multithreaded te programmeren.

Helaas is de Transputer nooit mainstream geworden. Atari heeft 't wel geprobeerd met de ATW800, maar voor zover ik weet is dat ding nooit echt op de markt gekomen.

[player-x]

ik denk dat de meeste het verkeerd zien hier
het gaat denk ik niet om dat het heele programa multithreaded geprogrammeerd wordt
maar gewoon een klein deel

de CPU blijft maar krijgt hulp van hulp prosessors die een veel voor komende routines uitvoerd een soort SSE maar dan veel uitgebreider

neem bv een zip file je kan makkelijk 10 modules tegelijk laaten rekenen op een compresie

[Verwijderd]

je hoort mij niet zeggen dat threads geen voordelen hebben vooral in netwerk apps pas je ze natuurlijk regelmatig toe.. maar dan dus vooral om sockets te onderhouden.. en in zo'n geval levert dat over 't algemeen nou niet bepaald veel performancewinst op, waar je met 100 cores natuurlijk wel op zit te wachten.

mijn punt is basically.. als je veel "rekenwerk" hebt, is dat moeilijk te spreiden over cores aangezien multithreading dan snel roet in 't eten gooit t.o.v. een iteratieve aanpak.

[Aaargh!]

mijn punt is basically.. als je veel "rekenwerk" hebt, is dat moeilijk te spreiden over cores aangezien multithreading dan snel roet in 't eten gooit t.o.v. een iteratieve aanpak.

Ligt er helemaal aan wat voor rekenwerk je moet doen, sommige dingen zijn ontzettend goed te paralleliseren, sommige niet.

Als je threads over meerdere cores kan verdelen beperk je daarmee ook het aantal benodigde context-switches die relatief duur zijn.

[Verwijderd]

Dit is ideaal voor servers, waar meerder requests tegelijk in een database gaan zoeken.

Een hoop applicaties (ook multi-player games) kunnen hier van profiteren

[BramT]

lol... multi-threading heeft toch geen drol met multi-player te maken

Verder zullen de requests waar je het over hebt rekentechnisch erg veel op elkaar lijken en in het artikel hebben ze het juist over "mini"-cores die ieder een eigen specifieke taak hebben.

Applicaties kunnen hiervan natuurlijk profiteren, maar alleen in bepaalde omstandigheden. Zie de posts hierover hierboven...

[Olaf van der Spek]

ik verwacht echt niet dat alle applicaties in de toekomst ineens spontaan multithreaded geschreven gaan worden, omdat dat gewoon veel te veel gezeik oplevert in 't ontwikkelproces...

Veel apps zijn ook niet CPU-bound, dus dat komt mooi uit. ;->
Verder worden apps (die het nodig hebben) echt wel multi-threaded als iedereen straks dual- of multi-core CPUs heeft.

[Verwijderd]

Waarom?

Zodra de grens bereikt wordt van de maximale snelheid te bereiken door 1 processor (of gewoon goedkoper), vanaf dat moment wordt multi core interessant.

Sparks

[Verwijderd]

Als je het nu gewoon simpel vanaf de andere kant bekijkt, dan is het snel te zien dat dit soort CPUs de toekomst hebben.

Spelletjes: Een CPU kan gemakkelijk vele DirectX en OpenGL functies direct in hardware uitvoeren, buiten het feit dat de GPU dit doet. Multi-threading is vaak standaard in alle moderne spelen, denk alleen al aan het tegelijk bijhouden van inputs, beeld en netwerk. Maar vooral in de 3D-engines gaat het een stuk verder. Frames worden tegenwoordig al voorberekend voordat ze feitelijk nodig zijn, multi-threading is hier ideaal voor.

Video: Vooral het encoderen van DivX/etc kan zeer versneld worden als bepaalde rekenformules in hardware vorm verwerkt worden in de CPU. Buiten het feit dat er vaak aan meerdere video-frames tegelijk kan worden gerekent.

Database: Ik ken weinig situaties waarbij er maar één database thread tegelijk gebruikt wordt, bijna alle SQL varianten hebben leuke tools om te laten zien wat de thread-count is. Net effe gekeken op één van mijn MySQL servers en de thread-count zit te schommelen rond de 18,000.


De hardwarematige invoeging van bepaalde wiskundige formules zal de grootste winst opleveren. Er zijn namelijk al vele toepassingen hiervoor die dit aantonen (dedicated video en/decoders, DSP, etc). En er zullen dan inderdaad situaties voorkomen, waarbij er voor een hoop gebruikers onnodige circuits in een CPU zitten, maar voor een algemene verhoging van de prestatie blijft dit de beste manier.

[oeLangOetan]

Spelletjes: Een CPU kan gemakkelijk vele DirectX en OpenGL functies direct in hardware uitvoeren, buiten het feit dat de GPU dit doet. Multi-threading is vaak standaard in alle moderne spelen, denk alleen al aan het tegelijk bijhouden van inputs, beeld en netwerk. Maar vooral in de 3D-engines gaat het een stuk verder. Frames worden tegenwoordig al voorberekend voordat ze feitelijk nodig zijn, multi-threading is hier ideaal voor.

hm, misschien moet je ff je 3d-engines voor dummys boek bovenhalen en zien hoe echt werkt.
Muli-theading gaat misschien volgend jaar, en vooral vanaf 2006 zijn intrede doen in enkele 3d engines (Quake 2 en UT zijn de enige games met experimentele smp die ik ken, er werd btw geen performance winst mee geboekt). Tegenwoordig wordt er nog sterk geëxperimenteerd met meerdere threads in games, de techniek die het gaat halen is waarschijnlijk micro-tasking hoewel ik al heb gehoord dat sommigen zelf volledig distributed gaan schrijven. Het grote probleem van deze technieken is dat ze veel moeilijker zijn dan single threads. Je moet meestal een efficiënte en goed gebalanceerde scheduler schrijven die de taken rangschikt volgens prioriteit & erin slaagt gelijksoortige taken samen te groeperen rekeninghoudend met geheugen beschikbaarheid & vele andere factoren. Je ziet al snel dat het probleem veel ingewikkelder is dan men over het algemeen denkt. Bovendien is je programma niet de enige client van de cpu(s), ook drivers & besturingssysteem vragen hun processortijd. Hoewel het hier veel gesuggereerd wordt kun je ook geen threads reserveren voor een bepaald proces (bv het geluid), dat vertraagt je systeem aangezien je ofwel processortijd verspilt ofwel een bottleneck creëert. Hoewel het als programmeur een leuke mannier van werken is (het is een nieuwe manier van denken ) maar het verdubbelt de ontwikkelingstijd.

Video: Vooral het encoderen van DivX/etc kan zeer versneld worden als bepaalde rekenformules in hardware vorm verwerkt worden in de CPU. Buiten het feit dat er vaak aan meerdere video-frames tegelijk kan worden gerekent.

De hardwarematige invoeging van bepaalde wiskundige formules zal de grootste winst opleveren. Er zijn namelijk al vele toepassingen hiervoor die dit aantonen (dedicated video en/decoders, DSP, etc). En er zullen dan inderdaad situaties voorkomen, waarbij er voor een hoop gebruikers onnodige circuits in een CPU zitten, maar voor een algemene verhoging van de prestatie blijft dit de beste manier.

GENERAL processing unit, geen DEDICATED processing unit, daarvoor heb je insteekkaartjes Bovendien wordt er alleen naar zulke toepassingen gekeken als ze economisch verantwoord zijn. Het is de bedoeling om de grootte van de cpu zo klein mogelijk te houden voor betere algemene prestaties (zowel economisch als feitelijke prestaties).

[Verwijderd]

hm, misschien moet je ff je 3d-engines voor dummys boek bovenhalen en zien hoe echt werkt.

Of misschien moet jij eerst beter lezen. Ik had het erover dat op dit moment de meeste moderne spelen zelf multi-threading zijn, oftewel multi-thread voor invoed/beeld/geluid/netwerk/etc. De 3D-Engine echter is in de toekomst uitermate geschikt voor multi-threading (voorzover dat al niet gedaan wordt, want ik kan me toch echt white-paper artikelen herinneren bij Unreal en ID3 waarbij op dit moment al wordt gemultitasked in de engine).

GENERAL processing unit

Voor een PC blijft het nog steeds een CPU (Central Processing Unit) embedded met een FPU (Floating Point Unit) die wordt gecombineerd met een GPU (Graphical Processing Unit). Waar het om gaat is dat de ontwikkeling stagneert kwa preformance en dat Intel en vele andere bedrijven andere methodes aan het ontwikkelen zijn om dit te overbruggen. Het artikel gaat tenslotte over de Cell processor ontwikkeling. Aangezien de migratie van Computer/TV/VCR/DVR/etc steeds verder gaat is het natuurlijk veel goedkoper om dedicated circuits te combineren met bestaande circuits.

Je kan dan wel met insteekkaartjes gaan rommelen, maar op dit moment kost een Dedicated MPEG-4 encoding kaart, zoals de VideoSpider SP444 ongeveer $1400, voor enkele dollars meer kan Intel het meerendeel wat dit soort kaarten doen toevoegen aan hun Cell processors.

[oeLangOetan]

Vandaag de dag zijn er helemaal geen moderne engines die gebruik maken van multi-threading.
Kijk naar de source engine van HL2, de cryengine van farcry, the unreal engine 2.5 van ut2004, de doom3 engine... geen enkele gebruikt multi-threading. Engines die momenteel ontwikkeld worden (met de consoles in gedachten) worden nu meestal van de grond af voor multi-threading ontwikkeld)

Dedicated chips hou je het best appart, dat is toch wat ze mij op school wijs maken. Voor die multimedia toepassingen die je aanhaalt heeft intel sse instructies, enige nadeel is dat je (indien je echt goede performance wilt) die code het best in assambly programmeerd.

(plextor heeft een veel goedkopere mpeg4 oplossing dan de videospider)

[Verwijderd]

Iederen loopt nou wel hard te roepen (nou ja een aantal mensen dan he ) dat dit niet zou kunnen werken maar ik denk van wel,

Kijk we moeten er niet van uit gaan dat morgen de processor klaar is en de software, maar op langere termijn als die twee naar elkaar gegroeid zijn kan dat dus best wel. Juist specifieke taken zorgen voor efficienty in een proces, of je nu in je eentje een puzzel in elkaar moet leggen of dat iemand je helpt die de randjes er uit haalt, de lucht apart legt etc, dat scheelt nogal wat.

het is helemaal niet verkeerd om eens van de geeikte paden af te wijken , hoe denk je anders dat al onze hedendaagse uitvindingen zijn ontstaan. anders hadden we nu nog kaarsen als verlichting om maar eens fig. te spreken.

Er zal nog een lange weg te gaan zijn voor we hier iets van gaan merken maar dat is met veel dingen zo.

[n4m3l355]

nou dat is 't 'm nou ook net.. windows noemt het evolutie maar nog voor 2000 zijn servers al multithreading. alleen hun aanpak is 'evolutionair'
wat het voor mij interessant maakt is dat ze juist op de punten waar men meer kracht uit moet pompen dat ze juist daar effecienter te werk gaan en dat daar juist de energie beperking in zit. tevens dat men klaagt over 'er is geen multithreading software en het is o zo lastig' alle server software is zo'n beetje multi-threading dus wat is het probleem? en buiten dat het misschien niet meerdere procs gebruikt het is nog altijd mogelijk om parallel meerdere programma's te draaien. dat zul je ook wel merken. ik merk het in ieder geval wel met mn hyperthreading

[Verwijderd]

't valt wel op dat een hoop mensen hier geen idee hebben waar we in de toekomst snellere computers voor 'nodig' hebben.

Niemand heeft een snellere CPU nodig dan de huidige AMD64 4000+ ofzo. om gewone toepassingen zoals Office, HDTV, Winamp, Firefox, Firebird en ga zo maar door te gebruiken.

Virtual Reality, Artificial Intelligence en server-toepassingen zijn de enige toepassingen die ik kan bedenken waar we processors kunnen gebruiken die duizenden (miljoenen?) keren sneller dan de huidige zijn. En dat zijn precies toepassingen die goed parallel te programmeren zijn.

Als je kijkt naar het mesnelijk brein, is dat ook niet een grote CPU, Het zijn miljarden extreem simpele processortjes met miljarden verbindingen naar elkaar toe.

De echte wereld is zo ongelooflijk complex, dat is niet te simuleren met de huidige snelheid van onze CPU's. Het moet nog vele malen sneller, en dat kan niet door de huidige processors op te voeren. Stel dat je duizend keer sneller wilt dan een P4 3,8 GHz... dan zou je naar de 3800 GHz gaan... dat werkt natuurlijk niet (ook niet als je het ontwerp efficienter maakt).

[Karimpje]

Dat heeft ook ooit iemand geroepen toen de Intel Pentium II 400mhz uitkwam. "Je zult de eerste paar jaar alles kunnen draaien. Programma's zullen de eerste paar jaar niet de volle prestaties van de chip gebruiken, dat is gewoon nog niet nodig."

Nou na een half jaar waren er ineens games met recommended CPU Pentium III 500 en hoger.

Dus dat is echt achterhaald. De hardware is altijd de bottleneck. Zelfs bij een Athlon64 FX-55 of Athlon64 4000+ zit je nog steeds op sommige applicaties te wachten (laadtijd). Zolang dit het geval is blijft het nodig om snellere processors te maken.

En bij de eerste x86 chip die op 1,75 Mhz liep ofzo, had men ook nooit gedacht dat in zo'n 13 jaar de pc's op 3,8 Ghz zou lopen. Dus waarom is 3,8 Thz niet mogelijk??

[Verwijderd]

Het probleem ligt niet aan de hardware maar meer aan de software, software kan veel efficienter. Er wordt vaak geen gebruik gemaakt van geavanceerde mogelijkheden van moderne processoren. En dat komt weer omdat niet iedereen de snelste pc kan kopen. En als ontwikkelaar moet je daar rekening mee houden.

Een tijd terug heb ik een link gepost van iemand die een 64bit encryptie software speciaal voor de Opteron had aangepast, prestatie nam toe met ruim 300% ! Zo valt er met meer software flink veel winst te halen indien je efficient gebruik van de platform maakt.

[player-x]

je hebt heelemaal gelijk als je over normale programa's praat dingen zo als office en IE kun je bijna zo slordig programeeren als je wild vandaag de dag
(zo lang ze maar geen geheugen lekken)
maar als je mij probeert te vertellen dat de engine van HL2 bv of bijna elke andere game niet netjes is geprogrameerd dan denk ik daar toch anders over
niet te praaten over dingen als drivers.

er word nog steedts netjes geprogrameerd zolang het nodig is, maar als het niet nodig is worden mensen lui ja dat klopt.

[Kakaroto]

Aan alles komt een einde, ook aan het x86 ontwerp.

Nu moet intel andere pcb toepassen om de vereiste yields te behalen. 4GHz is al lastig, laat staan 4000GHz.

[player-x]

Dit zou dus ook betekenen dat de XBOX II ook geprogrammeerd zou kunnen worden zo als de normale XBOX
Mits ze door de beveiliging code en hardware heen kunnen komen
Wat er eerst gedacht werd dat de IBM cell processor meer specifiek voor game console zou zijn zo als bij de huidige sony, sega en nintendo

@Dragunov
maar de grafische processor is anders bij de Xbox2, die is nu van ATI, vroeger was die van Nvidia, dus ja

dat maak dus eigenlijk wijnig uit dat is hardware en heeft niks met software temaaken
en er is een kans dat de XBOX II backwards compatible zou zijn met XBOX I

[Smoke]

Alleen gebruikt de Xbox 2 geen Intel CPU maar een IBM PowerPC(Vergelijkbaar met de G5). Om daarop een originele XBox te emuleren is schijnbaar te veel werk(En het draait niet lekker genoeg natuurlijk). Het is volgens mij al een tijdje geleden aangekondigd dat de Xbox 2 niet backwards compatible zou zijn(Terwijl de Nintendo Revolution, de PS3 en de Nintendo DS dat wel zijn)

[player-x]

(Terwijl de Nintendo Revolution, de PS3 en de Nintendo DS dat wel zijn)

dat is presies mijn punt als zij het kunnen moet de XBOX II het ook kunnen want zij gebruiken in de vorige generatie ook een andere CPU

[Verwijderd]

@desktop

voor thuisgebruik zal snelheid nu nog niet van belang zijn zolang de rest van de relatief gezien achter de feiten aan loopt. Voor professioneel gebruik , bv voorspellen en bestuderen van aardbevingen, klimaatveranderingen en weerst en constructie effecten voor gebouwen etc zal het allaan maar meer nodig zijn.

Er zal best wel een punt komen dat het allemaal sneller gaat voor de normale consument ook. bv door stemherkenning, te gebruiken in plaats van een muis in je office documenten etc. Klinkt als toekomstmuziek maar men werkt er al een tijdje hard aan. Als de pc een nog meer centrale plek gaat innemen en meer controle gaat krijgen over het huis is het ook wel zinvol voor controlle processen etc.

offtopic, mischien zou tweakers eens een uitgebreid artikel kunnen maken over de toekomstige ontwikkelingen die er aan staan te komen met de huidige computer technieken, evt in samenwerking met bv intel of amd als ze die kunnne bereiken , zou wel een leuk idee zijn naar mijn mening

[Verwijderd]

<quote>Voor professioneel gebruik , bv voorspellen en bestuderen van aardbevingen, klimaatveranderingen en weerst en constructie effecten voor gebouwen etc zal het allaan maar meer nodig zijn.</quote>

Aardbevingen,het klimaat en het ontwerpen/testen van nieuwe contructies valt allemaal onder virtual reality volgens mij.

Als je kijkt naar de huidige manier van voorspellen van het klimaat/het weer/aardbevingingen, dan zie je allerlei computer-modellen die de realiteit proberen na te bootsen. Bij het ontwerpen en testen van nieuwe constructies zie je hetzelfde.

Het enige verschil met de toekomst zal de hoeveelheid realiteit zijn die in de computer gestopt zal worden. De huidige super-computers zijn niet eens in staat om alle moleculen in een glas water real-time te simuleren, laat staan een hele oceaan.

<quote>bv door stemherkenning, te gebruiken in plaats van een muis in je office documenten </quote>

Stemherkenning valt natuurlijk onder Artificial Intelligence, zonder kunstmatige intelligentie kom je nooit op een niveau van stemherkenning die vergelijkbaar is met wat mensen kunnen.

[Verwijderd]

hmm, aan de hardware zijde zijn ze nu definitief de seriele weg ingeslagen. van AGP naar pci-expres, ATA naar SATA van Dimm naar FB-dimm en de nieuwe verbindingen tussen de north en eventueel southbridge zijn ook serieel en natuurlijk USB en Fire-wire. Alleen de Video kaarten markt houdt zich nog een tijdje staande met paralel geheugen, vertec en pixel shaders.( eigenlijk heb je het hier al over cell achtigen)

Nu willen de cpu makers en daarme Software makers de breedte in met 64 bits multi processors danwel cell achtige stucturen. Wordt wel dringen om dit allemaal paralel af te handelen. zie je het al voor je 64 brede data paden syncroon timen.
Je ziet het al met dual channel ddr en mem controllers in cpu's allemaal extra draden en aansluitingen dit kost zo veel meer dan dit allemaal op een seriele bus te prakken van 3 draadjes.

Ze moeten ook wel, als straks 8 processoren of meer hun data gaan vragen en spuwen,zullen we paralelle seriele verbindingen gaan zien.

Het is gewoon een golfbeweging van de techiek vs geld waamee ze worstelen wanneer wordt de huidige oplossing te duur en is de nieuwe oplossing hiervoor betaalbaar.
Het verder doorklokken zit er nu even niet in met de huidige productie technieken, en de technieken die dit wel mogelijk moeten maken zijn nu nog niet betaalbaar en beschikbaar, willen ze dan toch snel vooruitgang boeken, ze moeten nu wel in de breedte.

Dit wordt een mooie tijd mensen. Parallele 64 bit programma's die elkaar niet in de weg zitten, die plenty bandbreedte hebben om met de buitenwereld te comuniceren. Pc's gaan nog op Apple's lijken.
Als MS z'n best blijft doen natuurlijk.

[Olaf van der Spek]

zie je het al voor je 64 brede data paden syncroon timen.

Dat lukt al sinds de Pentium 1. Wat is het probleem?

[Verwijderd]

Je moet inderdaad erg ver gaan om op een werkstation voordeel te behalen met SMP.
Ik heb jaren met dual CPU systemen gewerkt

De enige applicatie waar ik ECHT kon zien dat beide CPU's gebruikt werden was tijdens het (software) renderen in een 3d applicatie, en een extreem heftige filter bewerking in Photoshop.
De meeste (kleine handige) applicaties voor het omzetten van videobestanden etc. zijn niet SMP.

[Verwijderd]

De meeste (kleine handige) applicaties voor het omzetten van videobestanden etc. zijn niet SMP.

Lees deze pagina(s) eerst dan effe:

http://virtualdub.org/blog/pivot/entry.php?id=18
http://www.microsoft.com/windows/windowsmedia/9series/encoder/faq.aspx #1_2

[Verwijderd]

ik denk dat je de voordelen van multicore chips mischien niet puur moet zoeken in snelheidswinst maar bijvoorbeeld in dingen als flexibiliteit.

zo'n chip kan echt vele processen volledig onafhankelijk laten lopen. en als een tread vastloopt kan mischien een andere core hem opnieuw oppakken zonder dat je os vastloopt.

de grootste voordelen komen waarschijnlijk uit onverwachte hoek en zijn nog mischien nog niet ontdekt.

[Gogar]

Straks worden processors steeds meer zoals hersenen o_o; Steeds meer parallel.
Is het ook niet zo dat transistors veel sneller zijn dan neuronen?

Misschien dat het AI tijdperk nu echt gaat beginnen.

[oeLangOetan]

hersenen = chaos