'Besturingssysteem blok aan het been in multicore-tijdperk'

Anonymous Coward op Donderdag 23 Oktober 2008 08:54

Ik kom niet goed uit dit verhaal. Zijn alle OSen een probleem, of is het een min of meer selecte groep?

Zijn nu OSen de bottleneck of applicaties? Het verhaal loopt nl naadloos over van de één naar de ander.

Hebben OSen en/of applicaties problemen met het werken met meerdere processoren, of is het prbleem dat de hoeveelheid kernen sneller stijgt dan de OSen en/of applicaties bij kunnen houden?

Vervolgens wordt beweerd dat Hypervisors geen oplossing zijn omdat ze slecht kunnen werken met meerdere processoren. Ik dacht juist dat de truuk was dat je een virtuele machine toewees aan een processor. Dus theoretisch 64 virtuele machines aan 64 kernen.

dat veel applicaties slecht rekening houden met de mogelijkheid van parallelle processoren zie ik ook wel. Het is ook nog knap lastig om een goede applicatie te schrijven die met meerdere kernen zinvol kan omgaan. Volgens mij werkt het op dit moment alleen goed als er zo goed als geen interactie nodig is tussen de processen op de verschillende kernen.

14 / 16

dtech op Donderdag 23 Oktober 2008 09:38

Vervolgens wordt beweerd dat Hypervisors geen oplossing zijn omdat ze slecht kunnen werken met meerdere processoren. Ik dacht juist dat de truuk was dat je een virtuele machine toewees aan een processor. Dus theoretisch 64 virtuele machines aan 64 kernen.

Dat levert natuurlijk een enorm voordeel op zolang die VM's/applicaties die erop draaien genoeg hebben aan één core. Het punt in dit artikel is nu juist dat het kan/gaat gebeuren dat toepassingen niet genoeg hebben aan één core.

Overigens is het onderscheid in het artikel tussen OS en applicaties inderdaad non-existent. Ook snap ik niet 100% waarom een besturingsysteem een probleem zou zijn bij meerdere cores. Het hoeft immers enkel (een) core(s) toe te wijzen aan een process.

Het applicatie-gedeelte was echt open deuren intrappen, en ook bestaande recente ontwikkel-omgevingen (.NET in ieder geval, Java weet ik niet helemaal) is het niet-moeilijk om gebruik te maken van threads. (of in ieder geval een stuk makkelijk dan in C(++))

2 / 4

Anonymous Coward op Donderdag 23 Oktober 2008 09:46

Maar kan een programma, dat gebruik maakt van threads, ook automatisch gebruik maken van meerdere processoren? Dat is mij nooit honderd procent bevredigend duidelijk geworden.

4 / 6

nico.coesel op Donderdag 23 Oktober 2008 10:16

Een thread is een apart proces en dat kan dus op een andere core draaien. Het antwoord op jouw vraag is dus JA.

Ik zie het probleem wat Gartner signaleerd ook niet. Typische server toepassingen zijn van zichzelf al multi-threaded. Kijk naar Apache, sendmail, etc die maken voor iedere verbinding zelfs een apart proces aan en hebben dus direct baat bij een multi-core server.

5 / 5

SurfSmurf op Zaterdag 25 Oktober 2008 10:21

Maar niet als het OS al die threads daarna op 1 core laat draaien....

0 / 0

Peter Roozemaal op Donderdag 23 Oktober 2008 10:27

In theorie kunnen als je 64 cores in je systeem hebt 64 threads tegelijkertijd draaien en zou je 64 keer zoveel werk kunnen verzetten als met een enkele core.
In de praktijk moet je het werk dat de threads doen managen, dat betekent applicatie en OS overhead; threads moeten data met elkaar synchroniseren (dat kost tijd), ze zitten elkaar in de weg bij geheugen en schijftoegang en in de meeste gevallen kun je het werk niet eerlijk over 64 cores verdelen...

Een jaar of tien geleden was het mooi als een vier-CPU systeem een performance van drie maal de performance van een vergelijkbaar een-CPU systeem had. Met alle vuistregels zou een factor 27 93**3) versnelling een mooie prestatie voor een 64 (4**3) CPU systeem zijn.

