'Quadcores in helft desktops in 2009'

Quadcore-processors worden momenteel alleen in enkele high-endsystemen toegepast. In 2009, zo speculeert iSuppli, zal bijna de helft van de pc's een quadcore aan boord hebben.

Wie het maximale uit een pc wil halen komt al snel uit bij quadcore-processors. Intel heeft momenteel het alleenrecht op die markt, aangezien AMD op zijn best setjes van twee dualcores verkoopt. De prijs van een processor met vier kernen ligt vaak hoger dan die van een variant met 'slechts' twee cores, wat voor een groot deel verklaart waarom deze processors momenteel nog niet echt aanslaan bij het grote publiek.

In het eerste kwartaal dit jaar was 16 procent van de verkochte high-endsystemen uitgerust met een quadcoreprocessor. De verwachting is dat dit percentage zal oplopen tot 33 procent in het vierde kwartaal. Eind 2009 zal 96 procent van de cpu's in dit segment een quadcore zijn. iSuppli definieert een performancesysteem als een computer met het beste van de huidige techniek en een prijs die boven de duizend dollar ligt. Dit soort computers vormt zes procent van de markt. De verwachting is dat aan het eind van dit jaar zeven procent van de betaalbaardere systemen een processor met vier kernen zal hebben.

Waar de penetratie van quadcores in de desktopmarkt al dit jaar op gang komt, duurt het naar verwachting nog tot het eerste kwartaal van 2009 voor de eerste laptops met quadcores worden uitgerust. Aan het eind van dat jaar zal elf procent van de notebookmarkt met de bewuste techniek uitgerust zijn. De remmende factor op de toepassing van quadcores in laptops is het energieverbruik van een processor met zoveel cores. Tot het moment dat het vermogen van dit soort processors afgenomen is tot een acceptabel niveau zullen quadcores hooguit worden toegepast in desktopvervangers.

Reacties (61)

[g4wx3]

Volgens Intel kunnen cores voledigs uitgeschakeld worden, dus als je je laptop intselt op "zuinig", dan zie ik niet waarom quads er pas later in kunnen komen.

Onderweg gebruik je dan 1 van de 4 cores, en op het lichtnet, trek je al systeembronnen open

Aangezien het om een nieuwere techniek gaat, zullen de cores zuniger zijn (denk aan 45nm).
AMD zal weer een tandje bij moeten steken..

[Kingh]

Daarnaast speelt de afvoer van warmte ook een rol. Die afvoer van warmte is bij een laptop een essentieel onderdeel of vermogende CPU´s gebruikt kunnen worden of niet, daar er beperkte ruimte is.

[freeco]

logisch eigenlijk: nu zijn C2D's mainstream en quadcores extreme highend.
Tegen 2009 zijn de C2D's basic en de quadcores mainstream... (en 8-cores highend?)

[Flying]

Enorme prijsverlagingen voor de Quad Cores zie ik toch niet echt. En de toegevoegde waarde ten opzichte van de prijs zie ik nog minder.

Intel heeft een huidige monopolie op Quad Cores en dat is steevast te merken aan de prijs. Zonder AMD zouden we allemaal tweemaal zoveel aan het betalen zijn voor alle processors. Dat ze maar snel komen met hun Quad Cores, AMD.

[Wouter Tinus]

Verdraaiing van de feiten. De Q6600 kostte vlak na de introductie begin dit jaar ongeveer 850 euro en staat nu vanaf 475 euro in de pricewatch. Wat heeft AMD precies gedaan om dat te bewerkstelligen? In de tweede helft van het jaar gaat de prijs nog verder zakken naar ~250 euro, waarschijnlijk nog voor de desktopquads van AMD goed en wel te koop zijn. De Extreme Editions zijn wel duurder, maar dat is nu eenmaal per definitie zo voor een XE, dat was toen ze zwaar werden ingemaakt door de Athlon 64 niet anders. Ze zijn inmiddels wel een tandje sneller gemaakt (2,66 -> 2,93) zonder enige druk van AMD.

