'Software maakt onvoldoende gebruik van multicore-cpu'

De hardwarewereld heeft de cpu met twee of meer cores ontdekt, observeert InfoWorld; alle fabrikanten hebben tegenwoordig multicorechips in hun assortiment. De software-industrie heeft echter flink wat moeite om zich aan de veranderende omgeving aan te passen, zei Herb Sutter, softwarearchitect van Microsoft, op het Fall Processor Forum in Californië. Omdat multithreading al een paar jaar tot de mainstream-technologie op de servermarkt behoort, maken serverapplicaties ondertussen redelijk goed gebruik van het vermogen een aantal taken parallel uit te voeren. Servertaken laten zich vaak ook makkelijker tot concurrency verleiden: een webserver die twee bezoekers tegelijk bedient, kan die twee taken zonder problemen tegelijk afhandelen.

Voor clientside toepassingen is er echter nog niet veel meer gedaan dan de meest rendabele tweaks. De meeste software voor end users wordt nog steeds sequentieel verwerkt: één instructie tegelijk. Hoewel processorbouwers daarop inspeelden met technieken als branch prediction - waarbij de cpu in zijn 'vrije tijd' alvast een aantal verschillende uitkomsten uitrekent, en daaruit kiest als duidelijk is wat de precieze input voor een stuk code wordt, moeten softwarebouwers beter rekening met de multithreaded cpu's gaan houden. Net als object-geörienteerd programmeren vergt het maken van multithreaded software een nieuwe benadering van de softwareontwikkeling, waarbij in dit geval steeds in het achterhoofd moet worden gehouden dat een applicatie in een aantal kleine stukjes moet kunnen worden verdeeld. Alleen dan kan software optimaal van de nieuwe hardwaretechnologie gebruik maken.

Deze nieuwe benadering vraagt veel, wellicht zelfs te veel, van de ontwikkelaars. De multicore-technologie zal weinig nut hebben als de hardwaremakers daarom niet beter op de programmeerbaarheid van hun systemen gaan letten, zei Sutter: 'Snelheid komt pas op de tweede plaats; chipfabrikanten moeten vooral niet aannemen dat de ontwerpers van besturingssytemen en software wel raad met dergelijke problemen weten.' Microsoft werkt onder zijn leiding aan het Concur-project, dat programmeurs helpt om eenvoudiger parallellisme in software te bouwen, maar een dergelijke inspanning heeft wel hulp van de hardwarebouwers nodig. Nu de kloksnelheden van processors zo'n beetje tegen het plafond zitten, zou verdere snelheidswinst van computers in de praktijk wel eens kunnen afhangen van hoe succesvol de samenwerking tussen hardware- en softwaremakers wordt.

large > many-progressieplaatje" alt="Athlon small > large > many-progressieplaatje">

Reacties (72)

[Anoniem: 98889]

Is toch niets nieuw ? Er is al jaren geen software meer die echt optimaal gebruik maakt van de beschikbare hardware.

Games komen nog een beetje in de buurt, maar bij office toestanden is het gewoon huilen met de pet op. Bloated unoptimized software die vaak op ultrasnelle hardware amper vooruit te branden is...

[Anoniem: 61096]

Games komen absoluut niet in de buurt.
Games moeten allereerst op allerlei verschillende hardware werken en daarnaast zijn games allesbehalve geoptimaliseerd voor zaken als Hyperthreading, multicore, SSE enz enz. Nee, juist games zijn de meest lomp geprogrammeerde stukken software die er bestaan.

[MAX3400]

Het nut van multi-cores bewijst zich wel degelijk ondanks dat huidige software niet altijd geschreven is daarvoor. Onder Windows (sinds NT, maar meer vanaf 2000) kan je processen aan cores toewijzen en daarmee de andere cores ontlasten. Verder zijn er wel al een aantal applicaties, voornamelijk CAD/CAM en video-editing, die wel degelijk gebruik maken van multi-cores en daar relatief gezien ook veel beter mee presteren t.o.v. single-cores.

Wat men wel even over het hoofd ziet (zie ook recentelijk de nieuwe lijsten van AMD), is dat je met een dualcore CPU met bijvoorbeeld 2x 2GHz veel meer rekenkracht hebt dan 1x 4GHz. Zo draai ikzelf bijvoorbeeld VMWare op mijn 2e core, de processen voor FireFox, Outlook en dergelijke draaien ook op core2 en daardoor heb ik ongeveer 95% van mijn eerste core beschikbaar voor makkelijk & snel een game spelen.

[n4m3l355]

echter dual cores zijn sterk teruggeklokt tov single core. met andere woorden als een process die je eerst op een 3.6ghz zou draaien amd of een 3600+ amd en die stop je nu in een 3600x2 of welke Intel variant die daaraan gelijk is zal er onder de meeste omstandigheden verlies optreden. die single thread die essentieel is naast de standaard threads gaat er dus op teruguit. met andere woorden deze schrijver heeft zeker gelijk in de zin van als jij specifiek 1 soort software gebruikt naast de rest. inderdaad wanneer jij en browsed, en photoshoppped en dan nog wat text zit te editen dan zul je met de dual core winst boeken maar de meeste mensen zijn in tegenstelling tot hun software niet multi-tasking

