Miljoenen van Intel en Microsoft voor optimaal gebruik multicores

Intel en Microsoft investeren miljoenen in nieuwe onderzoekscentra aan de universiteiten van Illinois en van Californië, waar onderzoek zal worden gedaan naar methodes en technieken om multicoresystemen optimaal te benutten.

De twee bedrijven investeren in de komende vijf jaar samen twintig miljoen dollar in de zogeheten Universal Parallel Computing Research Centers. Daarnaast wordt er door de universiteiten zelf nog eens vijftien miljoen dollar in de laboratoria gestoken. Volgens Intel is het onderzoeksprogramma het grootste op het gebied van mainstream parallel computing dat tot dusver in de VS is opgezet.

Weliswaar worden hard- en software op het gebied van dual- en quadcorearchitectuur al door Intel, Microsoft en vele anderen geleverd, maar het aantal cores zal de komende jaren snel stijgen. Zo wijst Andrew Chien van Intels Corporate Technology Group erop dat Intel al enige tijd geleden een prototype met tachtig cores toonde. Intel zal volgens hem Microsoft en de universiteiten nodig hebben om ervoor te zorgen dat die rekenkracht ook benut wordt.

Tony Hey, bij Microsoft verantwoordelijk voor het coördineren van extern onderzoek, zegt dat de opkomst van multicoresystemen de manier waarop software wordt ontwikkeld, drastisch zal beïnvloeden. Volgens informaticaprofessor Marc Snir, een van de leiders van het centrum aan de universiteit van Illinois, bestaat de uitdaging voor de onderzoekscentra eruit om het programmeren voor parallelle processen 'zo gemakkelijk te maken dat parallel programmeren synoniem wordt met programmeren.'

Daartoe moeten nieuwe oplossingen worden gezocht op het gebied van besturingssystemen, programmeermethodieken en programmeertools en applicatiemodellen, zodat programmeurs zich niet stuk hoeven te bijten op de vele cores die hen ter beschikking staan, en zodat ook de consument er uiteindelijk profijt van heeft.

Er zijn overigens al diverse resultaten geboekt op het gebied van het automatisch uitsmeren van gewone sequentiële programmacode over meerdere kernen. Zo demonstreerde het bedrijf Codeplay vorig jaar zijn 'autoparallelle compiler', die, zij het met de nodige hulp van de programmeur, stukken code opspoort die onafhankelijk van elkaar kunnen worden uitgevoerd.

Reacties (39)

[johnbetonschaar]

Ik ben bang dat ze bij Intel en Microsoft over een jaar of 5 tot de conclusie komen dat extreem parallele architecturen (zoals een 80-core chip) voor de meeste toepassingen niet geschikt zijn en de performance in veel taken heel erg tegen gaat vallen. Beetje net als met de Ghz-race. Veel computerprogramma's voeren nou eenmaal veel seriele taken uit, en daarbij vaak taken waar veel control-flow inzit. Veel control-flow = veel data-dependencies = veel plekken waar gewacht moet worden. Daarbij heb je vrij complexe hardware nodig om een snelle CPU te maken die dat soort berekeningen uitvoert (branch prediction, register renaming, speculatief uitvoeren, prefetching etc), wat direct de reden is dat een single-core x86 CPU zoveel beter presteert op het merendeel van de applicaties dan een DSP, maar wel zoveel meer transistors nodig heeft. 80 general-purpose cores op een chip is voorlopig nog wel even onmogelijk, en 2 of 4 slappe general-purpose cores plus 80 berperkte DSP's is leuk, maar alleen nuttig voor toepassingen die wat aan de DSP's hebben. Video/audio bewerking en 3D zijn eigenlijk de enige toepassingen die ik kan verzinnen voor thuisgebruikers, en voor het laatste zal de GPU voorlopig nog wel niet verdwijnen.