4 / 6

phantom op Donderdag 23 Oktober 2008 11:30

Als je 64 cores hebt kan je niet 64 keer zoveel werk verrichten. Het is een lineare grafiek maar een parabool. Stel dat je een CPU hebt met 2 cores, deze is net zo grof geschat 1,5 keer zo snel als een CPU met 1 core, een CPU met 4 cores is geschat 2 keer zo snel, etc., etc.

5 / 5

vincent1234 op Donderdag 23 Oktober 2008 09:47

Het is ook nog knap lastig om een goede applicatie te schrijven die met meerdere kernen zinvol kan omgaan.
Is het niet simpel een kwestie van multithreading? Het OS zorgt dan dat de threads bij andere kernen (indien aanwezig) terechtkomen.
Het is niet altijd zinvol om te multithreaden, maar als het zinvol is, dan is het niet moeilijk om te doen. Ik neem aan dat je zelfs utility-classes heb in de diverse programmeeromgevingen die dit simpel afhandelen

3 / 3

MvO op Donderdag 23 Oktober 2008 13:19

maar als het zinvol is, dan is het niet moeilijk om te doen.
Behalve race conditions, deadlock, live lock and so nog een aantal threading issues is het niet lastig. Er zijn echter hele slimme mensen die zich met de bovenstaande problemen bezig hebben gehouden die er nog steeds geen oplossing voor bedacht hebben. De enige situatie waarin het simpel is, is wanneer iedere thread totaal onafhankelijk is van alle andere en het resultaat kan leveren aan een "aggregatie-thread". Dat is maar slechts in een deel van de gevallen zo.

3 / 3

vincent1234 op Donderdag 23 Oktober 2008 18:06

er zijn een aantal richtlijnen die je moet aanhouden voordat je multithreading gaat doen, wat betreft hardware-toegang, database/file toegang/shared memory, als je dat goed in de gaten houdt kun je veel voordeel behalen middels multithreading.

0 / 0

MvO op Vrijdag 24 Oktober 2008 10:10

Zelfs als je die richtlijnen volgt, kun je nog de problemen krijgen die ik al eerder noemde. Het probleem daarbij is dat ze dan maar soms voorkomen, hetgeen enorm lastig te debuggen is.

0 / 0

Caesar Tjalbo op Donderdag 23 Oktober 2008 11:01

(Peter Koopman) ...
Zijn nu OSen de bottleneck of applicaties? ...
Als ik het verhaal goed begrijp dan is het probleem dat processoren met 1 core geen performance verbetering meer kennen en dat de performance verbetering in multicore gezocht wordt:

(artikel) Een 'single threaded' applicatie die op een oude server niet meer voldoende presteerde, kon in de oude situatie eenvoudigweg worden gemigreerd naar een nieuwe bak met een snellere processor en meer geheugen.

In het multicore-tijdperk heeft een dergelijke migratie weinig zin, aangezien de kloksnelheid nauwelijks nog toeneemt.
Dus eigenlijk zijn de multicore chips en de eisen die aan software worden gesteld het probleem.

3 / 3

lampje74 op Donderdag 23 Oktober 2008 13:34

niet alle processen in een programma zijn paralel te verwerken. dus als een proces erg complex/lang is is de core bezet. En helpt een extra core dus niet. Je kan je voorstellen dat datamining een liniear proces is. en dat als je met meerdere queries bezig bent het zinvol is om meerdere cores te hebben. Maar als de opdracht van zich zelf de core al vol benut heeft het uitbrijden van de cores geen nut om het proces zelf te versnellen. Daar zijn slimmere/snellere cores voor nodig.