Als je de reacties hier leest is het makkelijk om tot de conclusie te komen dat Intel alleen dingen doet om AMD te pesten, maar ze hebben wel grotere zorgen: de enorme productiecapaciteit moet benut worden en klanten moeten continu gemotiveerd worden om hun huidige, paar jaar oude, systemen te vervangen, omdat anders de verkoop keldert. Beide doelen bereik je niet door de prijzen door het dak te jagen of de ontwikkelingen te vertragen.

[Verwijderd]

Ik denk dat het onjuist is om te stellen dat AMD hier geen invloed op heeft. Het mag dan wel zo zijn dat AMD momenteel nog geen materiaal levert, als dit niet in de pijpleiding zat, zou intel veel meer op zijn lauweren rusten. Ik denk zelfs dat er dan nog helemaal geen quadcores te koop waren, immers waarom zouden ze zich haasten. Ook de grote productiecapaciteit is er vanwege de concurrentie. Als je niet kunt leveren, stappen mensen over op andere merken. Zou er alleen maar intel zijn, dan zouden mensen daarvoor op een wachtlijst gezet worden.
Intel verlaagt juist de prijzen om het AMD moeilijk te maken. Het is veel lastiger voor AMD om met een concurrerende prijs te komen als die van de concurrent zo laag ligt. En ja, intel moet op den duur van voorraden af, omdat ze anders straks inferieure producten moeten verkopen t.o.v. de concurrent. Intel moet dus van de voorraden af en zo snel mogelijk over naar de nieuwe, echte quadcore om de snelheidstroon te behouden.

[Verwijderd]

Ik denk zelfs dat er dan nog helemaal geen quadcores te koop waren, immers waarom zouden ze zich haasten.

AMD is niet de enige concurrent.
In de server/workstationmarkt zijn er ook nog andere spelers.
Voor die markt zou het heel handig zijn om toch die quadcores uit te brengen, en goedkope server/workstationoplossingen te bieden, om het marktaandeel te vergroten.
Sowieso lopen de server/workstationprocessors (Xeon-serie) voor op de desktopmodellen. Daar hebben ze al langer 1333 FSB en 3 GHz.

[Patriot]

Daar gaan we weer. Intel is de bad guy en AMD de oh-zo-geweldige underdog.

Natuurlijk heeft AMD wel enige invloed gehad op de prijzen van Intel, maar het is absurd om te stellen dat we zonder AMD nog geen quadcores hadden gehad, AMD is echt niet de enige concurrent van Intel.

Zou er alleen maar intel zijn dan zouden mensen daarvoor op een wachtlijst gezet worden

Wat is dat nou weer voor absurde opmerkingen. Alsof het niet goed voor Intel is als meer mensen hun processoren kopen.

Je doet alsof we zonder AMD nog in het Pentium II tijdperk zouden zitten, dat is een absurde claim. Programma's worden steeds zwaarder en dat is een goede ontwikkeling voor Intel. Als de programma's die de consument wil draaien niet elke keer zwaarder zouden worden zou de enige reden om een nieuwe computer/processor te kopen slijtage zijn. Door de ontwikkeling van nieuwe, zwaardere, software komt Intel zijn processoren weer kwijt.

[Verwijderd]

De prijzen zijn juist heel laag voor quadcores en intel gaat ze binnenkort weer verlagen.

[Ghost81]

Is het nou zo dat applicaties/games die geoptimaliseerd zijn voor 2 cores automatisch kunnen profiteren van 4 cores? Of kunnen die applicaties/games alleen gebruik maken van 2 cores. Kortom is multithreading generiek voor een x aantal cores?

[Kawaii]

Ik neem aan dat het afhankelijk is van hoe de software geprogammeerd is. Maar gezien de meeste ontwikkelingen denk ik dat de meeste software nu zo wordt geschreven dat deze over een x aantal cores verdeeld zou kunnen worden.
Het is zonder om eerst veel tijd en moeite te steken om alles naar 2 cores om te schrijven als er in de tussentijd als quad of misschien later nog wel octo cores uitkomen.

[OruBLMsFrl]