Voor de mensen hierboven die bij dit soort berichten aan dualcores of quadcores denken zoals we die nu al hebben: er is geen enkel probleem met het programmeren van dualcores of quadcores, dat kan al jaren prima, met 2 tot 4 symmetrische cores is het helemaal niet moeilijk of ingewikkeld om het parallelisme van de CPU te benutten, als je applicatie daar geschikt voor is tenminste. SMP systemen met zoveel CPU's, cores, threads, whatever worden al jaren efficient gebruikt. Dat dat nog niet echt tot veel desktop-toepassingen is doorgedrongen heeft er weer mee te maken dat veel applicaties gewoon weinig intrinsiek parallelisme in zich hebben.

[TERW_DAN]

Ik ben bang dat ze bij Intel en Microsoft over een jaar of 5 tot de conclusie komen dat extreem parallele architecturen (zoals een 80-core chip) voor de meeste toepassingen niet geschikt zijn en de performance in veel taken heel erg tegen gaat vallen.

Ik denk dat dat wel mee zal vallen. We zullen denk ik niet langer in de hoogte gaan als het aankomt op snelheid (dus steeds meer MHz of GHzjes voor een proc). We zullen langzaamaan gaan uitbreiden naar meerdere cores (in de breedte dus). Voor nu is dat nog niet zo heel boeiend, maar de software en OSen zullen erop geschreven moeten worden.
Threads zullen in dat geval kort gemaakt worden, zodat je heel veel threads hebt, die daardoor gelijk afgehandeld kunnen gaan worden. Op die manier kun je de snelheid behalen.

In het geval van games bijvoorbeeld is het nu zo dat er 1 of 2 threads zijn die alles renderen (al dan niet met behulp van wat hardware acceleratie voor 3d, physics etc). Stel je dit eens voor op een 128core bak. Je hebt 1 core voor het uitrekenen van de bewegingen van het haar van het karakter waar je mee speelt. 1 voor de linkerarm, 1 voor de rechterarm, 1 voor de torso, 1 voor het linkerbeen, 1 voor het rechterbeen etc.
Ditzelfde geldt voor alle andere dingen die er in het spel gebeuren. Je kunt een core hebben die zich alleen bezig houdt met grassprietjes renderen, 1 voor de regendruppels, 1 voor de belichting afhankelijk van het tijdstip etc etc. Op deze manier kun je een veel realistischer beeld maken, omdat dingen totaal onafhankelijk van elkaar kunnen gebeuren maar aan de andere kant natuurlijk ook dat er een samenwerking tussen de cores zit (wie weet gebruik je wel 1 core om de invloed van de ene thread op de andere te berekenen).

Dit geldt natuurlijk ook voor andere applicaties die uitgebreidt zijn. Het renderen van video bijvoorbeeld, laat iedere core een frame renderen, zet per 4 cores 1 core in om te syncen zodat je geen verschillen krijgt in frames die je niet wilt en je haalt hier potentieel flink wat snelheid uit, als je met een flinke hoeveelheid cores zit.

Bovenstaande geldt denk ik niet alleen voor de CPU, maar ook voor de GPU en Physics die er baat bij hebben om met meerdere gebruikt te worden.

Door de beschikking te hebben over veel cores bestaat de mogelijkheid om veel zaken tegelijkertijd te doen. Het is een andere aanpak dan hoe het nu gedaan wordt (veel losse threads zijn nu alleen maar traag ivm 1 langere thread).

Het duurt nog wel even voordat we zover zijn, maar ik denk dat die onderzoeken daarvoor best zinnig kan zijn.

[Bobco]

Het voorbeeld dat je aanhaalt is interessant, maar games is natuurlijk maar een heel beperkt stukje van het totale spectrum aan applicaties. De meeste PC's worden ingezet voor 'zakelijk' gebruik en alle applicaties die continue user input moeten verwerken hebben één beperkende factor: de gebruiker.

Veel standaard kantoor applicaties lenen zich niet zo geweldig voor paralellisatie. Een thread voor de UI, een thread voor de I/O, een aantal threads voor langer lopende bewerkingen en dat is het wel zo'n beetje.

