Google: multicore-systemen niet altijd beter

De claim dat het groeiende aantal cpu's met een multicore-design het rekenwerk in grootschalige omgevingen efficiënter en goedkoper maakt dan traditionele single core cpu's, gaat lang niet altijd op, zo stelt een topman van Google.

Urs Hölzle, senior vice president of operations bij Google, schrijft dat moderne processors met meerdere rekenkernen momenteel in de praktijk vaak achterblijven op single core-processors. Volgens Hölzle zijn vrijwel alle kernen in multicore-cpu's lager geklokt dan processors met een singlecore-ontwerp, waardoor de verwerkingstijd voor een enkele thread langer kan duren. De Google-medewerker stelt dat dergelijke rekenklussen die niet parallel zijn op te delen onder andere bij Google in de praktijk vaker regel zijn dan uitzondering.

Hölzle meent verder dat software voor veel bedrijven aanzienlijk meer kost dan de toegepaste hardware, maar dat er nog weinig multithreaded code gebruik maakt van de potentiële voordelen van moderne cpu's met meerdere rekenkernen. Hierbij haalt Hölzle de wet van Amdahl aan. Deze wet stelt dat er duidelijke grenzen zijn aan de haalbare prestatiewinsten van een totaal systeem als delen ervan parallel worden uitgevoerd. Een ander nadeel van parallelle verwerking door multicore-processors is de kans dat de wachttijden hoger liggen, zo meent Hölzle. Voor het afronden van een bepaalde taak zou er in veel gevallen gewacht moet worden tot alle subtasks zijn afgerond.

Volgens Hölzle kan het grootschalig toepassen van multicore-cpu's binnen grote datacenters in bepaalde gevallen de exploitatiekosten opdrijven. Zo zouden multicore-systemen veelal met meer werkgeheugen worden uitgerust terwijl deze niet altijd ten volle wordt benut. Ook zouden parallel uitgevoerde taken, zoals het verwerken van een zoekopdracht, meer kostbaar dataverkeer veroorzaken omdat deze worden opgeknipt in diverse subtaken.

Hölzle concludeert dat energiezuinige multicore-cpu's een logische en nuttige ontwikkeling zijn en dat dergelijke chips ook binnen Google veel gebruikt worden, maar dat snelle singlecore-processors voor bepaalde toepassingen momenteel nog de voorkeur genieten. Processors met meerdere kernen zouden minimaal een factor twee sneller moeten zijn om de traditionele single core-ontwerpen definitief in de geschiedenisboeken te laten verdwijnen.

Reacties (159)

[charlie]

Multicore voor servers is in elk geval een prachtige ontwikkeling die hand in hand gaat met Virtualisatie :

• Heel veel servers hebben niet de volle rekencapaciteit van een hedendaagse processor nodig, zeker niet continu.
• Door meerdere cores naast elkaar op 1 CPU, kan je ook meerdere virtuele servers op volle belasting draaien naast elkaar, zonder dat ze elkaar beïnvloeden

Dit samen met het feit dat een moderne server met sloten geheugen kan uitgerust worden, zorgt ervoor dat je steeds meer server op 1 fysieke machine kan laten draaien naast elkaar.

[ACM]

Je eerste punt is juist een argument om meer VM's dan cores te hebben, maar dan wel snelle cores. Goed voor de response-tijden van ieder van die VM's en het zorgt er voor dat e.e.a. toch allemaal cpu-tijd kan krijgen

[charlie]

Uiteraard kan je meer VM's draaien dan wat je aan Cores hebt, beide argumenten vullen elkaar gewoon aan. Ruwweg gezegd zorgt een verdubbeling van het aantal cores voor een verdubbeling van het aantal VM's wat je kan draaien.
Hierbij mag je Hyperthreading niet als een verdubbeling van de cores beschouwen. HT is immers geen volledige extra rekenkern, maar deels een "virtuele" processorcore op je processorcore. Dit gewoon om het allemaal wat ingewikkelder te maken...

[Gerardus]

dat is inderdaad wel waar, maar zelfs als je een beetje decent high end server hebt waar je bv 2 virtualisaties op hebt draaien zal de rekencappaciteit in het overgrote merendeel van de tijd niet zwaar gebruikt worden. je zit alleen vaak met geheugen en /of netwerkcappaciteit te koekeloeren. dat zijn de punten waar een server wel eens "vol" door zit.

als je bijvoorbeeld 2x 2 cores hebt (redunantie of hoe je het ook wilt noemen) kan je er in principe zelfs met voldoende geheugen enzo makkelijk 8 virtuele zervers laten draaien.

voorbeeld, Ik heb zelf hier thuis een low-end vrij oud servertje waarop me het is gelukt om win 2003 als host OS en 2 x win 2003 en een keer als test win 7 enterprise (kaal) tegelijkertijd te draaien.

probleem zat hem bij mij in de max 4 Gb memory, de dual core 2,0 Ghz processor kon het makkelijk hebben.

tegenwoordig draait ie mijn backup en me mail alleen nog maar, en voor schooldoeleinden een win2003 testomgeving die ik eens in de 2 weken een uurtje nodig heb ofzo.

[Anoniem: 303530]

een simpel rekensommetje

stel:
een 1-core processor op 1ghz verbruikt 10w + 4w voor chipset
een 2-core processor op 1ghz verbruikt 20w + 4w voor chipset
een 1-core processor op 2ghz verbruikt 30w + 4w voor chipset
(getallen uit duim gezogen)

ra ra, wat is dan, vanuit het performance per watt oogpunt, de meest effienciente manier om de performance te verhogen?

daar ligt nu juist het probleem: het is veel efficienter om 2 cores aan elkaar te plakken dan het is om 1 core sneller te maken.

[catfish]

maar op de 2GHz machine zal je applicatie 2x zo snel werken (mits er geen bottleneck is), op de 2x 1GHz machine is dat lang niet zeker...

[bwerg]