[TheCapK]

Maar als je dus zelf de instellingen aanpast kan je wel optimaal gebruik maken een dual core CPU. Dit lijkt mij namelijk de oplossing voor een "onbruikbare" PC die een paar uur staat te rekenen voor 1 DVD project dat ik wil wegbranden in Pinnacle Studio!
Als ik dat namelijk doe reageert de rest van de PC niet meer door de hoge core belasting en hier zou een 2e core er mooi voor kunnen zorgen dat ik mooi door kan gaan met andere dingen ipv dit soort taken voor 's nachts te bewaren!

[RedLizard]

@HighwayDevil: 2 CPUs van 2 GHz per stuk zijn zeker niet sneller dan 1 van 4 GHz. Als je applicaties er - hypothetisch - perfect op gebouwd zijn, en je hebt - ook in je OS - nul overhead, dan kan je evenveel rekenkracht halen als bij single CPU, maar meer zit er echt niet in.

@k1n8fisher:

Als ik dat namelijk doe reageert de rest van de PC niet meer door de hoge core belasting

Daar hebben ze prioriteitenlevels en CPU quanta voor. Zet Pinnacle maar eens op prioriteit 0, dan zal dat best meevallen.

[Anoniem: 93545]

echter dual cores zijn sterk teruggeklokt tov single core.

Ja toch wel zeker 200Mhz...

[Anoniem: 399]

Vind je zelf wel dat je clientside software noemt als je met VMWare aan het spelen bent? Men doelt hier op de modale JBL thuis, die de snelheid van een extra core in Doom, FEAR en Outlook Express dus totally niet ziet.
En dat je kan multitasken is ook al geen goeie, want dat doen thuisgebruikers ook al zelden.

Dat jij thuis op je werkstation server software draait is natuurlijk een mooie reden om een multicore CPU te nemen maar dan heb je wellicht ook al een hele tijd dual opteron of xeon systemen gebruikt. Check het verbazingwekkend lage aantal multi-cpu setups bij modale mensen thuis.

[SuperDre]

Ze kunnen het beter wat algemener zeggen: 'De huidige software maakt gewoon helemaal geen nuttig gebruik meer van de processor'...

alles wordt steeds 'lomper' geprogrammeerd, waardoor je steeds een snellere pc nodig hebt om hetzelfde resultaat te behalen..

[Anoniem: 30917]

alles wordt steeds 'lomper' geprogrammeerd, waardoor je steeds een snellere pc nodig hebt om hetzelfde resultaat te behalen..

Dat heeft niets met multithreaded programmeren te maken. Integendeel, de broncode wordt alleen maar gecompliceerder, onoverzichtelijker en vaak lelijker (lees: meer moeilijk te vinden bugs) in een geforceerde multithread oplossing. Enkel om een beetje snelheidswinst te pakken, vaak dus alleen maar de moeite waard bij servertaken of ingewikkelde berekeningen.

Net als object-geörienteerd programmeren vergt het maken van multithreaded software een nieuwe benadering van de softwareontwikkeling

Deze vergelijking uit het artikel gaat niet op. Object georienteerd leidde tot nettere en overzichtelijkere, maar meestal langzamere code, multithreading tot ingewikkeldere maar snellere. Exact ook de doelen die OOP en multihreading natreven.

[wimmi]

Object georienteerd leidde tot nettere en overzichtelijkere, maar meestal langzamere code

Denk dan ook even aan de ondersteuning van multicore door de beschikbare compilers of erger: de bytecode interpreters van VB, Java of C#.

Het vak van CPU's programmeren (echt iets uit de jaren '80) en de kunst van grootschalige software programmeren is zover uit elkaar gegroeid dat goed doordachte programma-archtectuur moeilijk te realiseren is.

Waarom maakt Intel niet eens een Java-CPU? Iets wat de bytecode direct door de CPU laat verwerken?

[Anoniem: 19339]

Het vak van CPU's programmeren (echt iets uit de jaren '80) en de kunst van grootschalige software programmeren is zover uit elkaar gegroeid dat goed doordachte programma-archtectuur moeilijk te realiseren is.

Je doet alsof dat iets slechts is. Inderdaad, programmeurs van nu zitten geen assembler in te kloppen, maar dat kan in deze tijd van grafische interfaces en windows en widgets ook niet meer. Je gaat niet steeds opnieuw het wiel uitvinden, je bouwt op bestaande blokken.

Een architect (van gebouwen) tekent ook hele muren tegelijk, en niet elk steentje apart opnieuw. Als je een pc bouwt, koop je ook losse functionele blokken (psu, moederbord, cpu, harddisk) in plaats van losse ic'tjes en weerstandjes en een soldeerbout.

Noem het de vooruitgang...

[jj71]

Waarom maakt Intel niet eens een Java-CPU? Iets wat de bytecode direct door de CPU laat verwerken?

Sun maakt de picoJava Core, een microprocessor core die Java bytecode als native instructieset heeft, maar voor zover ik weet is er geen toepassing voor PC's of servers die hiervan gebruik maakt.

[mjtdevries]

Wat bedoel je met je opmerking over de ondersteuning van multicore door de beschikbare compilers of bytecode interpreters?

