Intels Mitosis-project onderzoekt speculatief multithreaden

Intel heeft op IDF het Mitosis Project onthuld, een onderzoeksteam dat zich bezighoudt met speculatieve multithreading. Zoals iedereen inmiddels wel weet is het toevoegen van een of meer extra cores in theorie een goede manier op de prestaties te verhogen, maar loopt men in de praktijk vaak tegen het probleem aan dat (makers van) applicaties niet weten hoe ze er gebruik van kunnen maken. Intel bestrijdt dit probleem op verschillende manieren, onder andere door de programmeurs bij te staan met advies en geavanceerde ontwikkelsoftware, zoals de nieuwste versie van de ICC-compiler met helper threads.

Het bedrijf is ondertussen ook druk op zoek naar manieren om de hardware zelf mee te laten werken aan het oplossen van dit probleem, en Project Mitosis is daar een voorbeeld van. Het idee is om de hardware net zoals bij normale multithreading twee of meer stukken code tegelijk uit te laten voeren, maar dan op een 'agressieve' manier, dus eigenlijk zonder zeker te weten of het wel correcte resultaten oplevert. Net als bij andere features om de prestaties te verhogen zoals branch prediction wordt het risico dat er fouten worden gemaakt (in dit geval door onderling afhankelijke code parallel uit te voeren) voor lief genomen. Pas na de executie wordt gecontroleerd of de resultaten van de speculatieve thread bruikbaar zijn, en op dat moment wordt besloten of de effecten ervan 'committed' (geaccepteerd) danwel 'squashed' (genegeerd) worden.

Simulaties hebben aangetoond dat een processor met Mitosis-technologie aan boord alle single-threaded benchmarks op zijn minst iets sneller uitvoert dan een normale chip, en in sommige gevallen zelfs meerdere malen zo snel is. De grootste winsten zijn te behalen in situaties waarin parrallellisme wel aanwezig is, maar de progammeur het om wat voor reden dan ook niet expliciet in zijn code heeft ingebouwd. Het is niet duidelijk wanneer Intel verwacht dat speculatieve threads klaar zijn voor commerciële producten, maar wellicht zien we het concept binnen enkele jaren terug in een van de opvolgers van de Merom-core.

Reacties (38)

[Anoniem: 87832]

Het lijkt me dat deze technologie "normale" multithreaded applicaties in de weg gaat zitten, tenzij je het selectief aan/uit kan zetten per thread.

[Anoniem: 61096]

Hoeft natuurlijk niet, wat deze techniek lijkt te doen is dat delen van een enkele thread alsnog opgedeeld worden. Dus als je 10 threads hebt kun je hiermee de threads verder opsplitsen dan de oorspronkelijke programmeur bedacht had. Wat dat betreft zit er eigenlijk geen verschil tussen een multithreaded applicatie en een single threaded applicatie. Zodra er iets langs komt wat mogelijk paralel uitgevoerd kan worden, probeert de processor het.

Nadeel is er eigenlijk niet behalve dat bepaalde bewerkingen voor niets worden uitgevoerd. Maar je kan ervan uit gaan dat als zoiets beschikbaar komt het (net zoals Hyperthreading) uit te schakelen zal zijn en (áls het dus op de markt komt) in een flink aantal gevallen meer performance oplevert dan het kost.

[Anoniem: 87832]

Alleen WIL ik helemaal niet dat de processor een gokje doet of een deel van een thread parallel kan worden uitgevoerd terwijl ik zélf al weet welke delen 100% zeker parallel kunnen worden uitgevoerd.

M.a.w. zou de processor beide cores van een dual-core processor bezig kunnen houden met zélf threads verzinnen terwijl mijn applicatie moet wachten met het uitvoeren van een expliciet opgegeven thread waarvan ik zeker ben dat hij sneller gaat werken.

In geval van "gokken vs. zekerheid of iets sneller gaat" kies ik liever voor zekerheid

Tenzij handmatige thread prioriteit krijgen in het mechanisme natuurlijk, zodat een core wordt vrijgegeven indien ik zélf een thread opstart.