Bovendien is in jouw aanpak ook nogal wat intelligentie nodig in de applicatie: wat nu als je in een game meer karakters hebt rondlopen dan het aantal cores dat je hebt? Je zult dan alsnog een behoorlijk probleem krijgen want je wilt wel het complete beeld hebben waarin alle bewegingen zijn meegenomen. Elke keer wachten totdat de langzaamste thread klaar is kan dan een behoorlijke vertraging opleveren.

Bovendien moet je het probleem van synchronisatie niet onderschatten. Als onderdelen op elkaar inwerken moet er gecommuniceerd worden. Als dat ook nog betekent dat er dan opeens iets heel anders moet gebeuren dan heb je een uitdaging.

De uitdaging op dit moment bestaat eruit dat het ontwikkelgereedschap dat software bouwers hebben niet zo veel (eigenlijk geen) ondersteuning biedt voor automatische parallellisatie. Er zijn wel talen die beogen om concurrency gemakkelijker te maken (Erlang bijvoorbeeld), maar dat is nog lang geen mainstream.

[johnbetonschaar]

Allebei +1 wat mij betreft, als ik nog kon moderaten. Multicore systemen zijn zeker interessant en bruikbaar en waarschijnlijk gaat de technologie voorlopig ook sterk in die richting. Heb ik ook nooit ontkend overigens. Maar wat bobco zegt is ook helemaal waar: games, 3D rendering en video zijn allemaal zo'n beetje de poster-toepassingen van heterogene multicore systemen: de PS3 is er natuurlijk het schoolvoorbeeld van, maar in principe is een xbox 360 of een dikke PC+GPU ook gewoon een soort heterogeen multi-core systeem. Helaas is het percentage CPU verkopen voor consoles en game-pc's denk ik zo ontzettend beperkt ten opzichte van de totale markt, en zullen de ontwikkelkosten waarschijnlijk erg hoog zijn (want zeer specifiek). Ik denk dat Intel en AMD een beetje jaloers zijn op IBM, die alle consoles al van CPU's voorziet, en bang is dat de markt erachter komt dat een entry-level CPU (ok dual-core is wel handig) eigenlijk voor 80% van de markt voor PC-toepassingen voorlopig wel een beetje het eindstation is. Vandaar dat we nu allemaal moeten geloven dat je voor dagelijks gebruik een quadcore of een nieuw soort chip met 80 cores nodig hebt.

[Reactie gewijzigd door johnbetonschaar op 26 juli 2024 02:27]

[Verwijderd]

Het probleem is dat veel software de multi-core processoren nog niet optimaal aanspreekt, omdat er nog altijd een vorm van 'queueing' of 'in de wachtrij plaatsen' wordt gehanteerd.

Als beste voorbeeld, wegens zichtbaar op het PC-scherm, is de dBpoweramp Music Converter, een tool van Illustrate om CD's te rippen (zowat de enige gelijke, of zelfs beter want sneller, van/dan EAC of Exact Audio Copy).

Wanneer een CD geript wordt, is in het hoofdmenuscherm te zien hoe core 1 en core 2 beide respectievelijk track 1 en track 2 voorberekenen.

Vervolgens beginnen core 1 en 2 met de eigenlijke rip van beide tracks. Maar wanneer track 2 nu veel korter is dan track 1, dan is bijgevolg core 2 logischerwijs sneller klaar met het rippen dan core 1.

Maar... ipv dat core 2 dan onmiddellijk begint met de voorberekening van track 3, wordt core 2 in de wachtrij geplaatst en blijft bijgevolg 'idle' tot core 1 netjes zijn werk heeft afgehandeld. Omgekeerd echter, wanneer track 1 korter is dan track 2 en bijgevolg core 1 sneller klaar is, dan gaat core 1 lekker door met track 3, omdat core 1 niet in de wachtrij geplaatst wordt. Core 1 heeft dus duidelijk voorrang op core 2...

Nochtans is dBpoweramp versie 12 speciaal ontworpen voor gebruik met multi-core processoren, maar desondanks wordt er slechts gedeeltelijk gebruik gemaakt van het voordeel dat zulke CPU's bieden. Want als gevolg van dat 'in de wachtrij plaatsen,' van core 2, is mijn D 940 tràger dan mijn vorige P4 3,2GHz CPU met hyperthreading. Raar maar waar.