Java heeft namelijk uitstekende multithreading support, dus daar zit het probleem niet.

[Skinkie]

Grotere bedrijven willen makkelijker te maken code. Java perfect te onderhouden

SuperDre heeft gelijk, SSE, MMX, etc. worden allemaal niet ten volle gebruikt.

[TinusH777]

Dat is niet waar!
Relevante software wordt wel gebruik gemaakt van multi-threading en multi-processing:
- Alle databases
- Alle web servers (en dus web applicaties)
- veel business applicaties (n-tier model)
Het converteren van filmpjes en spelen van spelletjes wordt hier bij Tweakers een beetje onder een vergrootglas gelegd, maar is in mijn ogen minder relevant.
Daarnaast is voor 99% van de desktop-gebruikers de langzaamste singlecore Celeron al ruim snel genoeg.
Tenslotte: de die-hard gamer kan beter 100euro extra uitgeven aan een snellere GFX-kaart dan aan een extra core.

[Anoniem: 87832]

Denk jij dat ASM nog realistisch is in een wereld waarin:

A. Complexiteit van de x86 architectuur zo groot is geworden dat er slechts weinigen meer zijn die grote stukken ASM kunnen schrijven die efficiënt werken.

B. Er sowieso enorme lappen ASM nodig zouden zijn om zelfs de meest triviale dingen te doen. In dat soort code bugs vinden is een crime, en een algorithme aanpassen betekent opnieuw beginnen.

C. Compilers tegenwoordig dusdanig goed optimaliseren dat er slechts weinig programmeurs zijn die béter ASM kunnen schrijven.

Dit tesamen maakt het eigenlijk vrij zinloos om nog direct op de CPU te programmeren tenzij je tijd te veel hebt.

[sirdupre]

Wat stel je dan voor? Alle spellen maar weer in Assembly gaan maken?
Het is gewoon een logische afweging tussen wat developers en wat hardware kost.

[mjtdevries]

Jaaa, da's een goed idee.

Laten we Quake5 in assembly maken. Dan weten we tenminste absoluut zeker dat het lompe code wordt, waar een developer veel langer mee bezig is en die veel langzamer is dan als je het gewoon in C maakt!

[mieJas]

Ligt dat niet gewoon aan de x86 architectuur? Die is ondertussen ook al opa geworden...

[Luxx]

En als je dan bedenkt dat dit nog 2 identieke cores zijn die 'alle soorten' instructies kunnen behandelen... Als het hier al zo enorm lastig is, en lang duurt, kan je nagaan hoe lang het nog gaat duren voor een CELL-achtige volledig benut wordt. Geen wonder ook dat de PS3 niet al te populair is onder softwaremakers.

Intel wil ook naar zo'n soort architectuur toe, dus dat zal in de toekomst nog veel meer problemen zorgen. Hopelijk komen ze nog met veel ontwikkel-tools, of brengt Intels eigen compiler weer eens een snelle oplossing.

[koelpasta]

Cell is weer een apparte architectuur.,
Anders als bij de 360 zitten er in de Cell een soort co-processors.
Deze staan over het algemeen onder leiding van de hoofdprocessor.

Die hoofdprocessor geeft 'paketjes' van te berekenen data door naar de lokale geheugens van de SPU's (de subprocessortjes).
Deze draaien hun eigen programma code maar die is veel eenvoudiger omdat zo'n SPU zich vooral met zichzelf bezighoudt.
Deze code draait ook vanaf dat locale geheugen en is dus paralel aan de hoofdprocessor.
Dit betekent weer dat ze elkaar niet in de haren zitten, dus minder overhead.

Je bouwt in feite kleine OO progjes (code + data) die je uit gaat delen aan de SPUs

Die gaan gewoon lekker hun gang op de data en als ze klaar zijn dan schrijven ze de data weer terug.

Door deze manier van werken heb je veel minder last van synchroniciteitsproblemen dan met 3 all-purpose cores zoals op de 360.
Daar moet je namelijk elke core veel zinniger gebruiken door inderdaad bijvoorbeeld op de ene een client thread en de andere een server thread en de derde een gfx-engine thread te laten draaien.
Dit houdt in dat er 3 grote threads tegelijk draaien en dat die dus aan elkaar moeten syncen.
Zo'n grote thread heeft namelijk heel veel interne afhankelijkheden en kan niet makkelijk anticiperen op wat er op de andere cores gebeurt.