Nee, maar hoe hoger je gaat met kloksnelheden en aantallen cores, hoe groter/extremer het verschil wordt. Om maar even in de kloksnelheid-maal-cores-voorbeelden te blijven:
Veel moderne quad-cores lopen op 3GHz en verbruiken zo'n 100-130W bij typische belasting. Hoe veel verbruikt een single-core met een even krachtige architectuur op 12GHz, denk je?

Om over de i7 hexa-cores maar te zwijgen want 20GHz... tuurlijk is een quad-core op 500MHz onzin en wil je dan liever een 2GHz single-core. Maar dat principe gaat niet altijd op.

[Reactie gewijzigd door bwerg op 3 augustus 2024 10:59]

[Anoniem: 77640]

Hörzle's document is wel wat intelligenter dan men hier doet uitschijnen.

De discussie is niet single-core versus multi-core, maar multi-core met krachtige cores versus many-core met zwakkere cores. Die laatste halen in theorie wel betere prestaties / watt, maar in de praktijk moet er nog rekening gehouden worden met de verhoogde complexiteit van steeds meer cores te coordineren. Z'n duimregel is om de cores niet trager te maken dan de helft van de snelheid van een single-core.

"So go forth and multiply your cores, but do it in moderation..."

Alle huidige multi-core CPUs van Intel en AMD voeldoen dus aan z'n criterium. Hij ziet echter geen toekomst voor CPUs met véél meer cores op hetzelfde oppervlak die elk veel zwakker zijn.

Intel's Sandy Bridge en AMD's Bulldozer architectuur zetten ook door in de goede richting. Ze verhogen het aantal cores zonder aan de prestaties per core te raken (in het geval van AMD per module dan). Die verhoogt zelfs wat.

[Reactie gewijzigd door Anoniem: 77640 op 3 augustus 2024 10:59]

[Bjornmeijer935]

Het voordeel van AMD's bulldozer is dat deze meerdere cores van een module op een thread kan zetten waardoor deze dus sneller klaar zou moeten zijn in theorie.
Ook hebben programmeurs hier geen last van omdat de processor dit uit z'n eigen zou moeten doen als ik me niet vergis tenminsten.

[Anoniem: 77640]

Het voordeel van AMD's bulldozer is dat deze meerdere cores van een module op een thread kan zetten waardoor deze dus sneller klaar zou moeten zijn in theorie.

Neen, wat AMD voor Bulldozer een core noemt is echt helemaal geen volwaardige core te noemen. De module is de echte core, en wat zij een core noemen is gewoon de helft van de rekeneenheden, die aan een specifieke thread toegewezen kunnen worden.

Dat maakt het tot een goed alternatief voor Hyper-Threading, maar niks revolutionairs. De front-end van een module is niet breder dan die van Intel's Core architectuur, en dus zijn de piekprestaties ook vergelijkbaar.

[oddish2211]

en stel men maakt een multicore processor met 1 of 2 kernen die een aantal megahertz hoger geclocked zijn dan de andere kernen?
zoiets als AMD Turbo Core http://www.pcper.com/article.php?aid=897

[Reactie gewijzigd door oddish2211 op 3 augustus 2024 10:59]

[ACM]

Het is niet per se argumentatie voor single vs multi-core, maar vooral voor veel langzame vs weinig snelle cores. Dus een snelle dual-core vs een langzame quad-core kan ook prima in deze argumentatie vallen

Niet-symetrische processoren zullen qua ondersteuning van de operating systems nog wat lastig zijn, hoewel men natuurlijk al precies dat - maar dan automatisch - doet bij de recente processoren. De turbo-modus e.d. geven al een of meerdere cores een flinke boost als blijkt dat de omstandigheden het toelaten. Een OS zou de processen zodanig kunnen proberen te verdelen dat daar gebruik van gemaakt wordt voor processen die dat echt nodig hebben.

[koelpasta]

Dat heet een asymetrisch design.
Het kan absoluut nut hebben.
Toevallig keek ik gisteren naar een Google Tech Talk die hier over ging.
http://www.youtube.com/watch?v=KfgWmQpzD74

Afhankelijk van de hoeveelheid on-die resources en de te volbrengen taak (hoe parallel is de taak?) kan het performance optimum liggen in een design met enkele uitgebreidere/betere/snellere kernen met daaromheen veel simpele kernen.

Een design is niet zomaar beter of slechter. Je maakt een design om zo optimaal mogelijk een bepaalde set van functies te verrichten.
En in sommige gevallen is wat jij bedacht hebt inderdaad de beste oplossing.

[bredend]

Die zijn er al, iets met Turbo. Sommige kernen kunnen dan tijdelijk 'overklokken' als de rest niets te doen heeft.

[Da_Teach]

Mijn i7 kan dat ook, standaard draait deze processor op 2.9Ghz met 4 cores, maar als er maar 1 core gebruikt wordt dan draaien er 3 op 1.5Ghz (of minder) en 1 core op 3.4ghz.

Ik heb het uitgezet en al mijn cores op 4ghz gezet

[CH4OS]

Mijn i7 kan dat ook...

En dát is nou precies waar Bredend op doelt... Je bevestigd zijn bericht dus alleen maar...

Op zich zit er wel een logica achter, maar dan vraag ik me af of hetzelfde ook op gaat voor multi threaded applicaties?

[Romke]

Heb je het koud op je werkkamer?

[i-chat]

kortom programma's worden op dit moment nog te veel met eenvoudige logica, en dat komt omdat er nog geen wiskundige bezig is geweest met een efficiënte formule die multi-core rekenen beter schaalbaar maakt, -

en wat is nu het hele punt, naar mijn idee erg simpel x86 is niet meer geschikt voor bepaalde taken, en nu moet je op zoek naar architecturen die complexe berekeningen efficiënter kunne verwerken.

[max3D]

Intel doet juist erg veel onderzoek naar SIMD en heeft redelijk wat wiskundigen in dienst o.a. voor multi core efficientie verbeteringen. Er liepen minimaal drie volwaardige programmas intern de laatste jaren om grootschalig parallisme en multi cores in de orde van grootte van 32 - honderden mogelijk en zinvol te maken.