[Anoniem: 87832]

@Marcade: Slecht... gewoon niet multithreaded. Kan ze geen ongelijk geven, dat is in veel gevallen ook knap lastig.

Games bijvoorbeeld, zijn notoir lastig om multithreaded te maken omdat alles de godsganzelijke tijd met elkaar moet praten, dan krijg je vertraging door synchronisatie.

Een video-encoder daarentegen, kan je rustig een tijdje alleen op een minuut video zetten, tesamen met tig andere threads die een andere minuut encoden.

Idd, de code KAN beter, maar dan moet je wél een paar decenia hebben tot het af is. Wellicht is Duke Nukem Forever wel multithreaded straks

[Marcade]

Het komt er eigenlijk op neer als deze mitosis processor idd. je single-thread specifieke code kan multi-threaden .. dat je je code gewoon slecht geschreven hebt.

[Anoniem: 61096]

Je weet welke delen 100% zeker parallel kunnen worden uitgevoerd. Prima. Maar je weet niet 100% zeker dat alle andere code niet parallel kan worden uitgevoerd. Ook bij een multithreaded applicatie is er dus mogelijkerwijs redelijk wat te winnen.

Wel kost dit extra processorkracht. Die processorkracht in meestal gewoon beschikbaar zodat ook multithreaded applicaties sneller kunnen worden. Meestal zal er geen sprake zijn van verdringing van andere threads maar wordt er juist gebruik gemaakt van braakliggende rekenkracht. Het is dus geen "gokken vs zekerheid of iets sneller gaat" maar meer "gokken vs niets doen"

Maar deze techniek zal soms natuurlijk negatief uitpakken. Ofwel door verdringing, ofwel doordat er simpelweg te vaak fout gegokt wordt en de extra rekentijd voor de controlles niet meer goedgemaakt kan worden. Voor die gevallen zal Intel tzt wel zo slim zijn om deze techniek uitschakelbaar te maken. Instelbare prioriteiten of het selectief aan/uitzetten per thread lijkt mij dan ook zware overkill. Maar de toekomst zal het ons leren.

[Anoniem: 87832]

lamaar

[REAVER330]

okey nuttshell version,

ze laten op een hardware matige manier de code welke door de CPU verwerkt moet worden opsplitsen en vervolgens hopen ze erop dat dat wat eruit komt het goede is, laten er daarna nog een check overheen gaan.

Is het niet goed dan moet het opnieuw (is dus alweer meer CPU tijd) en vervolgens moet dit alles bij elkaar ook dan nog eens performance winst opleveren.

Ik weet het niet hoor al die dual core en minder wattage / warmte productie onzin, ik betwijfel of dit nou echt de toekomst is voor CPU`s.

Ik heb voor mezelf het gevoel dat de weg die zowel Intel als AMD hiermee is ingeslagen niet lang stand kan houden, ik bedoel okey Netburst architectuur is "dood"
maar of deze architectuur nou de juiste opvolger is???

En zoals ook al vermeld word dat vele applicaties nog steeds niet goed met multicore CPU`s overweg kunnen tja...

Mijn mening: get back to the drawingboard en start thinking about something totally different.

[edit] typ correctie.

[Anoniem: 87832]

Even je notendopje kraken hoor

De "check" is relatief eenvoudig; controleren of ze dezelfde geheugengebieden gebruiken en op welke manier. I.v.m. L1-cache in de CPU's wordt toch al een groot deel van deze administratie gedaan.

Het "opnieuw" uitrekenen zou je in een singlecore architectuur sowieso moeten doen, nu heb je enkel de kans gekregen dat het goed gaat en je ineens een leuke smak performancewinst maakt. Performanceverlies is niet mogelijk met deze methode, afgezien van de kleine performance die in de "check" gaat zitten.

Overigens hebben we nu al predictive branching dat vergelijkbaar is (hoewel in kleinere schaal) en in de praktijk ook best leuk blijkt te werken.