Dar er dus nog driftig onderzoek wordt gedaan is een goeie zaak, dat men zich serieus bezighoud met ook de software onder de loupe te nemen kan alleen toegejuicht worden...

[Reactie gewijzigd door Verwijderd op 26 juli 2024 02:27]

[YopY]

Da's op zich eenvoudig te verhelpen (dat probleem met die ripper), je neemt thread A die de manager is, die de CD analyseert en een lijst maakt van taken (rip track 1, track 2, etc). Die start vervolgens thread B die track 1 ript, en thread C die track 2 ript. Wanneer thread B klaar is geeft 'ie een bericht door aan thread A die thread B weer een nieuwe taak geeft.

Qua programmeren is het heel goed mogelijk om dit 'asynchroon' te laten lopen. Ik denk dat het grootste probleem bij zo'n programma de i/o is, aangezien een CD-speler maar een taak tegelijk aankan (= 1 track tegelijk lezen).

[Verwijderd]

Ik denk dat het grootste probleem bij zo'n programma de i/o is, aangezien een CD-speler maar een taak tegelijk aankan (= 1 track tegelijk lezen).

Tijdens het rippen van een CD wordt deze niet afgespeeld, alleen ingelezen. Moest bij het inlezen slechts 1 track tegelijk kunnen worden 'gezien' dan zou dat betekenen dat je nooit de volledige inhoud van een CD zou kunnen zien...

Het eigenlijke rippen van de CD gebeurt door beide cores tegelijk, echter heeft core 1 duidelijk voorrang op core 2, want core 2 moet wachten op core 1, terwijl core 1 verder werkt wanneer core 2 nog bezig is...

[0rbit]

Je hebt maar 1 leeskop in je cd-speler en die kan maar op 1 plek tegelijk zijn. Daarom kun je alleen op zinvolle manier rippen als je 1 track per keer ript. Dat je de data over twee cores kunt verdelen staat daar los van. Het seeken met je leeskop tijdens het lezen wil je tot een minimum beperken.

Heb je de data al op de harde schijf dan staat niets je in de weg om per core één compressie thread te starten. Dat is ook wat EAC doet en dat werkt gewoon zoals je zou verwachten; het werk wordt over de cores verdeeld. Zodra een track klaar is, wordt automatisch de volgende compressiethread gestart.

Het lijkt er meer op dat dBpoweramp gewoon niet zo goed in elkaar zit, want dit soort dingen kan ik zelfs programmeren

[Verwijderd]

Het lijkt er eerder op dat je nog niet goed hebt gekeken hoe EAC werkt én nog nooit dBpoweramp hebt gebruikt.

Bij het rippen wordt een CD alleen ingelezen, en de ingelezen data wordt omgezet naar whatever codec je gebruikt (FLAC, mp3, SHN, WMA...).

Mijn d 940 CPU ript twéé tracks tegelijk, alleen heeft core 1 voorrang op core 2, maar niet omgekeerd... Queueing heet dat. Lees wat er staat, a.u.b.

[.oisyn]

En lees jij nou eens wat Mr_Atheist zegt, want hij heeft gewoon gelijk. Als dBpoweramp zich gedraagt zoals jij voordoet, dan is het gewoon niet goed geprogrammeerd. Elke kapabele programmeur kan een synchronized queue maken die eerst wordt gevuld met alle taken (elke track is 1 taak), en vervolgens kunnen de verschillende threads (in principe ongeacht hoeveel cores je tot je beschikking hebt, dus het is behoorlijk schaalbaar) taken uit die queue trekken en afhandelen. Daarbij is er geen sprake van voorrang.

Je omschrijving klinkt er meer op alsof de multithreading er achteraf is bijgehackt. De main thread beheerst de queue (zoals in een single threaded applicatie), en elke keer als hij er zelf een taak uit haalt kickt hij ook meteen de andere thread, ipv dat die andere thread zelf in de queue kijkt.

[Mbyte]

Het lijkt er nog eerder op dat jij je gelijk wilt halen, en niet leest wat andere zeggen.

