Hoofdcategorieën
Device Settings

Google: multicore-systemen niet altijd beter

Door Dimitri Reijerman, zondag 19 september 2010 13:37, views: 46.307

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.

Volgende 14:58 Boeing wil zonnevliegtuig 5 jaar in de lucht houden
Vorige 13:18 Relic schrapt Games for Windows Live uit Dawn of War II-uitbreiding
Advertentie

Reacties

«  1  2  3  4  5  »


Dat was ook mijn reaktie, dit is al jaren bekend. Multicore is vooralsnog alleen leuk voor de desktop gebruiker.

Er zijn anders genoeg server toepassingen die wel heel goed van multicore gebruik kunnen maken hoor. Neem bijvoorbeeld een webserver waarbij veel onafhankelijke requests binnen komen. Hier kan absoluut heel goed gebruik gemaakt worden van multicore.

Het blijft echter wel dat vooral ook de kennis bij ontwikkelaars tekort schiet om goed multithreaded the ontwikkelen. Hiervoor is een behoorlijke hoeveelheid extra kennis nodig die maar bij een select gezelschap ontwikkelaars aanwezig is. Dit is ook niet zo vreemd natuurlijk als je kijkt hoe lang er echt veel multi core cpu's zijn. Het duurt natuurlijk ook even voor de grote ontwikkeltalen hierop in kunnen springen.

Eigenlijk vind ik het wel raar dat de ontwikkelaar moet nadenken over hoe het programma multithreaded moet draaien.

Eigenlijk zal een framework toch dit toch meer moeten vereenvoudigen. (laatste keer dat ik multithreaded ging programmeren was toen .NET 2.0 net beschikbaar was. Was best irritant om te doen)

Tegenwoordig heeft .Net 4.0 de parallel uitbreiding, dit maakt het een stuk makkelijker, maar door de niet-deterministische uitvoering van stukken code is gewoon heel veel code niet zomaar parallel te draaien, of het framework dat nou zou willen of niet.

Multithreading vereist vaak het compleet herdenken van je architectuur, er zijn wel kleine dingen, zoals lagen als UI en model in apparte trhreads draaien (wat vaak nog wel te doen is omdat dit vrij los hoort te zitten, maar voor echte snelheids winst is er een andere aanpak nodig.

Ook heb je een limit. Stel dat 25% van het programma (tijd) alleen singlethreaded uitgevoerd kan worden en 75% parallel.

Op 1 processor heeft het programma 100 seconden nodig.
Op 2 processoren heeft het 25 seconden + (75/2) seconden nodig.
Op 4 processoren heeft het 25 seconden + (75/4) seconden nodig.
...
Op oneindig veel processoren heeft het 25 seconden + (75/oneindig) = 25+0 seconden nodig.

Dus ja de processor race van meer instructies per seconden zal door moeten blijven gaan en is nodig.

Ook heb je een limit. Stel dat 25% van het programma (tijd) alleen singlethreaded uitgevoerd kan worden...
Die limiet zal waarschijnlijk ook steeds dichter de nul gaan, na verloop van tijd?
Dus nu bijv. gemiddeld 80% singlethreaded, over 10 jaar 20%, en over 20 jaar 1%.

.NET 2.0 had al primitieve worker threads, (BackgroundWorker class) maar om die zinvol te gebruiken moet je wèl je applicatie zó ontwerpen, dat er vaak losse pakketjes met 'werk' beschikbaar zijn. Dat is gewoon niet van toepassing op iedere applicatie.
En als je applicatie potentieel geschikt is voor backgroundworkers, dan is het nog nodig (nu we nog niet gewend zijn om zo te denken; dat zal ook de komende jaren nog wel blijven tot het gros van de programmeurs 'over' is) om een extra denkstap te zetten, namelijk je programma te verdelen voor de backgroundworkers. Dat zijn extra ontwerp uren, waar niet altijd zin, budget, of tijd voor is.
conclusie: applicaties maken de komende jaren nog niet optimaal gebruik van multicores.

Juist niet echt. Een dual core is voor 90% van de kantoor thuis situaties voldoende, meer dan dat ga je toch echt praten over workstation. Het gebeurt bijzonder weinig dat mijn drie jaar oude quad core bak 100% trekt op al zijn cores. Hij wil nog wel eens een enkele core stressen naar 100%, maar bij de probleem apps ben ik opzoek gegaan naar multithread oplossingen.

Juist voor servers is het interessant om meerdere cores te hebben, op een server wordt over het algemeen niet een enkel proces uitgevoerd, maar juist heel veel. Natuurlijk zijn er wel situaties waarbij een 'trage' multicore bak minder goed presteert dan een 'snelle' singlecore bak. Maar meestal heeft dat meer te maken met code dat niet is geoptimaliseerd voor multithreaded dan met de onmogelijkheid om multicores te gebruiken. In simulaties is het bv. erg moeilijk om met multicores te werken, aangezien de simulatie toch moet wachten op A om B uit te kunnen voeren.

Een leuk voorbeeld is EVE Online, dat gebruikt een enorme cluster (voor games) en daar zitten processen in die ze nog niet hebben omgebouwd om voor deel te halen uit multicore processors. Dit maakt in 99% van de gevallen niet zoveel uit, maar juist waar veel spelers zich verzamelen (in een enkel systeem) loopt men tegen problemen aan. Ze zijn daar dan ook druk bezig om steeds snellere servers voor die systemen neer te zetten en kleine tweaks aan de software te doen zodat ze nog even meer spelers in de clowncar kunnen proppen. De hele codebase herschrijven om gebruik te maken van meerdere cores kost teveel tijd/geld. Snellere hardware aanschaffen is goedkoper (en de huidige software optimaliseren).

Ik zie het dus in zo gebeuren in de meeste gevallen, Software die baad zou hebben bij multicores moet herschreven worden en dat kost vaak teveel tijd/geld. Dat is leuk als je een grote klanten pool heb die veel geld betaald, maar niet voor kleinere software bedrijven/developers.

Google loopt geheel niet te mekkeren, ze leggen alleen de situatie uit in een (white paper) pdfje, ik zie hier ook totaal niet de nieuws waarde van in...

Wellicht dat Dimitri een zware zaterdag avond heeft gehad en nog niet helemaal bij is ;-)