Je hebt eigenlijk drie soorten multithreading, het eerste introduceert wat overhead, maar zorgt ervoor dat je over zeer veel cores kunt opschalen. Dan maak je voor ieder stukje werk, bijvoorbeeld een object in een game, een thread aan die zelfstandig met de rest van de threads communiceert, eventueel via een centrale thread die het werk coordineert en timing regelt.
Het tweede is veel simpeler, namelijk dat je bijvoorbeeld een compiler laat uitzoeken welke stukken code onafhankelijk van elkaar uitgevoerd kunnen worden. Na zo'n stuk wordt dan gesynchroniseerd, wat weer tijd kost. Dit levert vaak veel mindere performancewinst en schaalbaarheid op, maar kost weinig ontwikkelingstijd.
Het derde is voorgeprogrammeerde multithreading, waarin expliciet bepaald wordt welke core wat doet. Kan veel performance opleveren, maar is steeds moeilijker te maken als het aantal cores toeneemt.

Ik denk dat games nu vooral de tweede en derde weg kiezen, omdat de eerste weg nog teveel overhead heeft om op een dual core machine toch snelheidswinst te kunnen boeken. Met quadcores of zelfs octocore zal het sneller richting het eerste en tweede scenario gaan.

[hansg]

Ik wil toch even bezwaar aantekenen tegen die tweede methode die je noemt. Weliswaar zijn universiteiten in mijn ervaring helemaal geil van dit soort trukerij (ik was er bijna nog op afgestudeerd), maar in de praktijk wordt het absoluut niet gebruikt. De reden is dat communicatie tussen de cores ook tijd kost, en de schaal waarop taken verdeeld kunnen worden door de compiler is iha. veel kleiner (in de buurt van nanoseconden) dan de schaal waarop taken door het OS toegekend worden aan cores (milliseconden, i.e. complete timeslices).

Je zou dus een ander OS nodig hebben om een dergelijke strategie zinnig te kunnen gebruiken, eentje die alle cores voor elke timeslice aan een enkel proces toekent en dan het proces zelf de verdeling van parallelle secties over de cores laat regelen, en daarnaast zou je ook nog eens hardware moeten hebben waarbij de communicatie tussen de cores vrijwel geen overhead oplevert. Dat bestaat wel (transputers en zo), maar dat is gespecialiseerde hardware die niet vergelijkbaar is met een moderne X86-stijl multicore chip.

Automatische parallellisatie is dus op zijn best een leuk onderwerpje voor afstudeerders, maar enige praktijk waarde heeft het niet. De gedachte dat compilers single-threaded code op magische wijze geschikt kunnen maken voor meerdere cores is dan ook volledig misplaatst.

[mjtdevries]

@Bas

Kun je een voorbeeld geven van een applicatie die die voorgeprogrammeerde multithreading gebruikt?

Ik heb ze nog nooit gezien, en ik zie ook niet in waar de snelheidswinst vandaan moet komen.

Het OS is prima in staat om zelf de verschillende threads tot te wijzen aan een core. Bovendien ben je veel flexibeler als je niet van te voren hoeft te weten hoeveel cores je ter beschikking hebt.

[mjtdevries]

@hansg,

volgens mij zijn er twee redenen waarom er toch naar die compilers onderzoek wordt gedaan.
1. Bij systemen met honderden processors wordt het voor mensen toch erg moeilijk om genoeg threads te maken om al die processors bezig te houden.
Maar dan hebben we het ook meteen over een totaal ander OS.
2. programmeurs van desktop applicaties weigeren nog steeds om behoorlijke multithreaded applicaties te schrijven. Ondanks multi-processor systemen al jarenlang betaalbaar zijn voor de desktop.

[hansg]

@mjtdevries:

Dat maakt allemaal niet uit. Het zou vreselijk nuttig zijn _als het zou werken_, maar het werkt niet en het kan niet werken, en dus is het ook niet nuttig. Het onderzoek ernaar kan geen kwaad, het helpt mensen begrijpen hoe compilers werken en met name ook hoe ze niet werken, maar het zal niet uitmonden in een compiler die een single-threaded applicatie "zomaar" (en betekenisvol) kan omzetten in een multi-threaded applicatie.

De enige manier om netjes taken te verdelen over CPU's is de programmeur die taken laten definieren. Dat is lastig, stukken lastiger dan dat een magische compiler het voor je doet, maar het is wel de enige manier die werkt.

Bij wijze van voorbeeld gaan we even een programma parallelliseren. Het programma is dit:

int a, b, c, d, e;

a = b + c + d + e;

Een single-threaded compiler maakt daarvan:

1: a = b + c
2: a = a + d
3: a = a + e

3 stappen; afhankelijk van de CPU architectuur zal het er ietsje anders uitzien maar dit is realistisch genoeg.

Een parallelliserende compiler maakt daarvan:

1: core 1: a = b + c
1: core 2: a' = d + e
2: core 1: wacht op core 2
2: core 2: zend a' naar core 1
3: core 1: a = a + a'
3: core 2: <idle>

In andere woorden, dit zijn ook drie stappen, maar dan verdeelt over twee cores.

Waar het misgaat is in stap 2. In het single-threaded voorbeeld is dat een optelling, oftewel een enkele cycle in een moderne processor.

Maar de het multi-threaded voorbeeld is dat een inter-processor communicatie, en die zijn veel en veel duurder dan optellingen.

Resultaat: onze parallelliserende compiler heeft tragere code opgeleverd dan de single-threaded compiler. En dit patroon zal je zien voor willekeurig welk stukje programmacode je ook kiest: als je op instructie-nivo parallelliseert dan wordt eventuele winst volledig ondergesneeuwd onder communicatie overhead.

[albatross]

Waar jij het nu over hebt, is parallel processing, maar een duo/quad core is daarvoor helemaal niet bedoeld. Bovendien moet je voor duo/quad core threads ook helemaal niet proberen om instructies op te delen in threads -- de overhead zou inderdaad enorm wezen. Threads moet je schrijven op applicatie niveau, voor databases en zo. Dan heeft het wel zin.

[flowerp]

Automatische parallellisatie is dus op zijn best een leuk onderwerpje voor afstudeerders, maar enige praktijk waarde heeft het niet. De gedachte dat compilers single-threaded code op magische wijze geschikt kunnen maken voor meerdere cores is dan ook volledig misplaatst

Toch blijft maar liefst 12% van de programmeurs hier op got doodleuk wachten totdat compilers automatisch parallelliseren:

http://gathering.tweakers.net/forum/list_messages/1174646

als je op instructie-nivo parallelliseert dan wordt eventuele winst volledig ondergesneeuwd onder communicatie overhead.

Ik hoop dat de meeste mensen ook wel begrijpen dat je ILP (Instruction Level Parallelism) helemaal niet op multiple cores moet willen afbeelden. De methode om dit te doen zit al jaren lang in alle gangbare CPUs: meerdere functional units i.c.m. met pipelining en out of order execution. Het inherente parallelism in een instructie stroom is echter relatief zo gering dat bij de meeste architecturen bosjes FU's onbenut blijven elke cycle.