Of x86 wel of niet geschikt is, is een te eenvoudige vraag. Er is niet zoiets als een X86 architectuur. Het zijn allang risc processoren die een X86 (feitelijk de X66 instructieset ISA) naar de buitenwereld bieden.

AMD heeft met de x86-64 instructie set uitbreiding de ISA toekomst vast gekregen en Intel gedwongen dat spoor te volgen.

Door het continu oprekken van de ISA met uitbreidingen voor o.a. meer register vector optimalisaties, 4 operand extensies etc maakt Intel de discussie over X86 achterhaald. Het interesseert programmeurs niet wat er intern gebeurd, maar wat de instructieset is en eigenlijk in hoeverre de compiler die efficient ondersteunt.

Intel heeft krankzinnige bedragen en bergen talent gestopt in haar Vtune en professionele compiler ontwikkelingen. Het is voor andere instructiesets moeilijk om daar tegen op te concurreren.

Wat je ook vindt van de oorspronkelijk X86 instructieset heeft Intel die discussie wat zinloos gemaakt door de extreme optimalisaties en de vindingrijkheid qua extensies. Ze zijn er zo goed in dat ze niet alleen kunnen concurreren met moderne alternatieve instructiesets , maar dat ze hun eigen Itanium architectuur in de voet geschoten hebben.

[Anoniem: 77640]

...en dat komt omdat er nog geen wiskundige bezig is geweest met een efficiënte formule die multi-core rekenen beter schaalbaar maakt...

Een wiskundige formule?

Multi-threaded programmeren heeft niks met formules te maken. Het is zoals meer mensen inzetten om een taak uit te voeren. Daar bestaat ook geen algemene formule voor. Het hangt af van de taak hoe je de extra werkkracht het best inzet.

Het is in de eerste plaats een nieuwe denkwijze voor de programmeurs. Decennia lang werd voor PC's alles serieel uitgevoerd. De bewerkingen worden stap voor stap uitgevoerd worden en je weet precies in welke stap waar het programma zich bevind. Het programma vormt een eenvoudig te volgen draaiboek. Met multi-threading is het alsof meerdere personen elk een draaiboek hebben dat ze moeten opvolgen. Plots is het onoverzichtelijk wie op welk moment waar exact mee bezig is, en het vergt heel wat coordinatie om de eigenlijke taak niet in het honderd te laten lopen.

Maar wees gerust, de huidige studenten computerwetenschappen en software-ontwikkeling groeien op met multi-core processoren en zijn er zich ten volle bewust van dat hogere prestaties behaald kunnen worden door de taken te verdelen over verschillende cores, en leren ook verschillende technieken om de coordinatie tussen de cores te regelen.

Verder vindt er ook traag maar zeker vooruitgang plaats op het vlak van programmeertalen en compilers. De huidige programmeertalen zijn grotendeels gericht op single-threaded uitvoer waarbij de processor dus slechts met één bewerking bezig is. Programmeertalen om hardware te beschrijven gaan er net vanuit dat alle bewerkingen simultaan uitgevoerd worden. Door dat idee ook toe te passen op programmeertalen voor CPUs worden ze geschikt voor multi-threaded ontwikkeling. Er is echter nog een lange weg te gaan en nieuwe programmeertalen worden slechts erg traag in gebruik genomen aangezien het een gigantische investering is om software te herschrijven.

Het potentieel van multi-core is echter enorm. Een doorsnee programma zou volgens onderzoek wel 1000 dingen simultaan kunnen doen. Dus op termijn zal je echt absoluut geen single-core processor meer willen.

[Reactie gewijzigd door Anoniem: 77640 op 3 augustus 2024 10:59]

[mark184]

waarom is het nog steeds niet mogelijk om een tread in stukje op te delen en elke core een deel ervan te berekenen?

[MMaI]

omdat niet alle taken paralelliseerbaar zijn. Bijvoorbeeld berekeningen die een lineair verloop of instructie hebben en over de gehele berekening lang doen zijn niet paralelliseerbaar. Alleen code die meerdere taken moet afhandelen is paralelliseerbaar.

Verder is er altijd een stuk overhead in code die op meerdere kernen draait, welke er voor zorgt dat alle gegevens gesynchroniseerd blijven, en het gehele proces wacht totdat alle taken zijn afgerond voordat de volgende taak wordt gestart. Het aandeel paralelliseerbare code moet dus grotere snelheidswinst geven dan het snelheidsverlies dat de extra overhead kost.

Lees dus ook de link naar de wet van Amdahl even, die tekst zou 100% een antwoord op jouw vraag moeten geven.

[charlie]

Omdat veel processen afhankelijk zijn van voorgaande processen : Je kan niet aan een volgende stap beginnen voor je het resultaat van de voorgaande stap kent.

[Cameleon73]

Omdat het op veel problemen kan stuiten (en de winst niet altijd in verhouding staat).

[joco]

dat doen ze in 1 core met meerdere alu's toch al?

out of order excution, branch prediction.. en zo

[bredend]

Multicore-cpu's zijn gewoon een simpele truc van Intel en AMD om te verbloemen dat ze het aantal GHz niet meer eenvoudig omhoog kunnen krijgen. Dualcore kan ik nog wel in komen, maar verder wil ik het liefst een hoge frequentie. En een goede instructieset.

_{(Ik draai vooral singlethread-toepassingen)}

[Anoniem: 77640]

Ik draai vooral singlethread-toepassingen

Dat dacht je maar. Als je Windows draait open dan eens Task Manager en kijk naar de Performance tab. Ik heb momenteel nauwelijks iets open staan en er zijn 70 processen en 883 threads.

Meer dan 10 threads per toepassing dus.