Als je even denkt aan blade servers waarin je 2 zes-koppige monsters insteekt met 192GB RAM kan je heftige Vmware oplossingen maken :-)

Multicore is dus niet per se vooral nuttig voor desktops maar evenzeer voor servertoepassingen. Vmware is niet het enige zo maar ook middle ware toepassingen zoals bvb Biztalk servers, ... .

ESX van VMWare maakt tegenwoordig optimaal gebruik van alle kernen. Hij kan zelfs selectief beslissen VMs te migreren van één ESX naar een andere om het CPU gebruik tot in de puntjes te optimaliseren...

Een singlecore die niks zit te doen is even nuttig als een multicore die niks zit te doen.

De tijd dat één OS en één applicatie op één fysieke machine draaiden ligt achter ons.

De tijd dat één OS en één applicatie op één fysieke machine draaiden ligt achter ons.
Ware het niet dat het grootste deel van alle PC's één OS op één fysieke machine draaien. Dat blijft nog jaren zo.

Lost van de discussie wel of niet virtualizeren (ik ben er nog steeds van overtuigd dat er situaties zijn waarin je (nog) niet wil virtualizeren) heeft het gebruik van virtualisatie toch geen verbetering tot gevolg als we kijken naar applicaties waarin berekeningen worden gedaan die niet multithreaded te maken zijn. Ook bij een goed multicore geoptimaliseerde virtual machine zal dit niet veranderen.

De kern van de zaak is volgens mij dat bijv een dualcore niet gelijk staat aan 2x single core op de zelfde snelheid en architectuur. Waarbij 2x single core natuurlijk ook niet helpt bij dit soort operaties, maar je kunt wel zeggen dat je een single core cpu met een single thread efficienter zou kunnen maken dan een single thread op een single core van een multicore cpu.

In de praktijk heb ik die voorbeelden soms gezien bij bepaalde applicaties gedraaid op een oude P4 3Ghz tegenover een Core 2 Duo 2.2 Ghz. Waarbij de verschillen te groot waren om toe te schrijven aan andere factoren. Ik heb wel het gevoel dat de markt waarin dit van belang zou kunnen zijn erg klein is, mogelijk zelfs alleen maar bij wiskundigen e.d. the R project misschien?