Aangezien je nu altijd de cores bezighoudt kan het enkel méér wattage/warmte opleveren. Tenzij je de cores allemaal wat omlaag klokt tegen dezelfde performance natuurlijk, in dát geval zou je inderdaad winst maken in wattage/warmte, aangezien die "niet geheel linear" oplopen bij kloksnelheid.

De reden dat veel applicaties niet met multicore overweg kunnen is omdat de programmeurs geen rekening houden met multicore. Deze technologie is juist ontwikkelt om met die situatie om te gaan dat een applicatie niet multicore ontwikkeld is maar dat het in principe wél multicore zou kunnen draaien als de programmeur de moeite ervoor had genomen. (niet dat programmeurs lui zijn; multicore is gewoon @#$! moeilijk)

Overigens zitten ze nog steeds op de drawingboard voor dit; het is research.

[Luxx]

Het "opnieuw" uitrekenen zou je in een singlecore architectuur sowieso moeten doen, nu heb je enkel de kans gekregen dat het goed gaat en je ineens een leuke smak performancewinst maakt. Performanceverlies is niet mogelijk met deze methode, afgezien van de kleine performance die in de "check" gaat zitten.

Er is geen preformance verlies, als je er vanuit gaat dat de 2e core niets staat te doen... Als de 2e core druk is met andere dingen (al is het maar DPC puntjes scoren) zal deze wel minder werk kunnen verzetten...

[Anoniem: 61096]

De discussie of Netburst dood is heeft niets met dual/multi core te maken. Het is in theorie prima mogelijk om tientallen netburst cores parallel te schakelen. Netburst heeft een erg lage IPC, Intel probeert nu een core te ontwerpen die hogere clocksnelheden aankan dan de Pentium M (een voordeel van Netburst) maar toch de IPC van de Pentium M én een laag stroomverbruik heeft. Misschien zou intel dat lage stroomverbruik ook met de Netburst architectuur kunnen behalen maar blijkbaar denken ze dat de P-M architectuur beter aan deze eisen kan voldoen.

Dat het splitsen van 1 thread in meerdere rekentijd kost is duidelijk. Je moet altijd een controle doen en soms zelfs de gehele berekening overdoen. Maar een single threaded app op een dual core processor laat 1 core (vrijwel) onbenut. De eerste berekening maakt dan gebruik van ongebruikte rekenkracht en kost dus niets. Als de controlle dan maar regelmatig uitwijst dat de parallelisatie terecht was en de berekening niet nogmaals hoeft te worden uitgevoerd kan de applicatie dus eerder over de juiste antwoorden beschikken. Dus hoewel er meer gerekend wordt kan het programma sneller met resultaten komen.

Mijn mening: get back to the drawingboard en start thinking about something totally different.

Ik denk dat zowel Intel als AMD met de kenmerken hoge IPC, hoge Performance/Watt, multicore en ook hoge kloksnelheden aardig in de goede richting zitten te denken. Misschien kan de x86 instructieset nog op de helling (Itanium iemand?) maar deze 4 kenmerken zijn toch redelijk belangrijk voor de performance. De winst is dat men sinds vrij recent niet meer puur naar 1 aspect kijkt (de klokfrequentie) maar ook andere factoren probeert te optimaliseren. Maar als je een oplossing weet om processoren sneller te maken die hier niets mee te maken heeft. Ik heb nog wel een telefoonnummer bij Intel

[Anoniem: 136066]

Lijkt me op zich iets heel mooi, en kan inderdaad wel een pak snelheidsverschil geven. Maar ik denk eigenlijk dat tegen dat deze technologie echt in cores ingebakken zit, hij eigenlijk al niet meer nodig is. De echt zware applicaties (het enige waarvoor dit nuttig zou zijn), zijn dan namelijk al zo geprogrammeerd.

edit: aan n4m3l355: Met zwaardere apps bedoel ik evengoed spelletjes enzo. Die zijn voor zoveer ik weet nog altijd single tread, maar dat gaat wel veranderen denk ik.

[Anoniem: 95352]

Tuurlijk, maar als er steeds meer cores komen, dan moeten de applicaties ook steeds paraleller worden.
Dus stel je voor, je hebt een applicatie die geschreven is om twee threads te hebben en dus gebruik te maken van twee cores. Deze app laat je dan draaien op een quad core computer, dan heb je twee cores die niks lopen te doen, met deze techniek zorg je ervoor dat je die extra cores dan toch kan gebruiken.

Disclaimer: Ik heb weinig tot geen kennis van parallel programmeren, dus niet kwaad worden als ik fout zit.

[Anoniem: 42901]

Mij lijkt het me gewoon het beste om gewoon je app niet double-core-stijl te schrijven maar gewoon algemeen multi-core gericht, dus dat het scaleable is. Oftewel in een soort multithreaded aanpak waarin de verschillende threads automatisch door afzonderlijke cores worden gemanaged.

[Anoniem: 87832]

Een applicatie zal alleen parallel kunnen werken als bepaalde delen code niet afhankelijk zijn van elkaar. Aangezien vroeg of laat bepaalde stukken code wel van elkaar afhankelijk MOETEN zijn (anders biedt het niet één functioneel geheel), is er altijd een praktische bovengrens aan het aantal parallelle threads dat nuttig is.

Zie het als het lezen van een boek; je kan hoofdstuk 1 en 2 door verschillende mensen tegelijk laten lezen. Maar als later blijkt dat je hoofdstuk 2 niet écht kan begrijpen voor je hoofdstuk 1 hebt gelezen, heeft één mens voor niks gelezen en kan de ander alsnog dat andere hoofdstuk lezen. Op z'n best ben je dubbel zo snel klaar maar op z'n slechtst even snel. En hiervoor heb je de altijd twee mensen nodig gehad.

In theorie kan je dus 20 hoofstukken laten lezen door 20 mensen en kan je op z'n best 20x sneller klaar zijn. Maar als het boek maar twee hoofdstukken heeft, maakt het geen verschil of je het laat lezen door twee of 20 mensen.

Het is dus niet zo dat het toevoegen van cores automatisch een snelheidsverbetering zou betekenen, alleen wanneer de applicatie dusdanig parallel kan worden verwerkt dat alle cores een eigen taak kunnen krijgen.

[flossed]

het kost een zwanger vrouw negen maanden om een kind te baren, 9 vrouwen kunnen hier geen een maand van maken.

Zoiets is het ook met applicaties, multicore is handig voor multi applicaties, hoeft niet handig te zijn voor een enkele applicatie, omdat de betreffende applicatie toch vaak een proces moet doorlopen, waardoor er afhankelijkheden ontstaan. Maar het kan het hoeft niet, dames kunnen rijden en makeuppen tegelijker tijd, typisch multicore architectuur. Heren zal daar altijd wel moeite mee hebben singelcore architectuur.

[sphere]

Zo werkt het niet. Je schrijft een applicatie single- of multithreaded, maar niet dualthreaded. Deze software is puur bedoeld voor stukken code die wellicht paralleliseerbaar zijn. Dan is het dus ook niet van belang hoeveel threads er draaien.

[Anoniem: 61096]

Tuurlijk wel, als ik maar twee threads heb in mijn applicatie kan ik maximaal van twee cores gebruik maken. Deze techniek gaat daar misschien verandering in brengen maar nu heb je dus redelijk veel programma's die maximaal van een eindig aantal cores gebruik kunnen maken. Denk dan bv aan Word. Eigenlijk een single threaded applicatie die voor bepaalde zaken (zoals afdrukken) een aparte thread opstart. Zelfde geldt voor applicaties waarbij lange rekenprocessen in een aparte thread gebeuren zodat de GUI nog enigszins responsive blijf. Of winrar (decryptie in de achtergrond) enz enz.

[Anoniem: 125026]

Waar jij het over hebt is het starten van worker threads om de main-thread te laten blijven reageren op user input. Hier heb je geen multi-core voor nodig, omdat de gui-thread toch bijna altijd idle is.

Edit: was als reactie op Pietje Puk bedoeld.

[n4m3l355]

de zware appps waar JerreDV over praat zijn allang multi threaded. denk aan MySQL/Maya/whatever. Juist de lichtere apps is dit een interessante feature voor of apps die heden ten dagen ontwikkeld worden waar dat nog niet in hun achterhoofd zit. Ik denk dat ontwikkelaars een steeds dunnere scheidingslijn krijgen tussen wanneer het wel/niet nut heeft om zo te schrijven

[Anoniem: 11710]

Iedereen doet steeds alsof nu pas door multicore de programma's parallel moeten worden, en dat alles wat nu bestaat singlethreaded is en nor aangepast zou moeten worden.
Maar multiprocessing is niet alleen dual core. Dual processor systemen bestaan al heel lang, ook voor consumenten. Iedereen kent de beroemde BP6 nog wel, waar je 2 celerons op kon knallen.
Een hoop fatsoenlijke software is al multithreadbaar, neem bijv. WME (Windows Media Encoder) die als je 2 cpu's hebt alle werk verdeelt over de CPU's en zo een video of WMA in de helft van de tijd kan coderen.
Alleen amateur software zal er vast nog geen rekening mee houden, de kans is groot dat een willekeurig door een amateur geschreven stuk software dat wav naar mp3 omzet alles in 1 thread doet.
Maar dan kan je je afvragen, hadden mensen met een dual CPU systeem die makers al 5 jaar geleden niet kunnen vertellen dat ie dual processor zou moeten ondersteunen ?

[WinL]

Maar niet in alle situaties is het gemakkelijk hoor! Encoding is misschien nog een gemakkelijk voorbeeld... Waarom zijn games dan singelthreaded? Omdat het te moeilijk is!
Ik zou een ervaren programmeur wel eens willen zien met zijn 32 cores (toekomst).

[Aetje]

Een ervaren programmeur zal met 2 of 256 cores even gemakkelijk uit de voeten kunnen. Het hangt van de STRUCTUUR van het ontwerp van een applicatie af hoeveel CPU's nuttig voor de applicatie zijn. Het eigenlijke programmeerwerk valt dan wel mee. Voor mensen die het in Delphi n's willen zien (nmm een eenvoudigere programmeertaal dan C++) kijk eens naar het TThread object. Je kan er zoveel van aanmaken als je wil, of het nuttig is is een tweede.

Hou er rekening mee dat dit soort multithreaded applicaties idd vaak de zware rekenintensieve applicaties zijn. 3D games, rendering... dat soort meuk. Je webbrowser zal er echt niet sneller van worden.

[Aetje]

Dat gebeurt dus al. (open voor de gein maar ns een webpage met veel graphics en gooi een Netstat in een command console). Maar idd, zoals Atmosphere al zegt, de bandbreedte is daar de bepalende factor, niet het al-dan-niet multithreaded grafisch opbouwen van de pagina.

En wat threads betreft. Stel, je wil in een document (groot document, zeg 64KB groot) een bepaald patroon zoeken. Je kan 1 thread sequencieel door dat docje laten stappen (of eigenlijk, de pattern-match tegen het geheugenblok doen), of het opdelen in 64 blokjes van 1K groot en deze aan een aantal CPU's toedelen. Dan heeft elke CPU werk. De CPU die de match maakt rapporteert dit via een soft interrupt (of flag) aan de main thread en de main killt vervolgens alle overbodige threads die nog lopen (if any). Een simpel voorbeeldje van hoe je zeer eenvoudig 64 CPU's aan het werk zet.

[Anoniem: 61096]

[lekker off topic]

Hou er rekening mee dat dit soort multithreaded applicaties idd vaak de zware rekenintensieve applicaties zijn. 3D games, rendering... dat soort meuk. Je webbrowser zal er echt niet sneller van worden.

Je webbrowser wordt er wel sneller van. In plaats van 1 voor 1 de plaatjes opvragen kan die ze allemaal tegelijkertijd requesten in aparte threads.

Multithreading is vaker zinvoller dan je denkt.
[/lekker off topic]

[Atmosphere]

ipv er 2 tegelijk te requesten zal het eerder zo zijn dat hij er 1 op kan bouwen en de aanvraag voor een 2e ... het tegelijk verwerken van de aanvraag schiet niet op aangezien deze toch over een niet multithreaded inet verbinding moet

[WinL]

Kan in .NET ook. Maar dan nog moet je synchroniseren in bepaalde gevallen. En dat is lastig. Er zijn veel programma's waar dat niet gemakkelijk in is. Bij een webserver zijn de threads ook aparte entiteiten die vrijwel (Dus toch een beetje) met elkaar te maken hebben. Dit vergemakkelijkt het programmeerwerk. Maar het is niet altijd zo gemakkelijk. Anders was alles al multithreaded.
Ow ja: ik ben geen prof maar heb binnen no-time paar duizenden threads runnen. De enige beperking het OS/proc. Ofwel: 255 threads die concurreren en samenwerken om iets te doen is toch wat intensiever.

[flossed]

lkker fijn , en dan serialiseer je de aanvraag via je een netwerkkaart naar een single threaded server. Die al je gets stuk voor stuk behandeld en op de lijn zet, omdat het toevallig een stukje AsP of JSP is wat op de server draait.

[Mars Warrior]

ik zou een ervaren programmeur wel eens willen zien met zijn 32 cores (toekomst).
Niks toekomst, wat dacht je dat webservers nu aan aantallen threads hebben draaien??? En zo zijn er nog wel zat applicaties die heel eenvoudig multi-threaded zijn en met elke core meer een performance boost krijgen, zonder dat je daar ook maar iets aan hoeft te doen als programmeur...

Ik denk dat de meeste problemen ontstaan bij applicaties die niet vanzelfsprekend multi-threaded zijn, en waar men "truukjes" uit moet halen om deze op te delen in meerdere threads om zo de aanwezigheid van meerdere cores te kunnen uitbuiten...

[mawashigeri]

Als er nu iets is dat zich goed leent voor multithreading is het wel een game. Denk maar aan allerlei verschillende voorwerpen waarop tegelijkertijd de physics modelling wordt toegepast, plus nog alle AI.

In zijn algemeenheid is goed multithreaded programmeren trouwens Echt Moeilijk als er veel synchronisatiepunten zijn; het aantal mogelijke deadlocks en livelocks is al gauw ontelbaar, dus je zal formele bewijzen moeten gaan opstellen als je e.e.a. betrouwbaar wil maken (en nee, de meeste "programmeurs' kunnen dit niet).

Mawashigeri denkt nog eens aan de colleges "Het programmeren van multiprogramma's"--snif

[cavey]

een game juist niet.

Omdat al die objecten erg interactief op elkaar inwerken. Moet je eerst berekenen wat het ene object doet, voor je weet wat het effect het heeft op een ander object. Kan je leuk physical modelling tegelijkertijd uitvoeren..... Gaat misschien ook prima voor objecten die niet in je blikveld staan en niet zo erg op elkaar inwerken, maar, als je die toch al niet ziet, heb je daar ook geen dikke AI/physical modelling voor nodig........ dus kan je dat afdoen met een simpel scriptje.

Opbouwen van je hele scene? Is ook moeilijk multhi-threaded te maken. Kijk alleen al naar de SLI ellende. Of interlaced rendering, of scherm in 2 vlakken verdelen....... maar dan heb je weer meer kans op tearing.

Enige wat beetje multithreaded kan is de splitsing tussen muziek en het grafische geweld. Grofweg gezegd.

Tot men betere technieken heeft bedacht om physics in spelletjes te parallelliseren.... zit een echt zware multi-threaded game er naar mijn mening nog niet in.

Bedenk me net dat dit alleen echt geldt voor FPS games....... misschien zijn er wel andere gamegenres die goed te doen zijn.

[Marcade]

Ik vraag me af of dat ten koste zal gaan van de stabiliteit. Applicaties die geschreven zijn voor single-thread processors zullen toch een bepaalde flow verwachten. Die flow verandert lijkt me als een processor gaat 'gokken' welke stukken code die tegelijkertijd kan laten draaien. Dan kan je toch onverwachte resultaten krijgen? En dan kan de processor het nog wel gaan lopen controlleren maar dan zit die dubbelop werk te doen lijkt me.

[WinL]

Jullie denken allemaal aan 2 of 4 cores. Een goede ontwikkelaar kan die met veel moeite nog wel aan. Maar laten wij eens gek doen.
Stel we hebben 16 cores --> wie begint met proggen in C++?
Juist dit is onaandoenlijk. Als jij je programma dan voor 4 cores hebt geschreven kan de techniek toch zorgen dat het op alle cores werkt zonder dat het OS/prog daar weet van heeft.
Sommige zijn bang voor instabiliteit en juist traagheid. Net zoals branch prediction controleert de techniek of het eventueel mogelijk is --> het is dus geen gok. Omdat deze techniek zo geavanceerd is, kan het toch nog fout gaan. De processor vergelijkt wat beide stukjes hebben gedaan (hij houdt bijvoorbeeld gebruikte registers/geheugen bij) en bepaalt of het geldig is of niet...
Daarbij, als je het opnieuw moet doen, bij singlethreaded bestond die andere thread sowieso toch niet.

Laten we nu niet meteen gaan schelden (net zoals bij de MS bashing reacties)... maar laten we het critisch bekijken met het oog op de toekomst. Deze techniek staat in kinderschoenen en kan zelfs nu al voor een performance boost zorgen... DUS eerst de RTM/FINAL build/uiteindelijke uitgave (bij soft- en hardware) testen alvorens een 100% hard oordeel te maken.

-->EDIT
Enkele waren me ietjes voor

[Anoniem: 142917]

De Merom Core? Dat is hoogstwaarschijnlijk de opvolger van de PowerPC voor de Mac, slechts 45W consumptie!!! Ik ben nieuwsgierig of dit specifiek gericht gaat worden op de Mac of dat dit voor iedereen beschikbaar zal zijn. De mac moet toch nog iets speciaals hebben niet???

<<edit Typo>>

[Anoniem: 28659]

/offtopic
nee de mac moet juist niets speciaals hebben. Daardoor kunnen ze meeliften op het x86 succes. Goedkope chips met behoorlijke performance. Als ze nu weer voor iets unieks willen hebben, lopen ze weer risico dat die ontwikkeling niet standhoudt en weer gaan achterlopen op de mainstream.

[flossed]

hmm, thread prediction, branch prediction. scatter and gather, hit and mis. nu nog een intelligent stukje software dat sorry zegt voor iedere vergissing die de CPU begaat en we hebben windows Xcuse. Als ik nu al kijk naar mijn task manager dan zie ik dat het zwaarste proces dat 97% van mijn CPU tijd bezig houdt de niet-actieve systeemprocessen zijn, wat kan ik nog met mijn coputer doen, als hij de hele tijd bezig zal zijn mij een stapje voor te wezen?, in de hoop efficient te zijn?"

"I think I will add two numbers in a bit, or I could do something completly different and go for a bite, but apparently I am not hungry, well maybe just a nibble then"

[Infinitive]

Vergeet niet dat deze thread "prediction" op runtime plaatsvind en niet op het moment dat je het programma schrijft. Als programmeur heb je wellicht een mogelijkheid voor multithreading genegeerd omdat je ziet dat er programma executies zijn waarvoor het geen correcte resultaten geeft. Bovendien schrijf je een programma met de nodige abstracties. Maar in het geheel van het programma, of gewoon op de manier waarop het programma gebruikt wordt, kan blijken dat dergelijke incorrecte executiepaden bijna nooit voorkomen. Dan heeft zo'n feature opeens wel nut.

(uiteraard moeten het aantal keren dat het fout gaat en er overbodig werk wordt gedaan het wel opwegen tegen het aantal keer dat het goed gaat).

Er zijn ook nog wel andere voordelen te onderscheiden, zoals het at runtime uitzetten van deze techniek als de server het al druk heeft en de processor al door andere processen en threads volledig benut worden. Of om tijdelijk een proces op de voorgrond wat extra power mee te geven.