Er is nog een gigantisch ongebruikt potentieel om die threads meer simultaan te laten lopen (en nog meer threads te gebruiken). Zelfs algoritmes die aanvankelijk single-threaded lijken, zijn nagenoeg zonder uitzondering multi-threaded te maken. Maar deze worden nog maar nauwelijks toegepast.

De reden waarom het zo traag gaat is net omdat de meeste mensen nog met een dual-core zitten, en daarvoor is de snelheidswinst amper de moeite. Pas als quad-core mainstream is zullen ontwikkelaars meer moeite steken in het optimaliseren voor simultane multi-threading. Een beetje kip-en-ei probleem dus tegenwoordig.

En een goede instructieset.

De voornaamste verbetering die ons nog te wachten staat is de toevoeging van 'gather' en 'scatter'-vectorinstructies. Momenteel zijn de vectorinstructies beperkt tot het verwerken van data die mooi achter elkaar opgeslagen is in het geheugen. Maar dit is eerder de uitzondering dan de regel.

Via gather/scatter zou praktisch elke lus paralleliseerbaar zijn.

[bwerg]

Kan wel zijn dat je 883 threads hebt maar in idle nemen die misschien 1% van je CPU-kracht gemiddeld, als het niet lager is. Ga je dan een zware rekentaak aanzetten (slecht geoptimaliseerde game of rar-achtig ding, zware berekeningen die niet te multithreaden zijn) dan neemt die taak eeeh... 100% van één core. Tuurlijk draai je veel multithreaded spul maar het gaat in dit artikel om de zware shizzle waarvoor één hedendaagse core niet genoeg is. Ja, het kan (vaak) beter geoptimaliseerd en dat is het nog niet, en zolang dat nog niet is kan iemand best voornamelijk single-threaded (zware) processen draaien.

Overigens snap ik niet wat google te klagen heeft aangezien één core van een i7 nog steeds veel sneller is dan een pentium 4-core (de laatste CPU waarbij het doel was één core zo snel mogelijk te maken). Mocht de i7 een single-core op hogere kloksnelheid zijn, dan denk ik niet dat die kloksnelheid significant hoger zou zijn dan die de quad-cores nu hebben. De 32nm-variant van de i7 draait al met gemak op 3,3GHz, is dat nog steeds te laag? Als het een single-core zou zijn was het misschien een 4GHz met hetzelfde verbruik (want verbruik is toch het criterium dat er voor zorgt dat de cores niet meer sneller "kunnen"), whoop-de-doo...

[Reactie gewijzigd door bwerg op 3 augustus 2024 10:59]

[Anoniem: 77640]

Overigens snap ik niet wat google te klagen heeft aangezien één core van een i7 nog steeds veel sneller is dan een pentium 4-core.

Daar klaagt men dan ook helemaal niet om. Lees het document. Google wil niet dat men de cores kleiner en trager maakt om er zo meer op één chip te krijgen. De totale prestaties gaan daarbij wel wat omhoog en het verbruik wat omlaag, maar de software haalt er niet de maximale prestaties uit. Merk op dat het hier wel degelijk over multi-threaded software gaat!

Google doet dus eigenlijk gewoon een oproep dat men bij het bepalen van het ideale aantal cores dat men op eenzelfde oppervlak plaatst niet alleen rekening moet houden met de som van de prestaties en het verbruik, maar ook ook met de software.

Eigenlijk is de titel hier heel misleidend. Multi-core is wél steeds beter. Echter is nóg meer cores, waarbij men de prestaties per core moet verlagen om ze kleiner te maken, niet altijd beter.

[bwerg]

Daar klaagt men dan ook helemaal niet om. Lees het document. Google wil niet dat men de cores kleiner en trager maakt om er zo meer op één chip te krijgen.

Ja, en dat zeg ik dus net, dat gebeurt niet. Bij nieuwe architecturen worden de CPU's ook per core gewoon sneller. Tenzij je uitzonderingen gaat zoeken als de atom dualcore of zo maar dat is flauw, een i7 is gewoon op 3,33GHz verkrijgbaar en daarmee is hij (dankzij een krachtigere architectuur) een stuk sneller dan de snelste pentium 4. Met turbo kan een i7 trouwens naar de 3,6GHz zonder overclock. Hadden ze één core per CPU gemaakt dan was die niet veel sneller geweest lijkt me, alhoewel ik me nou wel begin af te vragen hoe snel je één i7-core zou kunnen klokken binnen een TDP van 130W.

[Reactie gewijzigd door bwerg op 3 augustus 2024 10:59]

[Anoniem: 154505]

Ja, maar dat betekent dus dat een i7 maar liefst 25% sneller is dan mijn laptop van 7 jaar oud. What happened to Moore's law?

[millman]

Het lijkt mij hier te gaan over bijvoorbeeld een Atom met een x aantal cores tegenover een snelle singlecore p4 (of pentium D met 1 extra thread, is in weze ook een single core). Dan kan het in bepaalde gevallen in het voordeel van de hoger geklokte cpu uitvallen. Echter lijkt mij deze conclusie zo simpel, dat je daar wat mij betreft geen nieuwsbericht aan hoeft te wijden. Wel een slimme manier om je naam weer eens de wereld in te helpen. Goed gedaan google!

[kimborntobewild]

70 processen terwijl je bijna niks draait?
Misschien tijd om eens wat overbodige services (zoals eye-crap) uit te schakelen en met msconfig de zaak bij 'Opstarten' op te schonen...

(Ik heb hier momenteel trouwens 28 processen draaien.)

[Countess]

het is eerder omdat de extra transistors gebruiken om de core complexiteit te verhogen tot steeds minder snelheidswinst leid.
we zijn daar al ruim over het punt van diminishing return.

het is veel efficiënter om die transistors te gebruiken om meer cores te maken.

[koelpasta]