Verder blijft de externe I/O van de cpu een probleem in de huidige ontwerpen. Eigenlijk heeft elke core een geheugen bank nodig. Welke ook nog eens gemanaged wordt om buiten de cpu om data te kunnen versturen naar een bank van een andere core. Anderzijds moet de bus breedte omhoog en moet deze dus ook paralel aan te sturen zijn door de diverse cores. Dus een quad core moet een 4x bus breedte hebben en een octo-core een 8x bus breedte.
En dan nog de bottleneck dat de HD's zijn. Daar kan m.i. enkelt een partij paralele RAID hd's bij helpen, teneinde de theoretische doorvoersnelheden op te krikken. Maar dan dient de data wel ook goed opgedeeld te worden over vele schijven. En niet dat 1 data file in z'n geheel maar over 2 of 3 van de 10 hd's versprijd staat. En zelfs dan loop je nog geregeld vast dat meerdere processen van een zelfde HD gebruikmaken en dus de totale perfomance inzakt.
Hier hebben de hardware producenten nog wel ff werk aan.

4 / 4

SurfSmurf op Zaterdag 25 Oktober 2008 10:28

"Als ik het verhaal goed begrijp dan is het probleem dat processoren met 1 core geen performance verbetering meer kennen en dat de performance verbetering in multicore gezocht wordt:"

Dat is niet geheel correct. Er draaien altijd meer processen. Het maakt dus wel uit over hoeveel cores je die processen kunt uitsmeren.
Dat is (althans zou zo moet zijn) zelfs op een simpele thuis PC het geval.
Filmpje kijken terwijl op de achtergond een download loopt en wat render werk draait.

0 / 0

randakar op Donderdag 23 Oktober 2008 12:10

Ik kan me niet voorstellen dat dit over alle operating systems gaat. Als je kijkt naar b.v. Linux - dat OS domineert de top 500 snelste computers*. En die machines hebben allemaal minimaal honderden en in sommige gevallen tienduizenden processoren...

*) Zie:
http://www.top500.org/stats/list/31/os
http://www.top500.org/list/2008/06/100

5 / 7

super op Donderdag 23 Oktober 2008 20:47

beetje onzinnig want ten eerste zijn dat vaak heftig aangepaste versies van linux en ten tweede worden er met die computers voornamelijk gerekend/gesimuleerd aan problemen die goed paralleliseerbaar zijn. Als jij apache op zo'n rekenmonster zet (als het zou lukken) draait het echt niet heel snel hoor.

0 / 0

lampje74 op Donderdag 23 Oktober 2008 22:57

Dat Linux op dat soort super computers draait is een goed voorbeeld van een schaalbaar OS. MS zou zo iets niet zomaar lukken. Al is te stellen dat MS zich er niet mee bezighoud. Daar in tegen is de openheid van Linux een groot voordeel omdat de experts volledig toegang hebben tot de kernel en de rest van het OS om het OS goed te laten werken op de hardware.

0 / 0

Nickname op Zaterdag 25 Oktober 2008 17:21

Euhm... dat van Apache is volgens mij een slecht voorbeeld, volgens mij kan Apache nu juist wel heel goed omgaan met meerdere cores. Maar verder .. je hebt vast gelijk :)

0 / 0

Jeroenh op Vrijdag 24 Oktober 2008 17:54

Response-tijd gaat het over. Dat heeft ook te maken met I/O. En die zat snor op oude RISC servers, en zit nu ook snor op AMD64 (x86-64). Applicaties zoals MySQL ondersteunen bovendien wel meerdere cores. Het is niet zo dat iedere applicatie dat moet ondersteunen, maar het is ook niet eenvoudig te implementeren (zie reactie van MvO hieronder). Er zijn vast belangrijke programmas die nooit voor threading zijn geschreven, en die zo brak en spaghetti code zijn dat men het ook niet kan implementeren. In zo'n geval is een multi-core processor ipv zoals 'vroeger' een snellere processor geen oplossing. Goh! Dat wist 1 jaar geleden nog niemand!! Eigenlijk is dit dus niet zo'n interessante conclusie, en ook niets nieuws...

0 / 0

Anonymous Coward op Donderdag 23 Oktober 2008 09:34

Begrijp best dat dit een probleem aan het worden is, maar aan de andere kant parallel processing bestaat al wat langer dan vandaag. Kan me niet voorstellen dat IBM of SUN geen algorithmen klaar hebben liggen die naadloos in een nieuw te ontwikkelen besturingssysteem passen.

2 / 2