Bij de cell heb je een hogere 'resolutie' van cpu's met slechts 1 cpu die de hoofdthread draait.
Die enkele thread bepaalt wat en wanneer er dingen naar de SPU's gestuurd worden.
Die SPUs zijn een soort onafhankelijke slaafjes die opzich veel kunnen (volwaardige cpu's) maar vooral als number-crunchers zullen worden ingezet.
Omdat het meerdere (kleinere) cores zijn, zijn ze efficienter te schedulen door de hoofdthread.
Ze draaien dus niet non-stop een apparte hoofd-thread, ze zijn juist gemaakt voor het bulk-verwerken van data voor de hoofdthread op de main core.
Die is de baas en daarmee ben je van een groot deel van je sync problemen af.

De cell is dus een erg cool 'systeempje'

[Johnny]

Een bestaande applicatie multithreaded maken is ook niet echt makkelijk, dan kan je in de meeste gevallen het beste helemaal opnieuw beginnen, en daarnaaast is het ook nog een stuk ingewikkelder omdat er dan van alles gesynchromiseerd moet worden, en biedt het voor de meeste desktop-applicaties niet echt veel snelheidswinst.

[Bobco]

Voor sommige applicaties is herschrijven misschien ook wel het beste. Zelf heb ik nog dagelijks de twijfelachtige eer om te mogen werken met Outlook2000. Deze mail client is niet in staat om tegelijkertijd mail op te halen en de gebruiker een nieuwe mailtje te laten maken.

Nu is dit niet zo'n heel nieuw stuk software, maar multi-threading is nu niet iets wat opeens in de afgelopen 2 jaar is uitgevonden. Ik begrijp de opmerkingen van Sutter dan ook niet zo goed, maar ik ben ook geen OS guru.

Het lijkt me dat een OS een runnable thread toch aan een willekeurige 'vrije' core moet kunnen toewijzen en aan het werk zetten. Op dit manier hoef je je applicatie alleen maar netjes multi-threaded te maken en het OS zorgt vervolgens voor de optimale benutting van je hardware.

Heeft iemand wat meer info over hoe de verschillende OS'en omgaan metCPU affinity van processen?

[mjtdevries]

Ik denk dat die Sutter bedoeld dat programmeurs toch echt zelf bezig moeten gaan met multithreaded programmeren, en niet kunnen verwachten dat compilers dat automatisch voor hen gaan oplossen. (zoals sommigen lijken te denken)

Wat betreft het OS is het in wezen heel simpel.

Inderdaad kan het OS een thread aan een willekeurige vrije core/cpu toewijzen. Als je applicatie maar netjes multithreaded is dan werkt dat allemaal perfect.

Wat betreft affinity. Je ziet vaak dat die threads regelmatig van de ene core/cpu op de andere overgaan, maar i.t.t. wat veel mensen denken geeft dat geen performance issues. Daar hoef je je echt niet druk om te maken. (en programmeurs ook niet)
Zowiezo is dat al veel minder het geval als beide cores/cpu het al druk hebben.

En multithreading ook al nuttig is bij 1 core/cpu, omdat het dan ook de cpu efficienter benut, dus het is al jaren hoog tijd dat programmeurs multithreaded gaan werken.

[edit:] Het orginele artikel nog eens gelezen en volgens mij weet Sutter zelf niet wat ie bedoeld.
Aan de ene kant beseft ie dat de programmeurs van hun luie gat af komen en geen "free lunch" meer krijgen. Aan de andere kant roept ie hardware fabrikanten op, om die programmeurs toch hun "free lunch" geven.

[D-Three]

Hieruit begrijp ik dus dat een multicore CPU voorlopig nog weggegooid geld is.

[Anoniem: 112808]

Niet helemaal. Wanneer je namelijk meerdere applicaties draait, worden de taken volgens mij WEL verdeeld over de cores. Zo kun je dus rustig gamen terwijl er geleeched wordt

Waar het hier om draait is dat de applicaties zelf nog niet met meerdere cores werken.

[D-Three]

Doet Windows 2K/XP dit automatisch? Of moet je zelf de taken toewijzen aan een core?
Zelfs al gebeurt de toewijzing automatisch, dan nog is dit niet voor iedere gebruiker interessant. Niet iedereen draait meerdere CPU-intensieve taken tegelijkertijd. Veel gamers doen enkel maar aan gamen en tegelijkertijd niks anders. Dan is zo'n multicore cpu voorlopig niet interessant. Dan betaald hij beter wat meer voor een snellere videokaart
Voor bepaalde ontwikkelaars, kan het misschien wel interessanter zijn. Op mijn stageplaats (enkele jaren geleden) had iedereen twee PC's. Terwijl de ene druk bezig was met compileren, kon men verder werken met de andere. En omgekeerd. Met een multicore CPU zou dat ook met 1 PC kunnen.

[_Pussycat_]

Ja, dat doet je OS zelfstandig.

[mr._Anderson]

Windows XP doet dit automatisch. (2000 vanaf SP x ?)

Zoals uit alle reviews en testen naar voren komt is het voor gamers ook niet interessant.

Maar er zijn heel veel toepassingen te vinden waarbij het wel interessant kan zijn.

Ik denk bijv. aan designers welke photoshop open hebben staan en andere programma's, 3D design..
zoals jij al aangaf: compileren en programmeren tegelijk.

Wanneer je ook maar twee of meerdere zware programma's naast elkaar draaid krijg je enorm veel winst. Wanneer je alleen maar spellen draaid, dan houd het op. Wanneer je dan weer een server direct meedraaid kan het weer wel handig zijn

[mjtdevries]

Wat nou 2000 vanaf SPx???

ELKE NT versie (incl 2000) heeft dat altijd al automatisch gedaan.
ELK OS dat met meerdere cpu's om kan gaan doet dat automatisch!

[bjorntje424]

Zo kun je dus rustig gamen terwijl er geleeched wordt

Welke p2p gebruik je dan wel niet wat zoveel cpu kracht gebruikt?

[jiriw]

Ach ... als je je data met een paar kbyte per seconde binnenkrijgt zal ik me niet zo druk maken nee. Echter als het een paar megabyte per seconde is... Neem bijvoorbeeld bittorrent. Je bittorrentclient moet veel verschillende kleine stukjes data in hoog tempo naar je hardeschijf wegschrijven en er van ophalen, hij moet een x aantal verschillende cachesystemen bijhouden en checksums controleren, 100+ TCP connecties openhouden (als je flink wat seeds/leeches hebt). Als ik mijn lijn 'dichttrek' (10mbit, half-duplex) met een paar torrents en met zo ong. 300 andere computers een verbinding onderhoud (hoe gefragmenteerder hoe zwaarder) dan begint mijn AthlonXP 2400+ aardig te zweten hoor... CPU usages van gemiddeld 50% zijn echt geen uitzondering. En dan wordt het grootste deel van mijn HDD werk nog door de SCSI controller gedaan. Als ik naar een van mijn USB schijven wegschrijf wil je helemaal niet weten wat mijn CPU belasting is....

[Depress]

Nee, je gebruikt hem nu niet, maar als je een pc met multi core koopt dan koop je een pc die wel wat meer als 3 jaar mee kan. Tegen die tijd zullen toch wel al wat applicaties zijn die gebruik maken van deze techniek.

[Anoniem: 64607]

PCs die langer als 3 jaar meegaan bestaan niet

[Anoniem: 87442]

Ooit van een Mac gehoord?

[D-Three]

Tegen die tijd

Dus voorlopig weggegooid geld want "tegen die tijd" zullen die CPU's ook wel goedkoper zijn

[ThunderNet]

Tuurlijk niet... je draait namelijk meer dan 1 proces tegelijk ?

As we speak draai ik 42 processen en 522 Threads. Waarvan een groot deel gewoon processortijd wil

[SG]

Naast SMP kan je ook Multitasken daar heb je geen SMP support voor nodig

Maar ja de software migratie gaat volgens de hardware tak gewoon te langzaam. Maar wel zoals verwacht vind ik.

Je hebt dus 'n applicatie pobleem en daar voor kom je met 'n software oplossing. Normaal ging dat met één thread. Voor de desktop markt. Nu Moet je het probleem eerst analiseren voor opdeling in stukken die goed parralel en in afzonderlijke threads te doen zijn en dan dus voldoende parraleliserings winst opleveren.

Simpel voor beeld. je splitst de Game engine in 'n Server side en 'n client side module en elk met hun eigen tread. Ook voor 'n Single player game.
De meeste games hebben kwa OOP design al zo'n opdeling. dus de volgende stap is dus Die modules in een apparte thread te zetten. Maar hier bij kom met thread synchonisate en Save multithreading toch mee rbij kijken dan 'n create_thread() ergen in poten.

Dit kan verder doorgevoerd worden door nog mee rmodules in een eigen thread te zetten.
Het delen is niet het grootste probleem. Maar de thread shynchronisatie en thread save coden en interfacen is een must en veel meer werk dan gedacht.

Tja en nu is nog Single thread design de routine is. Is het in het begin dus pioneers werk. En de afweging of de rendement ervan het waard is voor die extra inspanning van dev resources maakt dus elk game engine team dus uit.

Dingen die performance hongerig zijn makkelijk te splitsen relatief eenvoudig tread save te maken door minimale afhankelijk heden die worden al snel SMP enable. Zoals video encoders. Games o.a lijkt mij 'n ander verhaal.

Aangezien de next gen console multi core platformen zijn kan het niet anders. Ze moeten 'n keer die stap toch doen ivm concurentie. Voor alle andere apps buiten games geld het zelfde. De deelbaarheid en de afhankelijk heden van die modules. bepalen de complexiteit en of het de moeite wel waard is naar SMP te stappen.

[pinockio]

Dual core is absoluut geen weggegooid geld. Voor ca. 100-200 euro meer heb je een veel soepeler werkend systeem en bij ondersteunde software (bijv. Pinnacle Studio) ook een bijna 2x zo grote snelheid.

Waarom is je systeem soepeler? Omdat je ene core je hoofdproces kan afhandelen, en de andere alle bijprocessen (zoals: Windows services, virusscanners, firewalls, P2P programma's, etc., etc.)

Ik heb hier op mijn pc ca. 50 processen tegelijk draaien...

Juist het switchen tussen processen zorgt voor veel vertraging (let maar eens op hoe traag je programma's worden op het moment dat je een nieuw programma erbij opent).

[Anoniem: 75364]

Onder Linux kan je heel makkelijk gebruik maken van multicore processoren. Als je bijvoorbeeld een AVI filmpje op DVD wil zetten knoop je gewoon een AVI decoder programma, video filter programma's en een MPEG2 encoder aan elkaar via UNIX pipes:

<decoder> | <filter1> | <filter2> | ... | <encoder>

Al deze programma's worden parallel uitgevoerd en automatisch over alle processoren en cores verdeeld, hoef je niks voor te doen. Je kan ze zelfs via een netwerk over meerdere computers laten verdelen, maar dat is ietsje ingewikkelder.

Verder zijn multicores natuurlijk erg leuk als je met meerdere mensen regelijk op 1 Linux machine werkt in een server / thin client configuratie.

[Anoniem: 19339]

'Snelheid komt pas op de tweede plaats; chipfabrikanten moeten vooral niet aannemen dat de ontwerpers van besturingssytemen en software wel raad met dergelijke problemen weten.'

En dáárom moet ik nog afwachten wat het resultaat gaat worden van de Cell-technologie. Ik geloof best dat, mits goed geprogrammeerd, software ongekende performance kan halen. Maar voordat er software gemaakt wordt die het maximale eruit haalt...

Volgens mij was het net zo met RISC-technologie. Minder instructies mogelijk, maar wat RISC wél snapt, gaat bloedsnel. Maar uiteindelijk won CISC het toch (althans, in de pc-wereld) vanwege de flexibiliteit (en dus gemak) van het programmeren ervan.

En nu hetzelfde... Een nieuwe techniek, maar daar heb je pas wat aan als we het allemaal doen. Alleen is de stap van single core naar multicore iets kleiner dan naar een compleet andere architectuur.

[Anoniem: 87832]

Nóg maar een zowat identieke reactie...

Als CISC beter is dan RISC, waarom is dan bijna élke moderne CPU RISC m.u.v. een CPU die met handen en voeten gebonden is aan een een instructieset uit het tijdperk van de allereerste IBM-PC?

Zoals ook al elders; de enige mensen die tegenwoordig nog direct op de CPU programmeren zijn óf mensen die compilers schrijven óf hobbyisten voor wie het resultaat niet telt.

[RetepV]

De CISC en RISC discussie is al lang dood en begraven. Kom op zeg. RISC was bedacht omdat het niet mogelijk was om alle functionaliteit van een CISC processor hardwarematig uit te voeren EN op één chip te krijgen. Dus zijn ze nog eens goed na gaan denken over de instructieset en het programmeermodel.

Met als resultaat dus de RISC processor die elk van zijn instructies in één clockcycle kon uitvoeren en die ook nog eens in een chip paste.

Maar transistortjes in IC's zijn een stuk kleiner geworden en het productieproces een stuk betrouwbaarder. En dus werd het lonend om een 'RISC' processor te maken met een 'CISC' instructieset. Dus een processor met een CISC instructieset waarvan alle instructies in één clockcylce uitgevoerd kunnen worden.

RISC = Reduced Instruction Set Computer. Die instructieset was alleen maar 'reduced' omdat dan alles in hardware uitgevoerd kon worden EN toch op één chip zou passen.

CISC = Complex Instruction Set Computer. Een complexe instructieset.

Voer je alle instructies in hardware uit en zorg je er voor dat ze allemaal in één clockcycle uitgevoerd kunnen worden, dan heb je dus een CISC processor met de karakteristieken van een RISC processor.

Het is gewoon evolutie. RISC en CISC waren vroeger onverenigbaar door de techniek, maar tegenwoordig niet meer. De termen betekenen tegenwoordig niks meer.

[koelpasta]

Volgens mij zijn de 2 concepten niet zo makkelijk verenigbaar als je zegt.
Je werkt altijd tegen een grens aan.
Als je een CISC cpu zou maken die alles in 1 klok doet dan moet je een compromis sluiten en het ding behoorlijk lager gaan klokken.
Dit omdat een CISC cpu een veel uitgebreidere instructie decoder heeft (daarom is het namelijk ook een CISC). en deze heeft per definitie meerdere kloks nodig alleen al om te vertalen naar microcode.
Dat houdt weer in dat de cpu intern op een hogere kloksnelheid moet hangen om zn instructies binnen 1 'buiten'-klok uit te voeren.
dat betekent dat de aangeboden klok gelimiteerd wordt door zn interne snelheid.
m.a.w. je kunt het niet zo snel klokken als een normale RISK en daar gaat je voordeel.

Andersom is het ook zo dat een RISK cpu minder instructies heeft en de kans is groot dat wat je wilt doen alleen kan als je meerdere instructies achter elkaar gebruikt (en dus meerdere kloks verbruikt).

Een andere reden waarom de 2 concepten moeite met elkaar hebben is de diepe pipelines van een CISC processor.
Een moderne x86 cpu heeft weldegelijk RISK functionaliteiten. SSE en MMX heet dat.
Maar daarvoor moeten wel de pipelines die met het CISC gedeelte bezig zijn ff 'geflushed' worden.
Vervolgens, nadat je klaar bent met je RISK berekeningen, moet je die CISK pipeline(s) opnieuw gaan vullen en het duurt dan vele kloks voordat er weer us wat uit komt.

En dan kom ik weer terug op de Cell cpu.
die heeft namelijk een vrij CISCerige hoofdcore met daaromheen RISKerige subcpu's met een eigen geheugen en die allemaal hun eigen code kunnen draaien.
Dus een beetje van beide voordelen meepikken.
CISK voor de besturing en RISK voor de bruute krach en om die-space te besparen.

[zytec]

Volgens mij was het net zo met RISC-technologie. Minder instructies mogelijk, maar wat RISC wél snapt, gaat bloedsnel. Maar uiteindelijk won CISC het toch (althans, in de pc-wereld) vanwege de flexibiliteit (en dus gemak) van het programmeren ervan.

Pfff, die x86 processoren vertalen allemaal de CISC instructies waar naar RISC, voordat ze uitgevoerd worden. Dat vreet natuurlijk extra energie (dissipatie) die uitbepaard kan blijven. Maar vanwege de flexibiliteit (lees backwards compatibiliteit) lijkt het voor de programmeur een CISC machine. En meestal ook weer niet, want veel applicatie's worden niet meer in assembly gemaakt maar in andere (hogere) talen.

Vraag mij eigenlijk wel af hoe snel zo'n beestje is als de tool-chain RISC code voor de x86 core aflevert.

[voodooless]

Volgens mij was het net zo met RISC-technologie. Minder instructies mogelijk, maar wat RISC wél snapt, gaat bloedsnel. Maar uiteindelijk won CISC het toch (althans, in de pc-wereld) vanwege de flexibiliteit (en dus gemak) van het programmeren ervan.

CISC heeft gewonnen vanweggen de killerapps van toendertijd, niet omdat het zoveel handiger werken is. Sowiso progt vrijwel niemand meer assmbler, dus de instructieset is vrijwel lost te koppelen van de flexibiliteit van de programmeur. Zie maar hoe betrekkelijk eenvoudig apple nu kan overstappen op intel: een recompile, beetje hacken, wat drivers, en klaar

lol: twee keer vrijwel de zelfde reactie

Vraag mij eigenlijk wel af hoe snel zo'n beestje is als de tool-chain RISC code voor de x86 core aflevert.

Dat snapt de x86 dan niet, aangezien de "RISC" (het is ook niet echt risc) code op een heel ander level werkt. Daarnaast is het niks sneller, omdat de x86 dat on-the-fly omzet. kost alleen meer transistoren en warmte

[Anoniem: 53628]

Een divxje coderen en tegelijkertijd in office spelen? Single core werkt dit niet echt lekker maar dual core zou dit prima gaan. Het is dus nog niet eens de software bouwer maar ook de persoon die de pc gebruikt.

Iemand die alleen een browser heeft lopen, die heeft niet veel aan een dual core. Ik begrijp dat de hardware fabrikanten graag willen doen alsof iedereen een dual core moet aanschaffen maar een nuchter persoon weet wel beter. Die kijkt naar zijn eigen wensen.

[bramseltje]

Puur theoretisch: Juist een browser kan baat hebben bij multithreading. Wanneer voor elke request van een server een aparte thread gestart zou worden (dus voor plaatjes, iframes e.d.) kun je met een dual(core) processor opstelling mogelijk nog best wel wat winst behalen. Zeker aangezien je internetverbinding meestal nog meer dan genoeg ruimte over heeft voor het binnenhalen van wat extra content.

Natuurlijk moet ook de renderer hiervoor geschikt zijn, en moeten er eventueel wat aanpassingen aan de website gebeuren, maar ik zie zeker mogelijkheden...

edit:

Goed, nu terug naar de praktijk:
Zoals hieronder al aangegeven wordt, is een browser inderdaad niet de meest ideale kanditaat voor een multicoreupdate. De huidige hardware is meer dan snel genoeg om de data binnen afzienbare tijd zowel binnen te halen als op het scherm te toveren. Het zijn vaak vooral andere factoren die van invloed zijn op de prestaties. (Grote, onnodige flash menu's, reclames e.d..)

Om kort te gaan: Weer een voorbeeldje waarin de informaticatheorie ingehaald wordt door de praktijk...

[Olaf van der Spek]

Wanneer voor elke request van een server een aparte thread gestart zou worden

Voor het gelijktijdig doen van meerdere requests heb je aan een thread genoeg.

[kid1988]

ik denk dat het versturen van de request van alle plaatjes ed langer duurt dan het renderen en verwerken van de website op 1 thread.. aangezien de upload van de gemiddelde nederlands niet boven de 1 mbit komt (toch het max van adsl?)

[Anoniem: 61096]

Upload is niet echt relevant als ik een verbinding maak met websites van bv Microsoft, Novell, IBM of Tweakers.

[Munters]

Iets coderen en tegelijk heel wat anders doen (iets met realtime java spelen bv) wertk standaard totaal niet. Het hapert gigantisch.
Maar als het processingtype van de encoder op "idle" zet (windows noemt dit prioriteit), werkt het perfect hoor.

Ik moet alleen steeds handmatig die keuze maken. Ik mis eigenlijk de mogelijkheid bepaalde processen standaard op "lower" of "idle" mode in te stellen.
Een beetje vergelijkbaar met het idle commando op unix.

Een van de weinige programma die dit wel goed doen is QuickPar. Die heeft deze mogelijkheid ingebouwd en onthoud ook de laatste instelling.

Maar eigenlijk wil ik gewoon een registerhack hebben, waarbij ik kan instellen dat programma X altijd met lagere of idle prioriteit draait.

[BugBoy]

Het prettigste zou zijn dat de encoder zijn eigen prioriteit al naar beneden zou schroeven. Ik encode altijd in idle time en dan pakt hij gewoon 99% CPU time. Maar als ik een browser opstart dan gaat dat gewoon lekker vlot en hapert wellicht de encoding even.

[Ge Someone]

Ik mis eigenlijk de mogelijkheid bepaalde processen standaard op "lower" of "idle" mode in te stellen.
Een beetje vergelijkbaar met het idle commando op unix.

Ik ken op Unix het "nice" commando ...
Op Windows kun je een app starten (command line of shortcut) met: start /low "app"
Er zijn best meer progjes die, zoals QuickPar, de prioriteit zetten. De meeste die ik ken zijn frontends voor encoders.

[RetepV]

Ach, ach, Microsoft is de laatste tijd wel de feiten aan het achternalopen, is het niet? Ze hebben de afgelopen 'tig jaar al hun resources aan het 'ouderwetse' programmeren gespendeerd, en alles wat met parallelle verwerking te maken heeft links laten liggen. Het is imo al een wonder dat er threads zitten in Windows.

Er is in de jaren '80 ZO VEEL onderzoek gedaan naar parallellisatie, dat er voorlopig helemaal niks nieuws bedacht hoeft te worden. Ze kunnen gewoon de bibliotheek induiken waar al die kennis gewoon ligt te wachten.

Maar het probleem zit hem er natuurlijk in dat Windows er helemaal niet voor geschikt is. Niemand heeft aan parallellisatie gedacht toen ze Windows of .NET bedachten.

Nou hebben ze Windows Vista bijna klaar liggen, maar dat blijkt achteraf helemaal niks revolutionairs te zijn, alleen maar een voortborduring op Windows 2003/XP. Het zal wel beter zijn (in de zin van stabiliteit en onderhoudbaarheid), maar alle revolutionaire dingen zijn er zo'n beetje uitgehaald of zijn er nooit in geweest.

Ik zou tegen Apple zeggen: het is nu of nooit. Apple's OS/X is veel modulairder dan Windows en ik durf te wedden dat support voor multicore processors er al in zit, of er anders zonder al te veel moeite bij gemaakt kan worden (microkernel, itt. tot Windows). Voor OS/X zijn al aardig wat applicaties te vinden. En aangezien Apple geen kleine speler is, zullen ze ook niet zo veel moeite hebben om softwaremakers over te halen hun programma's te porten naar OS/X x86.

Natuurlijk is Linux er ook nog, maar ik wilde eens een keer NIET Linux en Windows tegenover elkaar zetten .

Ik denk dat het moment voor Microsoft gekomen is dat de wet van de remmende voorsprong tegen hen in actie komt. Als Microsoft met Windows niet snel in kan springen op de veranderende markt, dan verliezen ze het. Ik voorzie dat hun marktaandeel in de komende 2 a 3 jaar een flink stuk zal gaan inzakken.

Edit:

Mensen moeten hier maar eens kijken:
Parallel C for use with the transputer
Of hier:
mpC
Of hier:
Atari had in de jaren '80 al een transputer systeem

Een transputer is een SMP systeem, waarbij je een aantal processoren hebt die in feite zelfstandig zijn, maar die een aantal hardware communicatiekanalen hebben waarmee er onderling gecommuniceerd kan worden.

Edit2:

In feite is dit de sleutel tot het efficient gebruik van multicore CPU's:

The main idea underlying mpC is that an mpC-based application explicitly defines an abstract network and distributes data, computations and communications over the network. The mpC programming system uses this information to map the abstract network to any real executing network in such a way that ensures efficient running of the application on this real network. This mapping is performed in run time and based on information about performances of processors and links of the real network, dynamically adapting the program to the executing network.

En denk bij 'network' nou niet gelijk aan ethernet ofzo, denk nou eens abstract. Een netwerk kan van alles zijn waarmee je data kunt distribueren. Zelfs een netwerk van postduiven.

[Anoniem: 44917]

Inderdaad, overal waar in het artikel gesproken wordt dat het operating system niet klaar is voor dual-core, moet je eigenlijk "Windows" lezen waar "Operating system" staat...

[mjtdevries]

Klinkklare onzin!!

Windows is net zo klaar voor dual-core als MacOS, Linux, BSD en noem ze allemaal maar op.

Het probleem ligt absoluut niet bij de OS-en. Die zijn er allemaal klaar voor.

[mjtdevries]

Je snapt het probleem niet.

Het probleem is niet dat de applicaties niet geschikt zijn om multithreading in toe te passen. Dat zijn ze namelijk wel.

Het probleem is juist dat software developers niet iets nieuws willen aanleren. Zelfs iets relatief simpels als multithreading komt er maar niet doorheen. Dan kun je wel nagaan wat de kansen zijn voor parallel programming.


Tegen de tijd dat de 32 core's per cpu hebben, en bestaande multithreading programma's niet meer efficient op die cpu's verwerkt kunnen worden, DAN wordt het tijd voor een ommezwaai naar parallel programming.
En die ommezwaai zal dan nog veel moeilijker worden dan deze kleine transitie naar multithreading.

[carpin]

Word wat als AMD de X32 80000+ uitbrengt binnenkort.