Het is geen truuk om iets te verbloemen hoor.
Het is een grens die al lang bekend was.
Het is altijd een afweging hoe je de on-die resources inzet.
Meer simpele cores ten opzichte van minder maar complexere cores.
Probleem is dat als je veel simpele cores neemt je tegen het probleem van parallelisatie aanloopt. Niet alles is goed te verdelen over meerdere cores (ook niet door het goed toepassen van multithreading).
Elk probleem heeft een deel dat te paralleliseren is en een deel dat niet te paralleliseren is.
Grof gezegd heeft een ideale processor (of bijvoorbeeld cluster) in verhouding net zoveel parallele resources als het probleem dat nodig heeft.
En dus ook net zo veel seriele resources als het probleem vereist.

Een ideale processor is dus toepassingsafhankelijk.

[Anoniem: 288594]

Precies, maar als het OS in kwestie al niet goed in SMP is ben je NOG veel verder van huis.
Windows is geweldig in core-hopping, zo lijkt het alle cores te gebruiken maar doet het niet.
Linux heeft van hetzelfde last.
Te veel software en operatingssystemen zijn opgebouwd vanuit het 1 core princiepe, met Windows voorop.
Als je OS nooit begonnen is als MT systeem word het later enorm lastig het om te gooien.
Windows 3.x kon ook al Multi-tasking!! Maar geen Multi-threading!
De Windows GUI kan het nog steeds niet voor veel taken.
Linux is er wat beter in, maar het is allemaal niet geweldig.

BeOS was er fantastisch in. OS/2 ook.

Wel is het zo dat Linux een inhaalslag aan het maken is op de desktop, heb het niet over server zaken, daar kan Linux het allang en heel goed.

[CH4OS]

Multicore-cpu's zijn gewoon een simpele truc van Intel en AMD om te verbloemen dat ze het aantal GHz niet meer eenvoudig omhoog kunnen krijgen.

Brute snelheid is tegenwoordig ook niet alles. Zie het als een sportwagen. Gaat bloedsnel, maar kan weinig meenemen. Een busje kan meer meenemen, maar moet het helaas wat trager doen. Vervolgens heb je de vrachtwagens, nog meer vracht tegelijk meenemen, maar met een nóg lagere snelheid. Wat dat betreft is er dus voor alle mogelijkheden wat te zeggen.

Dualcore kan ik nog wel in komen, maar verder wil ik het liefst een hoge frequentie.

Waarom? Ik heb liever zoveel mogelijk data tegelijk verwerkt hebben, met - als het kan - ook wel acceptabele snelheid... Het is dus gewoon uit de hoogte of de breedte en (voorlopig) nog niet allebei.

En een goede instructieset.

Waarvoor heb jij exotische instructiesets nodig dan?

(Ik draai vooral singlethread-toepassingen)

Misschien een mogelijkheid om te migreren naar multithreaded toepassingen? Zul je zien dat dat vele malen sneller is dan singlethreaded...

[Anoniem: 151917]

Inderdaad, geef mij maar een goede snelle dual core met een goede instructieset. Ik zou geen 6-8 core processor willen hebben (helemaal niet voor de prijzen waarvoor ze te koop zijn).

[analog_]

Jaja, want alle commerciele software is gecompiled met SSE4a support. Wat denk je zelf.

[Katsunami]

Dit is iets dat Microsoft jaren en jaren heeft lopen tegenhouden, zelfs Windows ZELF kan het amper!!

Bullshit. Windows kan al fatsoenlijk multi-threaden sinds Windows NT 3.1. Voor het geval je het nog niet weet, een groot stuk van Windows NT 3.1 bestond uit de kern van OS/2 3.0. Windows NT is niet voor niets heel lang compatible geweest met veel OS/2-applicaties.

Dankzij Micorsoft die veel te lang op 1 thread apps heeft toegelaten (ja ook in windows NOG ALTIJD!!) zitten je daar nu met hardware waar je weinig mee kan.

Je weet niet waar je het over hebt. Het heeft niks te maken met "toelaten". Het is al ruim 15 jaar mogelijk om multi-threaded te programmeren. Dat niemand dat doet omdat het voor dingen als een tekstverwerker niet nuttig is....

Wil je een multi-threaded app voor Windows? Kijk eens naar:

Deep Fritz 12

Het schaakprogramma ondersteunt tientallen cores, en per verdubbeling van het aantal kernen wordt het rond de 85% sneller. Als je van 1 kern naar 2 naar 4 gaat, levert dat dus een snelheidswinst op van 1x 1.85 x 1.85 = 3,42x. Je kunt het ook in het programma zelf zien, want hij geeft aan hoe snel hij rekent en met hoeveel posities per seconde.

Deep Fritz 12 is hét bewijs dat je gewoon fatsoenlijk multi-threaded kunt programmeren onder Windows. (En Deep Fritz is niet het enige schaakprogramma dat multi-threaded is, en daar veel voordeel uit haalt.)

[Reactie gewijzigd door Katsunami op 3 augustus 2024 10:59]

[Anoniem: 175233]

En zelfs de tekstverwerkers zijn wel degelijk multithreaded. De spellingscontrole draait bijvoorbeeld in een aparte thread, net als het printen. Maar veel meer winst valt er simpelweg niet te behalen.

De Mac is qua multithreading trouwens wel het slechtste! Die hebben nog als laatste het oude cooperative multithreading toegepast zoals je dat in Win3.x had, in de tijd dat OS/2 en Win9x allang op op pre-emptive multithreading waren overgestapt.

OS/2 was in theorie heel mooi, en de programmeurs waren ook heel erg er op gericht om te multi-threaden. Maar niet omdat OS/2 op dat punt zoveel beter was als OS, maar gewoon omdat dat als best-practice voorgeschreven was. Niettemin had OS/2 grote problemen, zoals de single-input queue, waardoor één crashend programma je hele interface blokkeerde... Windows NT was op dat punt gewoon verreweg superieur aan OS/2... maar gebruikte voor die tijd teveel RAM. Nu RAM geen probleem meer is, is de NT architectuur gewoon veel beter dan OS/2. Ook qua multithreading mogelijkheden.