Ondanks (of misschien juist dankzei) alle research is het wel duidelijk dat er op het instruction niveau niet al te veel te halen valt. (SMT is daarom juist uitgevonden om de onbenutte FU's te gebruiken).

Toch blijven bosjes mensen er maar op hopen dat ooit hun code volledig automatisch over meerdere cores verdeeld zal gaan worden. Ik schaar die mensen maar bij het rijtje waarin ook de oude C programmeurs zitten die nog steeds hopen dat er een refactor programma komt die hun oude procedurele code automatisch OO maakt.

[Verwijderd]

De meeste software wordt niet ineens anders geschreven vanwege multicore CPU's. Lichte applicaties hebben niet de extra power nodig en zullen niet anders ontwikkeld worden. Zware applicaties hebben die power wel nodig, maar zijn vaak van nature al multithreaded ontwikkeld, omdat ze veel verschillende taken tegelijk uitvoeren. Die hebben per definitie baat bij multicore processors.

Een van de weinige soorten applicaties die je echt zal zien veranderen is games. Die zijn traditioneel helemaal niet multithreaded ontwikkeld, maar ze hebben de komende jaren duidelijk geen keus. "Vroeger" werden 3D games eigenlijk op basis van een per-frame principe ontwikkeld. Het is dan een vaste sequentie van afhandeling, bijv:

1 - behandel user input
2 - bereken AI acties
3 - bereken physics
4 - behandel geluid
5 - render frame

Om dat multithreaded te maken is behoorlijk complex en daar was voorheen ook geen reden voor. Vandaag hebben de ontwikkelstudio's eigenlijk geen keus meer.

[mjtdevries]

1 - behandel user input
2 - bereken AI acties
3 - bereken physics
4 - behandel geluid
5 - render frame

In spellen is het helemaal niet moeilijk om dat multithreaded te maken.
Je moet alleen aan threads op een ander nivo denken.

Neem bv de AI acties. In vrijwel alle spellen heb je veel tegenstanders. Neem voor elke tegenstander een aparte thread. In een flightsimulator kunnen dat bv de andere piloten zijn. Dan heb je zo ineens tientallen threads die parallel uitgevoerd kunnen worden. Idem voor shooters.

Voor physics hetzelfde verhaal.
Je hebt stapels verschillende objecten die vaak vrijwel geen relatie tot elkaar hebben -> stapels threads die parallel uitgevoerd kunnen worden.

Geluid wordt vaak grotendeels in hardware gedaan en kost dus weinig cpu. Maar mocht je het in software willen doen dan kan ook dat goed multithreaded gemaakt worden.
Geef elke geluidsbron zijn eigen thread. zijn er toch minimaal een handjevol. Wederom een handjevol threads die parallel uitgevoerd kunnen worden.

Je ziet het is echt niet moeilijk om genoeg threads te vinden om een quadcore bezig te houden.

Het grote probleem is echter dat je wel eerst programmeurs moet opleiden om multithreaded te werken. En met name spelprogrammeurs lijken vreselijk conservatief te zijn. (zo denkt 99% nog steeds dat je een AI moet laten vals spelen om een goede tegenstander te laten zijn)

Kijk bv naar RTS games. Ondanks dat we sinds de 386 ongelooflijk veel meer cpu kracht hebben, zijn de AI in die spellen nog even dom als toen.

[Top-Rob]

Ik vind dat je een slimme manier beschrijft in je post om een game multi-threaded te maken.

Maar nog even over je laatste 2 alinea's: spelprogrammeurs denken niet zozeer dat je de AI moet laten valsspelen om 'm een waardige tegenstander te laten zijn (tenminste niet de programmeurs die ik ken), maar AI blijft gewoon zeer ingewikkelde materie dat steeds meer het ondergeschoven kindje wordt. Niet omdat de programmeurs lui of conservatief zijn, maar deel uitmaken van een vakgebied vol ernstige deadlines waarin multiplayer steeds centraler staat en singleplayer steeds meer terrein verliest. Het ligt dus steeds minder voor de hand om veel moeite te steken in een betere AI. Of althans, in die veronderstelling verkeert een groot deel van de game-industrie (wat mogelijk niet terecht maar wel begrijpelijk is).
Daarnaast vertonen games tegenwoordig vanwege hun complexiteit meer en meer bugs bij de release, dus ruimte voor een betere AI (in de huidige situatie) is er echt niet.

Enneh, de AI van RTS van tegenwoordig is overigens wel degelijk een HEEL stuk beter dan de AI van vroeger hoor. Het blijft alleen enorm achter op alle andere gebieden (grafisch/geluid/game design).

[albatross]

"In spellen is het helemaal niet moeilijk om dat multithreaded te maken. Je moet alleen aan threads op een ander nivo denken.Neem bv de AI acties. In vrijwel alle spellen heb je veel tegenstanders. Neem voor elke tegenstander een aparte thread. In een flightsimulator kunnen dat bv de andere piloten zijn. Dan heb je zo ineens tientallen threads die parallel uitgevoerd kunnen worden. Idem voor shooters."

Toch minder dan je denkt. Juist bij games moeten al die threads als een gek met elkaar communiceren, want de status van iedere player (= thread) moet bijgehouden worden en voortdurend aan iedereen doorgespeeld worden. Die relatie is eerder quadratisch dan lineair; want als je 2 mannetjes hebt, moeten er dus 2 x 2 pakketjes verstuurd worden. Bij 3 mennekes, dus 3 x 3 pakjes. Overhead gaat een killer worden zo.

[elmuerte]

Antwoord op de 1e vraag: Als het meer dan 2 threads(/processen) zijn, dan ja. Anders nee.

Antwoord op de andere 2 volgt daar wel uit.

[Ghost81]

Ik zag namelijk in een eerder bericht dat in de 2e helft van dit jaar een snelle dual core rond de 3 GHz net zo duur was als een langzamere quad core van rond de 2.4 GHz. Dat wordt een interessante keuze...

[SG]

Nou nee.
Valve laat alleen weten dat er over power is om de render engine te voeden. Zijn er dus meer CPU cycle voor andere taken beschikbaar.
Daarnaast zijn de meeste taken Serieel afhankelijk van mekaar. Dus houden ze een core voor Threadmanagen en sound. De ander taken zoals de laaste trap renden kan pas gedaan worden als input netcode AI Physics gedaan is. De een na de ander vanwege afhankelijkheid. Aanegzien dat allemaal posities en status van objecten beinvloeden. kan er pas na Phsyics berekeningen gerenderd worden.

Hiervoor die fine grain threading dat alle overige cores beschikbaar voor die ene task volledig worden gebruikt, dan de volgende afhankelijke task.

De winst die je daarmee haald is veel groter dan Phsyics op een core aangezien andere Thread task zitten te wachten op die Physics task. Ipv die Core Idle te laten zijn doen ze allemaal een task die op dat moment in focus is.

Dan Physics is maar eentje, AI is er ook nog. Op die methode kan er meer voor elke task gedaan worden. Maar ook nieuwe features eerst niet mogelijk kunnen wel voor elke task. AI wordt dan veel uit gebreider.

Dus Die quad core doet niet alleen Maar Physics maar ook andere task die ook belangrijk zijn om me te groeien.

Zoals in een Desrtuctieve enviorment moet Pathing dynamisch berekend worden en AI moet er dus ook rekening mee houden. Fix Path voor calculatie werkt dan niet.
Artifisial life hogere level AI ook AI methoden die eerst nog niet mogelijk waren maar wel voordeel bieden.

Daarnaast als Quadcore Mainstream worden in 2008 2009. Zijn er R700 tot R800 en G90 tot G100 beschikbaar om Physics op zo'n niveau te doen dat het een okt core voorbij blaast en dan heb je niet PPU van nu maar de derde generatie.als ageia ook nog in de markt zal zijn.

Het voordeel is meer de standaard gameplay Physics niveau is een stuk hoger geworden. Hardware Physics zal er nog steeds zijn maar dan nog op grotere schaal in fine detail.

Dus de minimum Phsyics level gaat een trapje omhoog.

[RagaBaSH]

dat ligt eraan wat je met die cores wil doen. Ik heb een maandje of wat geleden een presentatie van Valve (HL etc.) doorgenomen waarin ze verschillende strategieen uitlegden over het multithreaded maken van de Source Engine. Hierbij kwam naar voren dat bij meer dan 2 cores je niet perse meer frames per sec. gaat halen, maar wel veel meer eye candy kan gaan projecteren (realistische regen, betere vloeistof graphics etc.)

dus dan wordt de keus tussen dual core of quad core, een van meer fps of meer eye candy (ik weet al wat ik zou kiezen )

[Ernie]

Dus eigenlijk wordt de source engine dan zo aangepast dat hij processoren die gewoonlijk weinig gebruikt worden gaat benutten voor natuurkundige berekeningen, oftewel gewoon een goedkope physics kaart dus

Overigens is de keuze tussen dual core of quadcore moeilijker dan enkel FPS of eyecandy. Als je minimale fps van 80 naar 100 gaat zou ik toch zeker voor eyecandy kiezen. Als je echter van een fps van 20 naar 30 gaat is de dual core een betere keuze, op dat moment dan. Je mag aannemen dat meer cores in de toekomst nuttiger worden, om nog maar te zwijgen over het grotere overclockpotentieel van de lager geclockte quadcore. Dus alleen in extreme gevallen zou je voor een dual core kiezen.

[Verwijderd]

Als je programma eenmaal gemaakt is voor meer dan 1 thread is het over het algemeen niet zo moeilijk om dat voor meer threads uit te breiden. De moeilijkste stap is van single naar 2 threads ivm de code voor synchronisatie van de threads onderling. Daarna is het meer van hetzelfde.
Overigens zie je in de OS software van de laatste jaren steeds meer background processen ontstaan die ook eigen threads hebben en daarin asynchroon allerlei maintenance achtige taken uitvoeren. Bijvoorbeeld indexering, reorg of defrag etc.

[albatross]

Ik heb aan die jongens van CCE (Cinema Craft Encoder) eens gevraagd of ze ook quad-core ondersteunen. Het antwoord was: "Ja, maar we optimaliseren voor Core Duo." Ik heb het dus zodoende maar bij de E6700 gelaten.

[elteck]

Daar kun je wel van uit gaan. Zodra je multi threading toepast, moet je semaphoren (locks) inbouwen om de threads in je programma te synchroniseren. Dat is best veel werk, maar zodra je dat gedaan hebt, maakt het niet veel uit of je dat voor twee of twintig threads doet.

Je zal wel meer geheugen erbij moeten plaatsen, want alle threads moeten gelijktijdig in je geheugen komen.

[OruBLMsFrl]

Het toegenomen geheugengebruik valt reuze mee. Vaak is veel geheugen statisch, bijvoorbeeld textures en geluidsdata in games. Voor dynamische zaken als spelers en objecten die je bijvoorbeeld kapot kunt schieten is wel geheugen nodig, maar ook dat valt nog wel mee. Als er al geheugen overhead is, dan is het vaak in de orde van 10-20%, voor games verwacht ik nog minder. Geheugenbandbreedte heb je wel meer nodig, zeker als threads regelmatig gegevens uitwisselen ipv met gedeelde toegang tot hetzelfde stukje geheugen werken.

[mjtdevries]

Als je multithreading programmeert dan maakt het niet uit hoeveel je cores je hebt. Dan mogen er 2 of 4, of 16 maar ook 1 zijn. In je programma ga je niet van een bepaald aantal cores uit.

Wat je doet is in je programma defieneren welke stukken code als aparte thread uitgevoerd kunnen worden.
Vervolgens handelt het OS het verdelen van die threads over de cores af.

Of de applicatie er baat bij heeft wordt bepaald door het aantal threads dat je parallel kunt uitvoeren.

Heb je maar 2 threads die tegelijkertijd uitgevoerd kunnen worden dan zal een quadcore je geen winst opleveren.

Maar het is meestal wel zo, dat wanneer een programmeur eenmaal heeft geleerd om multithreaded te werken, dat ie dan meteen een heleboel threads kan maken. Dus vaak zal een quadcore dan wel degelijk nuttig zijn.
Het probleem is echter dat de programmeurs van spellen (waar we de cpu kracht het hardste nodig hebben) nog lang niet op dat nivo zitten.

[Rey Nemaattori]

quad core laptops

vreet dat niet enorme hoeveelheden energie? Dat heb je toch helemaal niet nodig op een laptop?

[keldererik]

De remmende factor op de toepassing van quadcores in laptops is het energieverbruik van een processor met zoveel cores. Tot het moment dat het vermogen van dit soort processors afgenomen is tot een acceptabel niveau zullen quadcores hooguit worden toegepast in desktopvervangers.

Als het moet kunnen ze dit haalbaar maken.

[GENETX]

Alles gaat door. Je zou het zelfde kunnen zeggen over Singlecore -> Dualcore in laptops. Verder worden laptops ook sneller en vaker gebruikt. Zit zelf ook op 1tje die ik gewoon als DTR gebruik. Een AMD Turion 64 X2 TL-52, 2GB, GF Go 7600 256MB @ 450/400, 100GB + 320GB extern is echt niet verkeerd ofzo voor in totaal €1350,- 10 maanden geleden. Van de overstap naar dualcore zijn die dingen ook echt niet meer gaan gebruiken.

Full load:
Intel: Pentium-M ~22-30W (oid) -> Core (2) Duo ~35W
AMD: Turion 64 25-35W -> 31-35W

In idle stand zijn ze echter zuingiger geworden omdat 1 core veel zuiniger is. Er kan van alles uit (vooral bij Intel) waardoor het niks uit gaat maken op de accu.

[DeArmeStudent]

dual core systemen worden al toegepast in pda's en zo zullen quad-cores juist een voordeel vormen voor dit soort energie-zuinige systemen...4 cores op 1 ghz is altijd nog zuiniger dan 1x een core op 3,8 ghz...

[Verwijderd]

ik zie niet in waarom dit voor normaal gebruik van belang is. het gaat erg hard zo en ik zie kwaliteit van games maar niet beter worden. mijn hoop is crysis. ik hoop dat dat nog realistischer wordt dan de huidige games. mijn 6600 is nu nog ruim voldoende en mijn 7900gt oc ook.

wat mij heel erg opvalt is dat de proc markt nu harder gaat dan de software markt.

[Dutch_Razor]

Zag je een jaar (of 2) geleden games ook niet beter worden? Toen had je Batlefield 2 enzo, nu heb je Rainbow Six Vegas, GRAW(2) en SCDA.

[DarthDavy]

En ik die dacht dat er eindelijk van die oude 286 architectuur in processoren ging afgestapt worden gaat ze toch nog lekker verder.

Maar aangezien ze onze processor niet meer in Hertzen sneller krijgen, gaan ze ons er gewoon meer geven: dual core, quad core. What's next? Octo core???

Ik zou liever nieuwe architecturen zien...

[t-h]

die zie je ook. de Core Duo cpu's van Intel zijn heel anders van de Pentium 4. Het is echter veel te duur om elk jaar een cpu 'from scratch' te ontwikkelen. Bovendien is dan niet het maximale uit de architectuur gehaald.

Octo-core, wie weet. Maar wie weet in 2009 ook wel een nieuwe architectuur. Die dan direct met 5-8 cores begint.

[XLeration]

Zul je zo zien, over enkele jaren praten we niet meer over mhz'en maar over megacores

[Verwijderd]

Eind 2009 zal 96 procent van de cpu's in dit segment een quadcore zijn.

Wat men lijkt te vergeten is dat in 2009 er vast wel 8-cores beschikbaar zullen zijn.

[ScSi]

Wat denk je dat ze bedoelen met die overige 4%?

[Verwijderd]

dualcores misschien?
Verwacht je niet dat er dan voor meer dan 4% van de high-end systemen 8-cores ingezet zal worden?

[Triek-Meister]

Ik denk eigelijk persoonlijk dat ze die een beetje links laten ligen en dat ze gaan proberen 4 qudcores op een chipie gaan proppen.

[Verwijderd]

Is het dan niet handiger dat je bij bepaalde belasting pas de volgende core inschakelt? Dan kun je bij 4 cores 4 instellingen gebruiken. Voor eenvoudig gebruik zoals Internet 1 core. Als het wat zwaarder wordt met 2D grafisch werk, dan wordt de 2e core ingeschakeld. Bij het spelen van spellen en encoding van video/audio de 3e en indien nodig de 4e core aan zetten. Scheelt enorm in energieverbruik. Zal wel niet zo werken, want daar hebben ze natuurlijk helemaal vanaf het begin over nagedacht lijkt me en als het kon was het allang zo. Dan zouden ze bij single core CPU's al de niet-gebruikte rekeneenheden uit kunnen zetten bij een lager systeembelasting.

[Terryb47]

Quadcore klinkt leuk en aardig maar als de meeste programmas niet eens van een dualcore profiteren is het voor de huis tuin en keuken computer gebruiker echt niet nodig.

Maar goed, in 2 jaar tijd als de prijs flink omlaag is gegaan dan kan ik me die 50% van de markt wel voorstellen.

[Verwijderd]

Probeer toch eens verder te denken dan 1 programma.
Bv een game op core 1 en allerlei systeem taken en encoden van een video op core 2.

PhotoShop zal niet sneller worden als je van 1 naar 4 cores gaat. Maar de rest van je systeem wel.
Photoshop trekt 1 core naar 100% load terwijl andere taken op vol vermogen doorwerken op andere cores.
Kortom applicaties worden niet sneller maar ze vertragen minder snel.
Ik draai niet de 10 zwaarste toepassingen op aarde. Verre van dat. Maar ik ben wel iemand met een eindeloze lijst in z'n taskmanager.

Natuurlijk zit er een grens aan het nut van meerdere cores. Aan 100 cores heb ik totaal niets. Mijn grootste vraag is waar voor mij de grens ligt. 2 cores 4 cores 8 cores?
Zelfs als je niet naar de kosten kijkt is nog meer cores niet altijd de beste oplossing. Dual cores lopen nl voor qua snelheid op quad cores (per core)
2x3Ghz of 4x2.4Ghz

[albatross]

Photoshop ondersteunt meerdere cores, hoor.