Weet er iemand nog voorbeelden? (voorbeelden van multicore optimized apps die bepaalde operaties beter doen in single core omgeving?)

[Reactie gewijzigd door cibrhusk op maandag 20 september 2010 14:04]


Programma's als autocad zijn ook single core.

Een goede ontwikkeling in multicore zou zijn één snellere core te maken met daarbij een aantal support cores.

Wat een nutteloos artikel is dit nu zeg :s
Je kan evengoed zeggen: Een Bugatti Veyron is niet altijd de beste oplossing om om boodschappen te gaan. DUH!
Het hangt allemaal af van de toepassing. Een multicore cpu is sowieso de toekomst. Programma's worden meer een meer multithreaded geschreven en volgens mij zullen er nog maar weinig programma's zijn die maar 1 thread hebben in de toekomst.

Ons bedrijf levert zelf 1U servers aan een grote bekende Internetsite waarin 4 netbook moederbordjes zitten met atom procesorren. Klaarblijkelijk is dat de meest efficiente oplossing voor die klant.

Ik denk dat dit meer een roep is naar de processorfabrikanten toe om vooral door te gaan met single-core ontwikkeling en -productie. Single-core CPU's sterven namelijk uit, maar Google heeft die blijkbaar hard nodig voor zijn toepassingen.

[Reactie gewijzigd door Fireshade op maandag 20 september 2010 10:05]


[off-topic]
Een Bugatti Veyron lijkt mij altijd de beste oplossing om om boodschappen te gaan doen. Als dat niet zo is geloof ik dat pas nadat ik dat intensief zelf getest heb... ;)
[/off-topic]

Verbruik, opbergplaats...Net hetzelfde zoals een dual core ook overkill is voor sommige toepassingen.

Kom em maar halen ;)
Je mag em best een weekje lenen.

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 zondag 19 september 2010 13:43]


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.

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

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 ;)

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?

Heb je het koud op je werkkamer?

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.

dus waar het op neerkomt is dus overclocken xD

dus waar het op neerkomt is dus overclocken xD
Nee, niet per se overclocken. Gewoon de CPU's zo ontwikkelen, dat de multicore varianten net zo snel (in GHz, MHz, whatever) zijn als hun singlecore broertjes en zusjes.

@Robo400, thanks!

[Reactie gewijzigd door CptChaos op zondag 19 september 2010 18:05]


Nee, niet per se overclocken. Gewoon de CPU's zo ontwikkelen, dat de multicore varianten net zo snel (in GHz, MHz, whatever) zijn als hun singlecore broertjes en zusjes.
Fixed

amai dat wisten we echt nog niet :D

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)

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).

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

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.


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.

Niet noodzakelijk.

Als je veel single threaded applicaties naast elkaar draait kan je OS (enigszins recent OS dan... DOS wordt lastig :P) 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).

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 zondag 19 september 2010 14:45]


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.

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.

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.

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. :)

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.


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

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...

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.

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.

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

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. :P

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?

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

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

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.

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.

È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.

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 zondag 19 september 2010 19:54]


(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.

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.

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.

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 zondag 19 september 2010 14:54]


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.

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 zondag 19 september 2010 19:29]


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! :+

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?

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.)

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.

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.

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... ;)

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

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.

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.

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

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

out of order excution, branch prediction.. en zo

@odish: volgens mij is dit gewoon het concept van de turbomodus bij intel/amd: een wordt hoger geclockt dan de andere cores wanneer het nodig is;).

Het staat gewoon nog in de kinder schoenen. Projecten zoals OpenCL zullen hierin wel kunnen helpen.

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

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

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.

:)

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

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.

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.

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

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.

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 zondag 19 september 2010 15:05]


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.

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?
«  1  2  3  4  5  »

Op dit item kan niet meer gereageerd worden.

Volgende 14:58 Boeing wil zonnevliegtuig 5 jaar in de lucht houden
Vorige 13:18 Relic schrapt Games for Windows Live uit Dawn of War II-uitbreiding
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011