Het probleem van multithreading is simpelweg dat het veel lastiger te programmeren is, en sommige problemen zelfs inherent geen (effectieve) multithreading toelaten. Zolang er in computers slechts één core aanwezig was, was het zinloos daar veel tijd in te steken, omdat je alleen maar extra overhead zat te creeeren. Nu het steeds lastiger wordt om snellere single core's te maken, moesten de cpu fabrikanten wel naar multi-cores overstappen, en is er meer reden om de software ook beter multi-threaded te maken.

[Anoniem: 46304]

(Traditionele) schaakprogramma's zijn natuurlijk ook makkelijk te paralleliseren omdat elk pad van alternatieve zetten dat berekend wordt per afsplitsing in een aparte thread gestopt kan worden.

[bwerg]

Ja. En dit slaat dus tang noch varken.

Tientallen jaren geleden? Waren er toen al quadcores op de markt dan? Xo nee, waarom steekt OSX dan onnodig resources in multi-core ondersteuning als die resources helemaal niet gebruikt worden? Dat zou juist vrij slordig zijn, eigenlijk.
Windows zelf kan het amper? Hoe komt het dan dat er hier tientallen processen lopen in mijn windows en zelfs de 2% belasting die ik soms zie in idle, al verdeeld wordt over 2 cores?
Microsoft die nog altijd meerdere apps op één core laat draaien (niet één thread, 2 onafhankelijke apps zijn per definitie losse threads)? Tuurlijk joh, alleen hebben ze er überhaupt geen zeggenschap in of onafhankelijke programmeurs hun programma's multithreaded maken, en dat kan nou al wèl tientallen jaren.

Het probleem zit hem niet in de processoren en niet in de OS'en. Het probleem is dat het niet zo simpel is om eventjes je programmatuur multithreaded te maken. Voor sommige programma's zels per definitie onmogelijk.

[Reactie gewijzigd door bwerg op 3 augustus 2024 10:59]

[Anoniem: 282252]

Ik denk dat BASMSI er op doelt dat een context switch binnen windows minder efficient uitgevoerd wordt dan bij bijvoorbeeld OSX of Linux.

Dit is de hoofd reden waarom Safari en iTunes minder goed en snel werkt dan op OSX. Apple heeft zover ik begrepen heb een vrij directly port naar Windows gedaan met dezelfde 'technieken' waarbij erg veel threads gebruikt worden.

Met Windows is het nu eenmaal zou dat als je een applicatie vergelijkend wil laten presteren je minder threads moet gebruiken.