dtech op Donderdag 23 Oktober 2008 09:42

In de huidige en verledene parrel processing ging het toch vaak om (meestal wetenschappelijke of semi-wetenschappelijke) berekeningen waarin eenzelfde berekening toegepast moest worden op een hele grote dataset. Dat is natuurlijk betrekkelijk eenvoudig op te delen.

Het probleem waarvoor de huidige (en toekomstige?) generatie IT'ers staat is niet alleen het opdelen van een algoritme/programma in afzonderlijke delen, maar ook die delen met elkaar laten communiceren en gesynchroniseerd houden. Dat is immers toch wat voor een "gebruiks"-programma nodig is.

3 / 3

Anonymous Coward op Donderdag 23 Oktober 2008 09:50

Ik denk dat het in de toekomst meer over clustering van taken zal gaan (indelen van processoren in groepjes). Parallel processing waar dat nodig is en neurale netwerken tussen clusters. De algorithmen daarvoor liggen allemaal al ergens op de plank. Het is meer een kwestie wie als eerste de implementatie schrijft.

2 / 2

HtHoope op Donderdag 23 Oktober 2008 09:56

Ik denk dat ander probleem is dat software bedrijven zoals Microsoft zijn licenties baseert op de hoeveelheid kernels die een computer/server heeft, zij moeten weer terug naar de situatie waarin een OS licentie per computer/server wordt verstrekt en niet per kernel.

Ik kan mij niet voor stellen dat zij deze melkkoe zomaar opgeven.

1 / 1

MvO op Donderdag 23 Oktober 2008 13:31

Grappig dat je juist het bedrijf noemt dat per processor rekent en niet per core. Dat is namelijk precies waarmee Microsoft zich met licentiekosten profileert ten opzichte van Oracle en IBM die wel per core rekenen. Oracle rekent heeft daarbij een wat eigenaardig model waarin een core gelijk staat aan 75% van een processor (4 cores = 3 processoren).

2 / 2

Aaargh! op Donderdag 23 Oktober 2008 10:01

Persoonlijk denk ik dat de processor in de meeste gevallen niet de meer de bottleneck is. Ze kunnen die processor wel steeds sneller maken maar er is helemaal geen markt voor. Je ziet ook dat juiste zuiniger processoren op dit moment helemaal hot zijn.

0 / 4

Anonymous Coward op Donderdag 23 Oktober 2008 10:56

Ik denk dat je dit een beetje teveel op de consumentenmarkt betrekt.

1 / 3

Anonymous Coward op Donderdag 23 Oktober 2008 11:06

Hm.. Amoeba en de programmeertaal Orca komen bovendrijven.

Geheel gratis beschikbaar (inclusief broncode uiteraard) voor diverse architecturen.

Wellicht kan dit als inspiratiebron dienen.

4 / 4

Anonymous Coward op Donderdag 23 Oktober 2008 11:20

Amoeba is toch voor farms? Er zit volgens mij een verschil tussen distributed computing en multicore computing. Maar je hebt misschien gelijk met de opmerking, dat het als inspiratiebron kan dienen.

3 / 5

MvO op Donderdag 23 Oktober 2008 13:34

Orca, daar moest ik ook aan denken, grappig. Ik herinner me het college parallel programmeren van Prof. Bal nog, als is dat al bijna 15 jaar geleden.

2 / 2

Vee op Donderdag 23 Oktober 2008 17:28

We moeten dus steeds sneller naar het nieuwste OS overstappen om iets aan de extra cores te hebben. Het OS wordt de komende jaren het grote probleem.

De oplossing moet volgens Gartner worden gezocht in nieuwe programmeertalen

Allemaal leuk, nieuwe programeer talen, maar als de basis (OS) niet multithreaded is dan blijf je nog steeds met een have oplossing zitten.
Lijkt me voor dit probleem veel beter om de oplossing to zoeken in een nieuw op multithreading gebaseerd os.
Namen die dan opkomen zijn bv Haiku en Syllable.

0 / 0

eerde op Donderdag 23 Oktober 2008 18:54