WTF is het verschil tussen een cd inlezen of tracks ophalen, jouw cd-speler kan maar op 1 punt tegelijk zijn en een hele cd of tracks binnenhalen maakt dus echt geen fuck uit.

Daarnaast is bij rippen je proc toch al niet de bottleneck, want hij kan sneller compressen dan dat de CD-rom kan aanvoeren. Ergo cd's rippen kan niet software matig geoptimaliseerd worden zolang de CD-rom de bottleneck is.

[erikdenv]

Ik vraag me af of de CD wel atijd de bottleneck is. Op enig moment moest ik een nieuwe CD/DVD-ROM speler, deze ript dusdanig sneller dan de oude dat encoden weer langzamer gaat dan rippen.

Gelukkig kun je met Kaudiocreator opgeven hoeveel encode-threads je tegelijk wilt laten lopen, je kunt ook de prioriteit van de encoder instellen, dat houdt je systeem nog wat bruikbaar.

Tevens maakt het m.i. uit hoe je gaat encoden. Ik encode MP3's met Lame met variabele bitrate en hoge kwaliteit (-v2), waarschijnlijk kost dit een stuk meer CPU-cycles dan encoden naar fixed 128 kbit.

edit:
kleine test, encode van een wav (Time, Pink Floyd, 71MB), meting met "time"
lame -h -V 0 -> sys 0.354s (VBR hoge kwaliteit, 252 kbit gem.)
lame -h -V 2 -> sys 0m0.301s (VBR redelijk hoge kwaliteit, 210 kbit gem.)
lame -h -> sys 0m0.272s (Fixed, 128 kbit)
het maakt dus wel verschil maar niet heel schokkend

[Reactie gewijzigd door erikdenv op 26 juli 2024 02:27]

[cc bcc]

Het probleem is dat veel software de multi-core processoren nog niet optimaal aanspreekt, omdat er nog altijd een vorm van 'queueing' of 'in de wachtrij plaatsen' wordt gehanteerd.

Die zogenaamde queueing is niet inherent aan multicore programmeren, maar een gevolg van lui programmeren.

[g4wx3]

efficienter programeren van software zou ook al veel doen denk ik. En daar doel ik dus vooral mee op Microsoft. Zij hebben verreweg het allerzwaarste OS geprogrameerd. Maar tov linux distro's zoals ubuntu, of tov OSX kan ik niet echt zeggen dat het zoveel geavanceerder is.
Ik wil nog kwijt dat Next OS in 1992 al dingen konden de pas mainstraim werden rond 2000.
Rond 2000 werd BeOS ook populairder, en ook die kon veel meer met minder resources. En BFS is nog altijd voor op alle huidige Filesystems.
Daarintegen is NTFS wel voor/veiliger dan HFS+, hoewel die laatste allerlei extra features EMULEERT. Die extra features komen goed van pas als je iets als timemachine programeert, dat niks anders is dan kopieren van mappen en bestanden, en bij identiek het zelfde bestand een hard link leggen. De interface is niks meer dan wat findervenstertjes met wat coredraw effectjes.

Toch vind ik dat huidige OSen nog sneller zouden moet kunnen gaan, en aangezien OSX bij iedere nieuwe versie iets sneller is weet ik dat men nog steeds code optimaliseerd.

[Reactie gewijzigd door g4wx3 op 26 juli 2024 02:27]

[arjankoole]

Volgens Intel is het onderzoeksprogramma het grootste op het gebied van mainstream parallel computing dat tot dusver in de VS is opgezet.

nu staat heel mainstream parallel computing nog dusdanig in de kinderschoenen dat dat natuurlijk helemaal niet verwonderlijk is.

[Mr_Light]

Gridcomputing is een gevestigd onderzoeksgebied.

ipv communicatie tussen nodes is het nu tussen cores,
localitieit van data storage; shared memory van nodes/blades vs dat van dies/cores

van macro naar micro niveau brengen, over het in de kinderschoenen staan vind ik ook weer wat overdreven. Daarnaast zijn er ook andere factoren:

Het duurt een tijd voor dat code dat vandaag wordt geschreven zich een weg vind naar de pc van de consument. (http://www.joelonsoftware.com/articles/fog0000000017.html niet dat ik nu echt fan van joel ben, ter illustratie) Os-en zijn een ander voorbeeld: wie draait er nog allemaal xp? De familie en onderliggende concepten zijn nog ouder.

Daarnaast staat de IT wereld er om bekend dat onderzoek met maar o zo moeilijk zijn weg tot de praktijk. En omgekeerd dat praktische problemen zich maar heel langzaam hun weg vinden naar onderzoek.

Het guru-systeem schijnt volgens sommige ook negatieve invloeden te hebben op dit proces.

Dat er extra onderzoek nodig is werd al langer geroepen nu voegen intel en ms het woord bij de daad middels poen.

[arjankoole]

Gridcomputing is een gevestigd onderzoeksgebied.

lees wat ik zeg

'mainstream' is het sleutelwoord hier, dat betekend niet de gridcomputing die we nu al gebruiken, maar paralelle computing in mainstream gebruik bij consumenten en zakelijk gebruik. Zeg maar 'conventioneel' gebruik.

Doordat we in die sector nu ook de beschikking hebben tot paralelle computing units, alles met 2-cores en meer, kunnen we nu applicaties beter geschikt maken voor multi core systemen.

uiteindelijk zal hier natuurlijk ook het e.e.a. uit voortvloeien voor gridcomputing natuurlijk.

[Mr_Light]

De theorie is niet echt anders als we het over een grid(als in een netwerk van nodes), supercomputer, bladeserver of 80-core cpu hebben.

De schaal is alleen anders. Het hele idee dat van scratch begonnen zou moeten worden is onzin. Zelf specifiek voor 'op de desktop' word ook al de afgelopen 3 ~ 5 jaar veel onderzoek naar gedaan. Dat is ook niet zo gek, men zag/ziet het teken aan de muur, daarnaast is die 80 core ook niet zo cutting edge(het nieuws bericht dateert van september 2006!) insiders wisten er uiteraard eerder van en intel zelf doet ook nog wel eens onderzoek.

[Tjeerd]

In Nederland staan we ook niet helemaal stil, ook al is het hier ook nog allemaal in de kinderschoenen. Hier heet het dan bijvoorbeeld Virtual Lab Environment, waar een klein lijstje van software beschikbaar is die in de wetenschap veel wordt gebruikt, maar wel op een gedistribueerd netwerk al draait.

[dj.verhulst]

Het is eigenlijk best gek dat een hoog geclockte dual core in overal handeling sneller is dan een quadro core,, puur omdat de andere cores nauwelijk wat doen.

en de snelheid winsten t.ov de oudere single core komt uit grotere & snellere cash L1 , L2 , L3 en geheugen bandbreedte en efficientere thread afhandeling.

[0rbit]

Dat zal best, maar er zijn ook applicaties te bedenken waar dat niet het geval is. Ik werk toevallig momenteel aan algorithmen die uiteindelijk op een quad-core dienen te draaien puur omdat er 3 data-verwerkende threads zijn (3x gelijke hoeveelheid data die min of meer synchroon afgewerkt moet worden) en 1 thread voor overhead. Dat werkt op een dual-core een stuk slechter, omdat het switchen van thread in dit geval switchen van context is, wat het hele process zeer langzaam maakt.

[PL JNS]

Goed initiatief! Dualcores zijn inmiddels al enige tijd beschikbaar, maar veel software maakt er nog helemaal geen gebruik van, wat eigenlijk wel zonde is.
Vooral voor Windows e.d. lijkt het mij dat er nog veel snelheidsvoordeel te behalen is.

[the_stickie]

Dat veel applicaties (nog) geen gebruik kunnen maken van multicores betekent niet dat er absoluut geen voordeel mee gehaald wordt. Onbenutte rekenkracht staat ter beschikking van het OS en andere (achtergrond) processen. Dat maakt de computer een stuk responsiever...

[Tjeerd]

Wat helemaal mooi zou zijn als er ooit een mogelijkheid komt om "klassieke" software door een of andere virtual machine automatisch over meerdere cores te kunnen verspreiden. Dus een soort van extra laag die het werk wat normaal op een CPU kan draaien toch over meerdere CPU's verdeelt. Dit dan als oplossing om niet-multidradige software toch gebruik te kunnen laten maken van de extra rekencapaciteit.

[YopY]

Het probleem daarmee is dat je daardoor het programma of de processen daarin moet analyseren en zoeken naar zich herhalende (= vaak paralleliseerbare) processen. Dat zou op zich niet zo'n groot probleem zijn - het grotere probleem, en datgene dat ook het lastigste is bij parralel berekenen is het geheugenbeheer - welk proces heeft welke gegevens nodig, en wanneer. Ik ben lang geen expert op het gebied, maar het lijkt mij dat dat verdraaid moeilijk is.

[arjankoole]

Wat helemaal mooi zou zijn als er ooit een mogelijkheid komt om "klassieke" software door een of andere virtual machine automatisch over meerdere cores te kunnen verspreiden.

ik dacht dat Intel al zoiets had bedacht met een soort omgekeerde hyperthreading. Daarmee wordt van 2 cpu cores 1 grote cpu gemaakt, met (in theorie) meer performance dan de 2 losse cores individueel kunnen leveren.

[Lex_brugman]

Dat was AMD: klik

[freaq]

het lijkt me mooi om te kunnen zorgen dat 2of meer cores aan 1 taak kunnen werken.
reverse multithreading.
dat zou echt wat zijn...

[TERW_DAN]

het lijkt me mooi om te kunnen zorgen dat 2of meer cores aan 1 taak kunnen werken.
reverse multithreading.
dat zou echt wat zijn...

Dat kan eigenlijk alleen door 1 thread op te delen in meerdere threads. Dan zul je dus uiteindelijk weer op hetzelfde idee als multithreading uitkomen. Dit zijn dingen die je niet door je cpu wil laten doen, gezien dat gewoon erg veel tijd kost (thread analyseren, opdelen, afhandelen en weer samenvoegen). Dan is het sneller om gewon die thread door 1 core uit te laten voeren.

[DLGandalf]

komt automatisch bij dat je dan een hoop overhead krijgt, bij stukken code die niet naturally-paralell zijn, variabelen die gesynchroniseerd moeten worden enz.

[Fiander]

En ik maar denken dat Microsoft hierin met plinq al erg ver was.

Ik ben benieuwt welke dingen er op een doorzichtige manier verder verbetert kunnen worden. Ik hoop dat ze meteen ook kijken om de jit compiler volledig gebruik te maken van sse(1234).

http://msdn2.microsoft.com/en-us/magazine/cc163329.aspx

[RemcoDelft]

Intel zal volgens hem Microsoft en de universiteiten nodig hebben om ervoor te zorgen dat die rekenkracht ook benut wordt.

Is dit niet een beetje omgekeerde wereld? Een oplossing zoeken voor een probleem dat er niet is, namelijk: software maken omdat de rekenkracht benut moet worden, i.p.v. nieuwe hardware ontwikkelen omdat de rekenkracht nodig is?

[Fiander]

software maken omdat de rekenkracht benut moet worden

ik denk dat je moet lezen : tools maken zodat de rekenkracht benut kan worden ( zonder dat dat veel moeite van de ontwikkelaar kost )

[SPee]

Vooral voor universiteiten e.d. is de rekenkracht wel nodig.
Hoeveel rekenkracht is b.v. nodig om het weer te voorspellen?
Of de invloeden van atomen?

En zoals gezegd; het realistisch maken van spellen (of zelfs robots).
Dat vereist ontzettend veel rekenkracht.

[Verwijderd]

Plus het is altijd leuk als je systeempje weer een seconde of wat sneller opstart.

[Decile]

dit gaat nog erg intressant worden omdat nu die skulltrails ook al uit zijn, 8 core computing, voor server apps zeer geschikt, voor gaming wat minder, hopelijk komt daar ook verbetering in.