Dit is overigens ook de reden waarom programatuur als Samba (see http://www.samba.org/samb...s-Guide/architecture.html) en PostgreSQL weinig of geen threads gebruiken.

Bij PostgreSQL en Samba wordt simpel weg een nieuw process gestard wat veel efficienter is voor dit soort toepassingen.


Een algemene techniek voor GUI applicaties om een thread te maken voor de GUI (her tekenen van scherm) en een thread voor de rest.

[Anoniem: 46304]

Bij PostgreSQL en Samba wordt simpel weg een nieuw process gestard wat veel efficienter is voor dit soort toepassingen.

Dat zal eerder te maken hebben met hun Linux achtergrond, in Linux zijn threads pas vrij laat geintroduceerd. Traditioneel werk je on der Unixen met meerdere processen en voor communicatie tussen processen zijn die dan ook veel beter ontwikkeld dan windows. Multithreading is pas ingevoerd nadat Windows het al lang ondersteunde, het voordeel is dat het minder overhead geeft dan meerdere processen.

[Anoniem: 35352]

In de praktijk is het verschil in overhead onder linux & de meeste unix'en relatief klein, mede daarom was het ondersteunen van kernel-level threading ook niet zo'n prioriteit als onder Windows/NT.

[Aham brahmasmi]

Ja. En dit slaat dus tang noch varken.

Tientallen jaren geleden? Waren er toen al quadcores op de markt dan?

Nee maar er waren al wel multi-processor moederborden.

[Soldaatje]

Wat is dit nou weer voor totale onzin?
Over welke windows heb je het?
XP kan prima meet meerdere cores werken, het is de software die multithreaded moet zijn.

[freaky]

Niet noodzakelijk.

Als je veel single threaded applicaties naast elkaar draait kan je OS (enigszins recent OS dan... DOS wordt lastig ) die prima over verschillende cores verdelen.

Het is pas echt vervelend als je maar 1 single threaded applicatie hebt en veel cores. Dan staan er veel - 1 (praktisch) niks te doen (alhoewel het interne OS spul wellicht over meerdere cores loopt is die load meestal erg verwaarloosbaar).

[poepkop]

Aha, de limiet bereikt... Waarom kan een Power7 dan harder dan 5ghz? De schakelsnelheid kan echt wel wat omhoog, ook de IPC valt zeker nog op te winnen.

En het verschil tussen Mac en PC? In het Adobe pakket vind ik de Mac trager, dus het ligt aan de programmeur.

[Anoniem: 288594]

4,25GHz max...waar haal jij die 5GHz vandaan?
En er zijn er wel meer die die Snelheid halen, zoals de P4 die reeds lang niet meer in productie is.
De kosten zijn domweg te hoog om zo'n CPU te blijven maken.

[Bacchus]

Èn om hem te laten draaien. De Netburst-architectuur was gemaakt om hoge kloksnelheden te kunnen halen maar het bleek onhaalbaar om de processor van het benodigde vermogen te voorzien.

[GamingZeUs]

Niet al te offtopic is overigens dat BeOS weer nieuw leven in wordt geblazen als Haiku, nu nog in alfastage.

[Anoniem: 288594]

Ik ga het zeker proberen, als vroeger OS/2 en BeOS liefhebber kan me dit bekoren.
Linux is wel aardig, maar SMP op de desktop is niet geweldig.
Iets waar OS/2 en BeOS in uitblonken.

[sfranken]

Ga je eerst eens inlezen in de theorie voor je een domme opmerking maakt aub. Linux en problemen met multicores? Verklaar mij dan eens waarom je het op een PS3 (met 8 kernen..) kan laten draaien?

[NoResult]

Op een PS3 draait Linux op 1 core. De overige cores kunnen special purpose worden ingezet.

[sjaakwortel]

volgens mij zaten er 7cores in een PS3 waarvan er een word gebruikt voor het besturings systeem

[martijnvanegdom]

Beste BasMSI,

Aan de programmeertalen in je profiel te zien heb weinig kennis over talen waarin je multi-threaded programmeert.

Sommige processen zijn bijzonder lastig parallel uit te voeren,vooral recursieve functies zijn daar voorbeelden van. Nu zijn sommige van deze functies wil om te schrijven naar een parallelle evenknie (bijvoorbeeld de faciliteit berekening).

Maar zeker de typen algoritme die google gebruikt willen nog weleens erg lastig zijn om ze parallel te maken, als het überhaupt al kan.

Daarnaast, de complexiteit van je software neemt vaak ongelooflijk toe als je lastig algoritme parallel gaat doen.. Daar vergis je je nogal in.. dus niet zo hard roepen als je eigenlijk niet echt van toeten of blazen weet.

[Anoniem: 46304]

Nu zijn sommige van deze functies wil om te schrijven naar een parallelle evenknie (bijvoorbeeld de faciliteit berekening).

faciliteit berekening? Wa's dat? Ik kan iets in de belastingwet vinden maar verder geen idee. Of bedoel je faculteit? Om dat recursief te berekenen doet men alleen uit educatieve overwegingen omdat het eenvoudig uitlegt wat een recursieve functie doet, in het echt is een gewone loop natuurlijk veel sneller omdat je niet iedere keer je hele stack hoeft op te slaan en terug te halen.

[analog_]

Dat moeten programmeurs niet doen maar compilers, er zijn namelijk architecturen die een circular loop buffer hebben om dat op te vangen. Denk aan de ibm390.

[Miuccia]

Waarom locked de hele Windows shell als 1 stom programma een error moet geven?
Je kan multithreaded programma's op Windows draaien, maar de eigen shell is zo bagger als het maar kan.

Bas, ik denk dat je het hier hebt over Windows 9x, met DOS als onderlaag. Bij de Windows NT-achitectuur waar 2000, XP, vista, 7, etc op draaien is dit alleen niet meer zo en draaien programma's onafhankelijk van elkaar.

Als je tweakers-profiel echt klopt, had je dit zelf ook geweten... Maargoed, toegeven dat je de plank volledig mis slaat is makkelijker gezegd dan gedaan...

[Relief2009]

We hebben het hier over Multithreaded programmeren en niet over de shell. Het is veel makkelijker om toe te geven dat je onzin praat.

[Anoniem: 353647]

Opvallend nieuws. Maar wel begrijpelijk. Inderdaad, men kan technisch gezien gewoon geen hoge kloksnelheid produceren.

[MMaI]

zeker wel, alleen gaat de performance/watt daarmee sterk achteruit, en is het voor de fabrikanten een stuk duurder dan meerdere kernen plaatsen.

Overigens is het in de processen waar Hölzle naar verwijst ene kwestie van code. Google gebruikt namelijk heel erg veel systemen om deze taken uit te voeren, wat met goede code neer zou moeten komen op multicore processen. Verder is deze manier van berekenen afhankelijk vna de traagste factor, en dat is bij vrijwel alle systemen die google gebruikt het interne geheugen (HDD in de google bakken is alleen voor storage/backups). Zie ook: http://arstechnica.com/ha...nside-a-google-server.ars

[koelpasta]

De performance per watt gaat welliswaar omlaag, maar dat komt omdat je steeds meer energie het systeem in moet pompen om een bepaalde hoeveelheid extra performance te halen.
Het grootste probleem is dus ook de warmteopwekking die daarmee gepaard gaat.
Het is daarom ook niet raar dat de heren overclockers met dingen als vloeibaar stikstof in de weer gaan om alle overtollige energie af te kunnen vloeien.

[Anoniem: 288594]

Kan wel, maar is domweg te duur om interessant te zijn.

[Forsith]

@mark184: Omdat bij de executie dit zou betekenen dat thread op elkaar dienen te wachten, waar je alsnog niets mee opschiet, bijvoorbeeld dat thread0 gegevens nodig heeft die thread1 berekent, waardoor thread0 alsnog moet wachten. Dit _kan_ wel werken in bepaalde situaties, maar meestal is in dit geval één thread net zo snel, zoniet sneller.

Ik ben het dan ook roerend eens met Google. Het moet is afgelopen zijn met die core-schaling, die zoals bredend zo mooi zegt, een truc is om het aantal kloktikken tussen de 1 en 4 GHz te houden. Zelf heb ik wel een quadcore, en als software-ontwikkelaar durf ik wel voorzichtig te stellen dat met de juiste compilers het compileren een stuk sneller gaat, maar voor jan-met-de-pet ( { gamers,alledaagse gebruikers} is een snelle single- of dualcore veel geschikter.

*Edit: typo*

[Reactie gewijzigd door Forsith op 3 augustus 2024 10:59]

[MMaI]

je vergeet daarbij dat meerdere cores er ook voor zorgen dat verschillende processen naast elkaar afgehandeld worden. Het gaat bij multicore systemen natuurlijk niet alleen om de snelheidswinst PER PROCES, maar ook over het systeem in het algemeen. Een singlecore handelt maar 1 taak tegelijk af, terwijl iedere computergebruiker tegenwoordig rond de 40 simultane processen (en nog meer threads) zit.

Je verhaal gaat dus alleen op als je system maar 1 taak heeft, en deze taak volledig zelfstandig draait (zoals google's db indexers etc.) dat wil dus zeggen, geen desktop OS, geen userinput, geen background processen etc.

Schakel voor de grap maar eens terug naar een systeem met een P4 Extreme op 3.8 Ghz met maar 1 core, dan merk je al snel dat je redenering niet klopt.

[Forsith]

Daar heb je helemaal gelijk in, maar het is makkelijker dit soort problemen atomisch op te breken. De vraag van mark184 ging niet over een geheel systeem, maar of het een idee was om 1 thread op te breken in kleineren ten behoeve van performancewinst. En zoals ik al zei het kán wel performancewinst opleveren als iets singlethreaded is ontworpen, maar voor standaard applicaties heb je meestal 1 mainthread en nog een subthread voor de GUI (om te zorgen dat het niet lijkt alsof de applicatie "hangt").

Als het gaat om een systeem met meerdere processen (en nu komtie) heb je imho gelijk. Er kunnen meerdere processen parallel door een multicore processor heen. Toch vragen de meeste processen voor Jan Modaal geen processorkracht, behalve het main proces (browser,game etc)

[koelpasta]

Google weet wel beter hoor.
Hoeveelheid cores schalen is de enige optie om in de toekomst meer processing power te halen uit digitale electronica.

Het probleem is namelijk dat complexe single core designs energietechnisch niet goed schalen.
Je kan praktsch gezien geen 20GHz single core cpu maken.
Je kan wel 40 cores op 1 plak CPU prakken, en als die cores relatief simpel zijn dan kost het ook nog eens erg weinig.
Als die 40 cores samen maar 50% efficient zijn (door alle overhead) dan heb je opeens wel de performance van 20GHZ single core.
Het probleem is natuurlijk een algoritme vinden dat 50% efficientie weet te halen...
En het probleem moet ook nog eens voor een goed deel paralleliseerbaar zijn.

[bwerg]

Ik kan merken dat je geen gamer bent want met één core, zelfs al is het een i7-core, gaat gamen toch niet bepaald soepel in moderne games. Zware games maken toch echt al wel minstens van twee cores gebruik tegenwoordig, als het niet meer is. Dual-core? Alleen de snelste dan, een gemiddelde dual-core vindt GTA4 niet fijn. Om maar te zwijgen over dat Civilisation 5 90% efficiënt met een hexa-core kan omgaan (volgens de ontwikkelaars, maar goed).

[Reactie gewijzigd door bwerg op 3 augustus 2024 10:59]

[multipasser]

Opvallend zou ik niet noemen. Ik merk dat hier ook. In aftereffects bv rendert hij soms stukken sneller op 1 core dan met 5 of meer! Raar maar waar. (CS4). CS5 heb ik nog niet voldoende getest om een oordeel te vellen maar hij is wel een stuk sneller, dus misschien ook betere multicore ondersteuning.

Ik denk dat we in een OS meer nut hebben aan een snelle singlecore dan multicore!
Zo overtuigt ben ik nog niet van multicore cpu's. Ofwel hupt de software een beetje achter.

[bwerg]

Liever een snelle singlecore dan multicore? Realiseer je dan wel het volgende: vanaf ongeveer 3GHz gaat de performance per verbruik zeer sterk achteruit. Klinkt leuk, een core op 10GHz in plaats van een quadcore op 3GHz, maar alle desktop-CPU's die tot nu toe richting de 10GHz gingen (al kwamen ze maar tot de 7 - 8GHz) konden dat alleen met koeling van vloeibaar stikstof. Wil je dan nog steeds liever die snelle single-core?

Op gewone lucht-koeling (maar dan wel goede) kom je zo tot 4-4,5GHz, afhankelijk van je hardware natuurlijk. Een single-core op 4,5GHz wordt echt helemaal weggejonast door een quadcore op 3GHz als er ook maar een beetje multithreading in je software zit. En intel zit natuurlijk ook niet te springen om een hooggeklokte single-core te ontwerpen, aangezien 99% van de computeraars gewoon beter af is met multi-core. En je moet je architectuur er helemaal voor gaan optimaliseren terwijl na die 3GHz de winst nog steeds klein blijft t.o.v. de architectuur die niet voor extreme kloksnelheden gemaakt is (zoals de i7).

[Reactie gewijzigd door bwerg op 3 augustus 2024 10:59]

[Amanoo]

Ik weet neit of dat aan de 99% zit. Hoorde laatst nog iemand klagen die een single-threaded applicatie had die hij zo snel mogelijk wilde draaien. Dat soort dingen zul je waarschijnlijk vooral in de professionele markt tegenkomen (in dit geval waar ik het over had was dat ook zo), maar de professionele markt is nog best groot.

[bwerg]

Nee, dat is waar. Er is wel markt voor, waarschijnlijk. Echter blijft het dus zo dat intel geen zin heeft om een nieuwe architectuur te maken (kost veel geld) voor hoge kloksnelheden terwijl dat dus toch niet erg effectief is t.o.v. de architectuur die ze al hebben liggen. Zie de pentium 4 die wel even de 10GHz zou gaan halen. En om nou een single-core i7 te maken... als ze daarop dan ook 75% korting moeten gaan geven dan hebben ze zoiets van "je koopt maar een quadcore" natuurlijk.

Trouwens, intel heeft als compromis al de turbo-functie geimplementeerd (en dat doet AMD nu ook, zij het iets anders). Als één core zwaar belast wordt en de andere cores niet dan kom je dankzij die turbo toch al aan de 3,6GHz met de beste modelletjes. Niet slecht, toch?

[tweakerbee]

Als een taak niet te parelleliseren is, en je wel meerdere cores hebt kan je programma elke keer op een andere core belanden. Dit levert heel veel contextswitches op, waarbij elke keer data uit het geheugen gekopieerd moet worden.
Affinity op een enkele core zetten kan dan voor een verbetering in performance zorgen.

[max3D]

Een modern OS doet dit zelf. Het was in het verleden een goede tip.

[ari3]

Onzin. Ook op een single core CPU is een context switch nodig wanneer aan een andere taak gewerkt gaat worden. Je kunt hooguit performance verliezen als iedere core zijn eigen cache heeft, maar voor de context switch an sich maakt het niet uit of het een single of multi core is.