Ik zie het voordeel nog niet van het het draaien van een (1) proces over meerdere core's. Juist bij meerdere core's kan je ieder proces aan een aparte core toewijzen. Lang leve meerdere core's.

Als ik kijk zie ik vaak een core op 48% staan en een volgend proces een andere core nemen b.v. op 17%.

Wanneer komen de octacore's beschikbaar ?

0 / 0

super op Donderdag 23 Oktober 2008 20:51

vrij simpel, je kunt het vergelijken met arbeiders die aan hetzelfde product werken (1 proces op twee cores) of met twee arbeiders die aan twee verschillende producten werken (1 proces per core). in het eerste geval is het product sneller klaar en dat kan grote voordelen hebben als je het snel nodig hebt.

0 / 0

Anonymous Coward op Donderdag 23 Oktober 2008 21:55

Het hoeft niet elke keer op een nieuwe OS over te stappen want er is namelijk 1 OS die al voor meerdere multi cores is gebouwd.
Namelijk BeOS/Haiku!

BeOS
nl.youtube.com/...feature=related

nl.youtube.com/...feature=related

1 / 1

krak op Donderdag 23 Oktober 2008 22:38

Gartner deed altijd uitspraken met 80% kans.
Dit lijkt mij meer 80% gelul en 20% probleem.
Moderne OSsen zijn allemaal thread based en multicore mag geen probleem zijn. Gewoon de threads over de verschillende cores verdelen. Het probleem zit in de applicaties. Als die geen threads gebruiken kan het een probleem worden, maar threadloze applicaties zijn uit de oude doos en draaien op nieuwe dozen zo wie zo sneller dan oorspronkelijk.
Nieuwe applicaties dienen dus zoveelmogelijk van threads gebruik te maken willen ze toekomst vast zijn.
Wie verzonnen heeft dat e1n core alle hardware devices aanmoet spreken is ook niet goed wijs.
Een sd kaartje lezen, een sata disk aansturen en een usbdrive afhandelen kan best onafhankelijk van elkaar.
Per core dus een device.

0 / 0

lampje74 op Donderdag 23 Oktober 2008 23:07

en daar (lijkt) MS een steekje te hebben laten vallen...
Maar juist de rand componenten in je PC limiteren het parallel verwerken/uitvoeren van taken. bij het opstarten van je windows pc lopen veel processen. Deze worden vast wel verdeeld waar het kan. echter is er maar 1 chip die de hd's aanstuurdt. en veelal staan alle programme's die gestart moeten worden op 1 schijf. de IO chip en de sata databus en de HD kunnen niet paralel werken. en dus wacht de een op de ander. dus eerst betere hardware en 'verplicht' 3 of meer hd's in een raid configuratie (10?) om de doorvoer op te krikken, en liefst een aangepaste raid controller welke meerdere tasks aan kan en dus parallel meerdere data blokken kan ophalen/wegschrijven.

Of te wel, Gartner zit er een beetje naast. De rest van het mobo/chipsets/pc hardware moet multicore compatible worden. Daar zit momenteel de bottleneck.

(en ja, ik val in herhaling op m'n vorige posting in dit topic)

0 / 0

SurfSmurf op Zaterdag 25 Oktober 2008 10:19

Ik draai XP-64 bit op een Intel Quadcore.
Vooral videobewerkings tools halen *veel* voordeel uit die meerdere cores.
Maar dat is de verdienste van de programmeurs van die (opensource) programma's
Over MS kan ik helaas niet zo positief zijn.
Als ik meerdere programma's draai die slechts 1 core gebruiken zou ik verwachten dat het OS de load ongeveer evenredig over de cores verdeelt.
Helaas kan is vrij vaak zelfs haast niet surfen omdat 1 core 100% vol zit en de andere cores vrijwel leeg zijn.

1 / 1

lampje74 op Zaterdag 25 Oktober 2008 23:15

En daar heeft Gartner dus, blijkbaar, gelijk dat het OS een obstakel vormt.
Maar, gezien het artikel zich focust op servers en server applicaties en niet zo zeer op enduser OS/apps, hou ik ook vast aan m'n stelling dat de rand hardware nog echt multi-core compatible moet worden.

0 / 0