[alg] Gebruik maken van multiple cores

[Alarmnummer]

Olaf van der Spek schreef op zaterdag 18 augustus 2007 @ 12:37:
[...]

In plaats van threads kun je hier ook async of non-blocking IO gebruiken.

Dat is een andere mogelijkheid. Helaas is non blocking io niet altijd beschikbaar, en dan is het wel handig dat je met threads kunt werken.

Verder moet je voor non blocking io een ander programmeermodel toepassen en per case moet je kijken (als het al mogelijk is) of het wel de moeite waard is. Complexiteit kost tijd/geld.

[ Voor 31% gewijzigd door Alarmnummer op 18-08-2007 12:56 ]

[LauPro]

H!GHGuY schreef op vrijdag 17 augustus 2007 @ 19:25:
[...]
Een OS mag naar mijn mening hoogstens een "GetNbrOfCores()" functie of iets dergelijks implementeren. Wat ik als programmeur daarmee doe is mijn zaak, daar heeft de kernel helemaal niks mee te zien. Kijk je bijvoorbeeld naar de documentatie van make onder linux dan staat er dat het ideaal aantal compile-jobs wat tegelijk loopt gelijk is aan #cores + 1. Andere software kan dan mss optimaal draaien bij #cores*2 of zelfs gewoon met een vast aantal threads omdat verdere opsplitsing onzin is.
De kernel heeft er dus helemaal geen zaken mee hoe ik mijn software dimensioneer. Hoogstens mag hij me de tools aanreiken om dit op een eenvoudige manier te doen.
(Ik gebruik OS en kernel hier door elkaar, ja. In dit geval vind ik dit geen fout )

Waar het mij om gaat is dat de kernel in een multi-user omgeving de programma's af richt zodat er niet teveel resources wordt gebruikt. In dit geval zou dat dan neerkomen dat wanneer er bijvoorbeeld 32 cores zijn, "GetNbrOfCores()" dan maar doorgeeft dat er 4 cores beschikbaar zijn.

[...]
Enigste voordeel hiervan is dat je gemakkelijk kan vergelijken hoe lang je nodig hebt om een fout op te lossen in elk systeem. Het verschil, kan ik je verzekeren, is groot.[...]De reden waarom transactional memory een grote stap vooruit is is dezelfde waarom ethernet beter is dan token ring op een netwerk waarin: de kans op een collision heel klein is (2 threads willen dezelfde lock), en de overhead van token-passing (lock-nemen/vrijgeven) relatief groot is.

Jij redeneert voor STM voor binnen dezelfde applicatie, ik zie diezelfde voordelen ontstaan wanneer 2 applicaties bijvoorbeeld actief IPC gebruiken. Dus ik snap helemaal dat STM bij multithreaded werkt, maar het werkt ook al bij meerdere single threaded applicaties. Dus ik denk dat we verder wel op 1 lijn zitten op dat punt.

Jij verliest 1 iets uit het oog.
Desktop applicaties zijn een consumer-product. Werkt software niet dan zal de gebruiker er ofwel mee leven, ofwel een concurrerend product kopen. Maar dat concurrerend product is meestal toch maar even "goed". Net doordat desktop computers steeds krachtiger worden, kunnen software-huizen het zich permitteren om "quasi-roekeloos" om te springen met resources.
Als een operatie 2s duurt dan is het de moeite niet om even te kijken of het niet in een halve seconde kan door te optimaliseren.
(ik overdrijf hier natuurlijk wel wat, maar in extremis komt het daarop neer)

Natuurlijk moet de software afgestemd worden naar de markt. Maar het komt maar al te vaak voor dat sommige grote programma's (games om maar even te nomen) proberen vrijwel 100% van het systeem te gebruiken. Gelijk hebben ze, want dan halen ze de beste performance uit je PC. Maar stel dat je op de achtergrond ook nog andere activiteiten wilt hebben draaien (P2P, IM etc) dan wordt dat door 1 programma helemaal om zeep geholpen en echt veel kan je er niet aan doen. Wel als applicaties gewoon lekker 1 core blijven gebruiken als er 2 zijn, dan kan die tweede worden gebruikt voor achtergrondprocessen. Vroeger kwam het wel eens sproradisch voor dat mensen bijvoorbeeld een dual socket A hadden. Die kwamen dan op een LAN en die waren echt de king. Die konden namelijk zowel een zwaar spel draaien (toch maar 1 thread) en zonder problemen aan heftige filesharing doen.

flowerp schreef op vrijdag 17 augustus 2007 @ 21:09:
De logische oplossing is dus gewoon om die zwaardere taken op te splitsen over de cores die op dat moment toch niet zo veel doen, ondanks dat er dus +-50 users op zitten.

Dat is prima, maar als je 8 cores hebt, zorg er dan voor dat die applicatie bijvoorbeeld maximaal 3 cores gebruikt. Dat is eigenlijk waar ik heen wil, dus resource management in het geval van meerdere cores en users. Nog mooier zou het zijn dat je periodiek in je programma een watchdog laat checken wat op dat moment de load van het systeem is, en indien die load niet door het programma zelf wordt veroorzaakt dat er dan ook minder threads worden gebruikt. Zodat als alle 50 users actief zijn bwvs elke applicatie maar 1-2 threads maakt. Maar als iemand helemaal alleen op die server zit hij best 8 threads mag gebruiken. Met threads bedoel ik dan even intensieve processen.

Ik denk niet dat hij zich tegenspreekt. Enkele dagen met een probleem bezig? Joh, ik ben wel eens weken met een (non-MT) probleem bezig. Dat is inherent aan het vak als je het mij vraagt.

Inmiddels heeft hij zijn statement verduidelijkt, het ging niet puur en alleen om MT. Ik weet verder niet wat je als probleem definieert maar ik kan me weinig bugs voorstellen die ook echt weken fulltime werk kost om die op te lossen. Het is meer dat je (imo) soms gewoon even een stapje terug moet doen (soms paar dagen) zodat je het probleem weer helemaal fris kan oppakken. Het heeft vaak geen zin om het te forceren omdat dat alleen maar meer tijd kost.

MSalters schreef op zaterdag 18 augustus 2007 @ 01:15:
[...]
Fout. Dit is juist een klassiek voorbeeld hoe je drie threads kunt gebruiken. De eerste thread is je disk read thread. Deze wacht meestal op I/O, maar als het OS een paar sectoren gelezen heeft staat de input thread klaar. De input thread zorgt ervoor dat de uncompress thread de extra data krijgt. Zolang de uncompress thread data heeft, zal de thread op 100% CPU draaien. Is er een blok uncompressed, dan gaat het naar de write thread en kan de compress thread door. De write thread kan vervolgens blokken op een write operatie.

Wat je zegt is eigenlijk dus de caching (zie Olaf) die de kernel vaak voor je doet. Ik vraag me af of je dat soort systemen in de applicaties moet brengen.

[H!GHGuY]

LauPro schreef op zaterdag 18 augustus 2007 @ 16:50:
Waar het mij om gaat is dat de kernel in een multi-user omgeving de programma's af richt zodat er niet teveel resources wordt gebruikt. In dit geval zou dat dan neerkomen dat wanneer er bijvoorbeeld 32 cores zijn, "GetNbrOfCores()" dan maar doorgeeft dat er 4 cores beschikbaar zijn.

Laten dit dan aub minstens 2 verschillende calls zijn waarbij de ene het aantal cores geeft en de andere de system-load (zoals de load die we kennen van de uptime-tool in linux).
Een programmeur moet er dan maar conclusies uit trekken.

Het initiatief van AMD is hierin een stapje in de goeie richting. Hoewel dit enkel gaat over het monitoren van het eigen proces.

Natuurlijk moet de software afgestemd worden naar de markt. Maar het komt maar al te vaak voor dat sommige grote programma's (games om maar even te nomen) proberen vrijwel 100% van het systeem te gebruiken. Gelijk hebben ze, want dan halen ze de beste performance uit je PC. Maar stel dat je op de achtergrond ook nog andere activiteiten wilt hebben draaien (P2P, IM etc) dan wordt dat door 1 programma helemaal om zeep geholpen en echt veel kan je er niet aan doen. Wel als applicaties gewoon lekker 1 core blijven gebruiken als er 2 zijn, dan kan die tweede worden gebruikt voor achtergrondprocessen.

Dit moet je anders zien. Als je een dualcore hebt en je game gebruikt 1 proc en er draaien nog 2 andere progsels op de andere CPU met een gemiddeld gebruik van 50%, kun je nog tot 50% van de andere CPU gebruiken voor extra performance in je game. Bovendien zijn P2P en IM over het algemeen "idle" applicaties. IM doet meestal niets en P2P is meer I/O intensief om maar die voorbeelden te geven.

Dat is prima, maar als je 8 cores hebt, zorg er dan voor dat die applicatie bijvoorbeeld maximaal 3 cores gebruikt. Dat is eigenlijk waar ik heen wil, dus resource management in het geval van meerdere cores en users. Nog mooier zou het zijn dat je periodiek in je programma een watchdog laat checken wat op dat moment de load van het systeem is, en indien die load niet door het programma zelf wordt veroorzaakt dat er dan ook minder threads worden gebruikt. Zodat als alle 50 users actief zijn bwvs elke applicatie maar 1-2 threads maakt. Maar als iemand helemaal alleen op die server zit hij best 8 threads mag gebruiken. Met threads bedoel ik dan even intensieve processen.

Wat met bvb het omgekeerd evenredig instellen van de prioriteit van de threads tov het aantal threads. Iemand met 1 actieve thread (op 1 CPU) krijgt voorrang op iemand met 8 actieve threads op (max) 8 CPUs.

[MBV]

Het lijkt mij idd het slimste om genoeg threads voor het aantal procs aan te maken, en dan de scheduler te laten bepalen wie wat doet. Dat je in Windows 2 cores nodig hebt om niet je hele PC te laten crashen als outlook crasht is natuurlijk idioot: dat had de scheduler af kunnen vangen met 1 core.
Dat voorlopig 95% van de desktops een OS met slechte scheduler heeft (Linux doet het voor mijn gevoel beter dan Windows) is natuurlijk niet iets waar de hele infrastructuur op moet worden aangepast, lijkt mij.

[Icelus]

Nog een interessant artikel in de Dr. Dobb's van september 2007: How Much Scalability Do You Have or Need? — "Orders" of Throughput.

En in datzelfde nummer een link naar de Berkeley website: The Landscape of Parallel Computing Research: A View From Berkeley.

[Grijze Vos]

H!GHGuY schreef op zondag 19 augustus 2007 @ 12:24:
Laten dit dan aub minstens 2 verschillende calls zijn waarbij de ene het aantal cores geeft en de andere de system-load (zoals de load die we kennen van de uptime-tool in linux).
Een programmeur moet er dan maar conclusies uit trekken.

Ben ik het niet helemaal mee eens. Als gebruiker van bijv. desktop software wil je toch nog iets van controle kunnen hebben over je applicaties. Er zijn zat applicaties waarvan de programmeur vind dat ie best wel alle cpu power op mag slurpen, maar als ik een dual core systeem heb wil ik dat eigenlijk best kunnen limiteren.

[flowerp]

LauPro schreef op zaterdag 18 augustus 2007 @ 16:50:
het komt maar al te vaak voor dat sommige grote programma's (games om maar even te nomen) proberen vrijwel 100% van het systeem te gebruiken. [...] Maar stel dat je op de achtergrond ook nog andere activiteiten wilt hebben draaien (P2P, IM etc) dan wordt dat door 1 programma helemaal om zeep geholpen en echt veel kan je er niet aan doen.

Opzich regelt de scheduler in je OS natuurlijk dat de beschikbare rekentijd evenredig wordt verdeelt over je applicaties. The Completely Fair Scheduler die in de komende kernel release geïntroduceerd wordt belooft dat zelfs nog een beetje meer fair te doen.

Waar het natuurlijk om gaat is dat het weinig zin heeft om met 8 cores en 2 apps die volledig CPU bound zijn, elke app 8 threads te laten spawnen alleen maar om de performance te verbeteren. In dit geval zou je dus liever 2x4 threads zien.

Heb je echter gewoon echt meerdere apps draaien, dan mag de scheduler er lekker voor zorgen dat iedereen gelijke aandacht krijgt. Dat is namelijk gewoon de taak van dat ding.

Nog mooier zou het zijn dat je periodiek in je programma een watchdog laat checken wat op dat moment de load van het systeem is, en indien die load niet door het programma zelf wordt veroorzaakt dat er dan ook minder threads worden gebruikt

Inderdaad, dat is een imho zeer belangrijk element. Een stukje terug in dit topic werd hier al over gediscussieerd. Een soort van addaptive threading zeg maar. De huidige libraries, runtimes en operating systems bieden hier nog te weinig support voor vind ik.

Inmiddels heeft hij zijn statement verduidelijkt, het ging niet puur en alleen om MT. Ik weet verder niet wat je als probleem definieert maar ik kan me weinig bugs voorstellen die ook echt weken fulltime werk kost om die op te lossen.

Een probleem is natuurlijk breder als een bug. Dat kan ook een ontwerp van iets zijn; een OO model, een aanpak, of een algoritme. Wat ik dus bedoelde was dat er gesuggereerd werd dat het te moeilijk was om een software ontwerp te maken waarbij je de verantwoordelijkheden optimaal verdeeld over threads en berekeningen opsplitst in (recursieve) sub berekeningen.

Het is waar dat dit tijd kost, zeker als je het goed wilt doen. Maar het punt is dat bijvoorbeeld functionaliteiten verdelen over verschillende classes ook zeker niet altijd triviaal is. Een tijd terug heb ik een soort data retrieval systeem ontworpen waarbij datasources pluggable waren, de 'sets' van data abstract was en er een eveneens pluggable filter pipe-line tussen te zetten was. Om deze functionaliteiten die ik hier zo even in 1 zin opschrijf op een logische manier onder te verdelen over een groep interfaces, packages en abstracte base classes, die ook nog eens allemaal logische namen moesten hebben, heb ik toch wel zeker meer dan een week lopen schetsen & puzzelen, en dan had ik nog geen regel code geschreven.

Bij een threaded systeem zul je hoofdzakelijk ook over een verdeling na moeten denken. In de grote lijnen van je architectuur kun je het als een uitbreiding van je OO ontwerp zien; classes worden meer 'levend', meer 'actief' om het maar even gevoelsmatig uit te drukken. Het is dus geen onmogelijke complexiteit die je meester moet worden, maar een iets uitgebreidere manier van taken verdelen.

Ben je op dit niveau bang voor te veel race conditions dan heb je te fine grained taken verdeeld. Net zoals bij een OO ontwerp, waar classes "highly cohesive en lowly coupled" moeten zijn, geldt ook voor deze manier van threading dat het relatief onafhankelijke sub-systemen moeten zijn. Communicatie dient via welgedefineerde paden te verlopen en moet simpelweg 'waterdicht zijn'. Als je inderdaad via die welgedefineerde paden communiceert en niet chaotisch allemaal methods gaat aanroepen of instance variablen gaat zitten te veranderen in een shared object, dan is het helemaal niet zo moeilijk.

Het is meer dat je (imo) soms gewoon even een stapje terug moet doen (soms paar dagen) zodat je het probleem weer helemaal fris kan oppakken. Het heeft vaak geen zin om het te forceren omdat dat alleen maar meer tijd kost.

Mee eens, maar niet helemaal wat ik eerder bedoelde

[H!GHGuY]

Grijze Vos schreef op donderdag 23 augustus 2007 @ 10:28:
[...]

Ben ik het niet helemaal mee eens. Als gebruiker van bijv. desktop software wil je toch nog iets van controle kunnen hebben over je applicaties. Er zijn zat applicaties waarvan de programmeur vind dat ie best wel alle cpu power op mag slurpen, maar als ik een dual core systeem heb wil ik dat eigenlijk best kunnen limiteren.

windows (geen idee van *nix) heeft nu reeds zoiets als CPU affinity. Het betekent dat je kan aangeven op welke CPU een programma mag draaien. Kun je heel eenvoudig inpassen in mijn verhaal door GetNbrOfCores() het aantal toegewezen (default alle) cores te laten teruggeven en GetLoad() de load voor die CPU's.

[LauPro]

H!GHGuY schreef op zondag 19 augustus 2007 @ 12:24:
Laten dit dan aub minstens 2 verschillende calls zijn waarbij de ene het aantal cores geeft en de andere de system-load (zoals de load die we kennen van de uptime-tool in linux).
Een programmeur moet er dan maar conclusies uit trekken.

Liever niet, ben het eens met Grijze Vos, want dan zullen vrijwel developers besluiten dat hun programma het maximum uit het systeem mag halen. En zeker op het Windows platform is wel gebleken dat dit soort keuzevrijheden voor de programmeur uiteindelijk niet ten goede van de eindgebruiker zijn gekomen. Het is mijns inziens aan het platform om te bepalen welk programma de meeste prioriteit mag hebben. (Eventueel op verzoek van de gebruiker.)

Dit moet je anders zien. Als je een dualcore hebt en je game gebruikt 1 proc en er draaien nog 2 andere progsels op de andere CPU met een gemiddeld gebruik van 50%, kun je nog tot 50% van de andere CPU gebruiken voor extra performance in je game. Bovendien zijn P2P en IM over het algemeen "idle" applicaties. IM doet meestal niets en P2P is meer I/O intensief om maar die voorbeelden te geven.

Dat klopt, maar mocht je zoiets als een SFTP server hebben draaien wordt het toch wat andere koek. In een game zijn FPS/response heel belangrijk voor de user experience. Dus ik heb dan liever dat ik 50% van mijn resources reserveer dan dat ik met een diaserie zit opgescheept.

Wat met bvb het omgekeerd evenredig instellen van de prioriteit van de threads tov het aantal threads. Iemand met 1 actieve thread (op 1 CPU) krijgt voorrang op iemand met 8 actieve threads op (max) 8 CPUs.

Ik weet niet of dat handig is, want dan ontmoedig je juist om meerdere threads te gebruiken. Bovendien krijgt dan alle O(1)-geprogrammeerde software voorrang op MT software.

flowerp schreef op vrijdag 24 augustus 2007 @ 00:33:
Opzich regelt de scheduler in je OS natuurlijk dat de beschikbare rekentijd evenredig wordt verdeelt over je applicaties. The Completely Fair Scheduler die in de komende kernel release geïntroduceerd wordt belooft dat zelfs nog een beetje meer fair te doen.

Klopt, dat zit eraan te komen. Maar helaas moeten de Windows users nog even wachten. Wat CFS vooral gaat doen is zich losbreken van het huidige klokregime in de kernel (waarmee nog snellere responses mogelijk zijn). Volgens mij richten ze zich bij Windows op betere priorisatie. Maar ook daar blijven (imo) achtergrondprocessen een te grote impact hebben op desktop applicaties in zijn algemeenheid.

Wat er bij CFS bijvoorbeeld nog niet in zit is ketenpriorisatie met het oog op de user experience (deze scheduler modules zullen nog worden ontwikkeld). Als ik op de achtergrond aan het compileren ben, dan wordt mijn systeem nog steeds merkbaar trager zelfs met de laagste prioriteit (19). Wat het systeem dus moet doen is kijken welke processen impact hebben op mijn user experience en die verhoogte prioriteit geven (zal een samenwerking worden tussen de WM, X11 en de kernel).

Heb je echter gewoon echt meerdere apps draaien, dan mag de scheduler er lekker voor zorgen dat iedereen gelijke aandacht krijgt. Dat is namelijk gewoon de taak van dat ding.

Je moet wel de overhead van thread meerekenen. Ik denk dat 16 threads die bij een 8-core systeem elk 50% van een core gebruiken minder efficent zijn dan 8 threads die elk een volledige core gebruiken. Nu hoeft dat niet in het extreme te worden doorgevoerd, maar aannames zijn fataal wil ik maar even aangeven .

Inderdaad, dat is een imho zeer belangrijk element. Een stukje terug in dit topic werd hier al over gediscussieerd. Een soort van addaptive threading zeg maar. De huidige libraries, runtimes en operating systems bieden hier nog te weinig support voor vind ik.

Ben eigenlijk wel volledig met je eens dat dit de taak is van de toolkits en platforms. Het zou onzinnig zijn als je een dergelijke watchdog in elke applicatie in zou moeten bouwen.

Een probleem is natuurlijk breder als een bug.[...]

Dat is misschien meer iets persoonlijks. Maar ik probeer een probleem altijd te laten terugslaan op een bestaande omgeving. Als het gaat om een geheel nieuwe opdracht dan beschouw ik dat als een project of (hoe cliché) 'een uitdaging'. Dus vandaar mijn opmerking. Het is zeker niet ongebruikelijk dat het opzetten van een architectuur enkele weken in beslag kan nemen. Dit ligt aan de gebruikte methode, velen vinden de watervalmethode PITA maar ook bij agille software development moet je op een gegeven moment een basis vormen - maargoed dat is een andere disuccsie.

Bij een threaded systeem zul je hoofdzakelijk ook over een verdeling na moeten denken. In de grote lijnen van je architectuur kun je het als een uitbreiding van je OO ontwerp zien; classes worden meer 'levend', meer 'actief' om het maar even gevoelsmatig uit te drukken. Het is dus geen onmogelijke complexiteit die je meester moet worden, maar een iets uitgebreidere manier van taken verdelen.

Ben je op dit niveau bang voor te veel race conditions dan heb je te fine grained taken verdeeld. Net zoals bij een OO ontwerp, waar classes "highly cohesive en lowly coupled" moeten zijn, geldt ook voor deze manier van threading dat het relatief onafhankelijke sub-systemen moeten zijn. Communicatie dient via welgedefineerde paden te verlopen en moet simpelweg 'waterdicht zijn'. Als je inderdaad via die welgedefineerde paden communiceert en niet chaotisch allemaal methods gaat aanroepen of instance variablen gaat zitten te veranderen in een shared object, dan is het helemaal niet zo moeilijk.

Ook een van de argumenten die ik mee nam is dat heel vaak O(1) software naar O(N) wordt omgebouwd. Nu durf ik wel te zeggen dat van O(1) naar O(N) minder complicaties op levert dan van O(K) naar O(N). Maar het blijft een punt dat als software niet ontworpen is voor MT daar gewoon hele vervelende situaties voor gaan doen. Als het gaat om een totaal nieuw te ontwikkelen oplossing ligt het wat anders, dan heb je alle vrijheid en tijd om het goed op te bouwen.

Wat je verder stelt over de opbouw van MT software sta ik verder achter.

H!GHGuY schreef op vrijdag 24 augustus 2007 @ 19:00:
windows (geen idee van *nix) heeft nu reeds zoiets als CPU affinity. Het betekent dat je kan aangeven op welke CPU een programma mag draaien. Kun je heel eenvoudig inpassen in mijn verhaal door GetNbrOfCores() het aantal toegewezen (default alle) cores te laten teruggeven en GetLoad() de load voor die CPU's.

Zolang dat onder Windows met wazige parameters, taakbeheer of 3rd party tools moet gebruiken zal dat nooit echt veel gebruikt gaan worden. Misschien een paar gameserverboeren die de load een beetje eerlijk willen verdelen maar het is onwerkbaar als je dat steeds zelf moet instellen. En tevens vind ik het eigenlijk geen taak van de applicatie om te bepalen welke CPU's hij mag gebruiken.

edit:
Ik denk dat we over het algemeen toch wel mogen stellen dat op de huidige generatie PC's de process prioriteit op zijn zachts gezegd nog in de kinderschoenen staan. Veel consoles hadden het al veel langer door dat je om een bepaalde responsetijd te garanderen je gewoon bepaalde processen dedicated op een eigen processor moet zetten. In de electronicawereld is het al heel lang gebruikelijk om bepaalde functies een eigen aansturing te geven.

Natuurlijk begrijp ik dat er op de gemiddelde PC 100+ processen naast elkaar draaien en dat dat logischerwijs tot gevolg heeft dat er soms vertraging op kan treden bij de verkeerde processen (vanuit de gebruiker gezien). Maar nog steeds ben ik eigenlijk nergens een functie tegengekomen waarbij prioriseren ook daadwerkelijk werkt zoals een gebruiker verwacht. Als ik onder Windows een process 'realtime' prioriteit geef, dan is het nog steeds mogelijk dat een low priority - maar wel fanatieke - virusscanner alle disk I/O op vreet wat alsnog dat realtime process vertraagd.

Men denkt volgens mij op dit punt vrij veel in hokjes. Als het gaat om process priorisatie dan moet dit voor een process op alle vlakken gebeuren, zowel CPU-tijd alswel extern geheugen en I/O.

[ Voor 7% gewijzigd door LauPro op 26-08-2007 04:19 ]

[flowerp]

LauPro schreef op zondag 26 augustus 2007 @ 04:08:
Als ik op de achtergrond aan het compileren ben, dan wordt mijn systeem nog steeds merkbaar trager zelfs met de laagste prioriteit (19). Wat het systeem dus moet doen is kijken welke processen impact hebben op mijn user experience en die verhoogte prioriteit geven (zal een samenwerking worden tussen de WM, X11 en de kernel).

In de praktijk heb ik FAH 2x draaien op mijn AMD 4200+, onder Debian Etch (testing van midden 2006) met de 2.6.15 kernel. Deze pakt 2x 100% load, maar ik merk er -absoluut- niets van. Sterker nog zelfs als ik een full-rebuild doe van een +200.000 regels code project in Eclipse (en die gaat er echt flink los op), dan kan ik nog redelijk mail lezen in Thunderbird of het web surfen via Firefox.

Er zijn nog wel situaties voor verbetering vatbaar, want een vertraging van het systeem door een achtergrond proces dat zelfs de muis in X begint te skippen is me ook weer niet totaal onbekend natuurlijk.

Je moet wel de overhead van thread meerekenen. Ik denk dat 16 threads die bij een 8-core systeem elk 50% van een core gebruiken minder efficent zijn dan 8 threads die elk een volledige core gebruiken.

Uhm, dat zei ik toch ook precies daaronder?

Als het gaat om een geheel nieuwe opdracht dan beschouw ik dat als een project of (hoe cliché) 'een uitdaging'.

*lol*

Men denkt volgens mij op dit punt vrij veel in hokjes. Als het gaat om process priorisatie dan moet dit voor een process op alle vlakken gebeuren, zowel CPU-tijd alswel extern geheugen en I/O.

Inderdaad, en de aangewezen methode om een process op dit vlak te beteugelen is waarschijnlijk virtualisatie. Je ziet dat bijna alle dominante markt partijen daar enorm op aan het inzetten zijn. Feitelijk draaien alle Java en .NET programma's al in een virtual machine, en er is zeer veel gaande rond alle diverse hypervisor oplossingen en interfaces daar toe.

Nu al kun je op b.v. een Xen bak redelijk gedetailleerd een hoeveelheid resources toekennen aan virtual clients. Zo kun je bijvoorbeeld de hoeveelheid cores toekennen, of de maximale hoeveelheid geheugen. Nu is de huidige opstelling helemaal gericht op servers, maar het is niet ondenkbaar dat deze technologie in de toekomst ook voor desktop toepassingen gebruikt zal gaan worden.

[.oisyn]

Grijze Vos schreef op donderdag 23 augustus 2007 @ 10:28:
[...]

Ben ik het niet helemaal mee eens. Als gebruiker van bijv. desktop software wil je toch nog iets van controle kunnen hebben over je applicaties. Er zijn zat applicaties waarvan de programmeur vind dat ie best wel alle cpu power op mag slurpen, maar als ik een dual core systeem heb wil ik dat eigenlijk best kunnen limiteren.

Als een app zich erop richt om 100% load te halen zodat alles zo snel mogelijk werkt, wil dat nog niet direct zeggen dat alle andere apps meteen unresponsive zijn. Je hebt namelijk ook nog gewoon zoiets als thread scheduling en prioriteiten. Als je die app op lage prioriteit zet, zal hij 100% van het systeem gebruiken als je verder niets doet, maar alleen maar de overige 25% als je toevallig een HD filmpje aan het kijken bent.

LauPro schreef op zondag 26 augustus 2007 @ 04:08:
[...]
Liever niet, ben het eens met Grijze Vos, want dan zullen vrijwel developers besluiten dat hun programma het maximum uit het systeem mag halen.

En laten ze dat alsjeblieft doen, je hebt niets aan al je processing power als je CPU 90% van de tijd uit z'n neus zit te eten, alleen maar omdat die ene app niet alle resources mag gebruiken zodra die beschikbaar zijn.

[MBV]

@.iosyn: zolang er nog geen goeie schedulers zijn (voor windows) wil ik als gebruiker toch dat stukje invloed houden.

[Grijze Vos]

.oisyn schreef op maandag 27 augustus 2007 @ 11:21:
[...]

Als een app zich erop richt om 100% load te halen zodat alles zo snel mogelijk werkt, wil dat nog niet direct zeggen dat alle andere apps meteen unresponsive zijn. Je hebt namelijk ook nog gewoon zoiets als thread scheduling en prioriteiten. Als je die app op lage prioriteit zet, zal hij 100% van het systeem gebruiken als je verder niets doet, maar alleen maar de overige 25% als je toevallig een HD filmpje aan het kijken bent.

En stel nou dat ik een geavanceerde gebruiker ben, die gewoon 1 van mijn 8 cores op mijn desktopje wil laten idlen, zodat ik bepaalde data die ik at any time binnen kan krijgen realtime kan verwerken. (Ja, beetje over the top voorbeeld).

Ik ben het met je eens dat apps gewoon die processortijd zouden moeten kunnen pakken, maar dat de gebruiker nog altijd de controle daarover moet kunnen hebben. De eindverantwoordelijkheid van scheduling zit bij de scheduler (eventueel gestuurd/getweaked door de gebruiker), niet bij de applicatie of de applicatie-developer. Per default mag een applicatie best slurpen, maar je mag best tegen je scheduler zeggen dat applicatie X niet alle cores mag vol trekken.

Mijn ervaring (als gebruiker) heeft me gewoon geleerd dat priorisatie niet 100% werkt. Een voorbeeld is bijv. Seti@Home draaien naast een Counterstrike servertje. Seti draaide met de laagste nice prio mogelijk, en CS met de hoogste prio mogelijk, en toch draaide die CS server niet lekker (de spelers hadden last van lichte latency), terwijl theoretisch de scheduler dit zou moeten oplossen.

Het probleem is gewoon dat de processer power die de CS nodig heeft nogal verschilt van seconde tot seconde, en de scheduler kon hier gewoon niet goed op anticiperen. Dan ben je toch wel blij dat je gewoon kunt zeggen dat Seti met zn fikken van CPU0 afblijft.

Ok, dit is dan wel een server-toepassing, maar goed, ik kan me soortgelijke dingen bedenken die ik op mijn desktop zou willen draaien.

Ik hoop dat ik het een beetje begrijpelijk heb opgeschreven.

[.oisyn]

MBV schreef op maandag 27 augustus 2007 @ 13:38:
@.iosyn: zolang er nog geen goeie schedulers zijn (voor windows) wil ik als gebruiker toch dat stukje invloed houden.

Waar haal je vandaan dat die er niet zijn? Als je via taskmanager een proces op low of idle priority zet, dan zal hij niet je responsiviteit beinvloeden.

Grijze Vos schreef op maandag 27 augustus 2007 @ 13:48:
[...]

En stel nou dat ik een geavanceerde gebruiker ben, die gewoon 1 van mijn 8 cores op mijn desktopje wil laten idlen, zodat ik bepaalde data die ik at any time binnen kan krijgen realtime kan verwerken. (Ja, beetje over the top voorbeeld).

Dan kun je de affinity mask van dat proces instellen, waardoor je app nooit de 100% load zal halen. Ik vind dat echter nog geen reden dat het voor de app niet opvraagbaar mag zijn hoeveel cores er zijn.

Mijn ervaring (als gebruiker) heeft me gewoon geleerd dat priorisatie niet 100% werkt. Een voorbeeld is bijv. Seti@Home draaien naast een Counterstrike servertje. Seti draaide met de laagste nice prio mogelijk, en CS met de hoogste prio mogelijk, en toch draaide die CS server niet lekker (de spelers hadden last van lichte latency), terwijl theoretisch de scheduler dit zou moeten oplossen.

Te kort door de bocht. Er zijn meer dingen die hier invloed op uitoefenen behalve CPU scheduling. Je netwerk-hardware is ook bezig voor Seti. Seti zorgt er ook voor dat de bussen tijdelijk bezet zijn voor communicatie met die hardware en de hardeschijf.

Ook is het zo dat threads nog altijd met timeslices werken. Als de CS server geen load heeft waardoor Seti een timeslice krijgt, en net daarna is er weer CS informatie dat verwerkt moet worden, dan zal toch eerst de Seti timeslice afgewacht moeten worden.

Het probleem is gewoon dat de processer power die de CS nodig heeft nogal verschilt van seconde tot seconde, en de scheduler kon hier gewoon niet goed op anticiperen. Dan ben je toch wel blij dat je gewoon kunt zeggen dat Seti met zn fikken van CPU0 afblijft.

Kan toch ook?

[Olaf van der Spek]

.oisyn schreef op maandag 27 augustus 2007 @ 14:25:
Ook is het zo dat threads nog altijd met timeslices werken. Als de CS server geen load heeft waardoor Seti een timeslice krijgt, en net daarna is er weer CS informatie dat verwerkt moet worden, dan zal toch eerst de Seti timeslice afgewacht moeten worden.

Is dat zo? Waar komt die info zo ineens vandaan dan?
Bij IO (of een timer) heb je een interrupt en daarna kan het CS proces toch direct die info verwerken?

[Olaf van der Spek]

flowerp schreef op zondag 26 augustus 2007 @ 11:39:
Inderdaad, en de aangewezen methode om een process op dit vlak te beteugelen is waarschijnlijk virtualisatie.

Waarom heb je daar virtualisatie voor nodig? Prioriteiten voor CPU, disk en netwerk IO moeten dat toch ook gewoon zonder virtualisatie op kunnen lossen?

Virtualisatie betekent toch eigenlijk ook gewoon dat de 'standaard' besturingssystemen falen op belangrijke punten qua beveiliging en resource management?

Grijze Vos schreef op maandag 27 augustus 2007 @ 13:48:
Het probleem is gewoon dat de processer power die de CS nodig heeft nogal verschilt van seconde tot seconde, en de scheduler kon hier gewoon niet goed op anticiperen. Dan ben je toch wel blij dat je gewoon kunt zeggen dat Seti met zn fikken van CPU0 afblijft.

Volgens mij is dat slechts speculatie.

[ Voor 29% gewijzigd door Olaf van der Spek op 27-08-2007 14:46 ]

[Grijze Vos]

.oisyn schreef op maandag 27 augustus 2007 @ 14:25:

Kan toch ook?

Maar als jij met de hand zegt proces X mag geen toegang tot Core 6 & 7 (van de , en vervolgens vraagt de applicatie hoeveel cores er zijn, en dan 8 terug krijgt. Dan spawnt ie dus 8 threads, terwijl 6 even efficient zoniet meer efficient was geweest, want er zijn toch maar 6 cores beschikbaar. Is het dan niet beter om gewoon 6 terug te krijgen van het OS in de eerste plaats.

Olaf van der Spek schreef op maandag 27 augustus 2007 @ 14:45:
Volgens mij is dat slechts speculatie.

Da's inderdaad speculatie. Als je een betere verklaring hebt hoor ik het graag. Ik ben geen guru op het multiprocessing gebied.

offtopic:
@MBV: je hoeft niet te schrikken als ik hoi zeg in de trein hoor.

[ Voor 19% gewijzigd door Grijze Vos op 27-08-2007 14:48 ]

[MBV]

.oisyn schreef op maandag 27 augustus 2007 @ 14:25:
[...]

Waar haal je vandaan dat die er niet zijn? Als je via taskmanager een proces op low of idle priority zet, dan zal hij niet je responsiviteit beinvloeden.

Oh nee? Waarom haperen mijn MP3's dan in windows zodra ik een nieuwe pagina in Firefox laad? Load blijft onder de 80% (single-core), ondanks dat Winamp een real-time prioriteit heeft.

Grijze Vos schreef op maandag 27 augustus 2007 @ 14:47:
[...]

offtopic:
@MBV: je hoeft niet te schrikken als ik hoi zeg in de trein hoor.

offtopic:
Een paar gedachten:"Shit, die kende ik ergens van, wat moet ik terug zeggen?" "Die zat op de TU/e, maar waarover had ik het toen?" "Bwoah, ben hier veel te moe voor" 'k blijf toch een beetje nerd

[ Voor 31% gewijzigd door MBV op 27-08-2007 14:52 ]

[Olaf van der Spek]

Grijze Vos schreef op maandag 27 augustus 2007 @ 14:47:
Maar als jij met de hand zegt proces X mag geen toegang tot Core 6 & 7 (van de , en vervolgens vraagt de applicatie hoeveel cores er zijn, en dan 8 terug krijgt. Dan spawnt ie dus 8 threads, terwijl 6 even efficient zoniet meer efficient was geweest, want er zijn toch maar 6 cores beschikbaar. Is het dan niet beter om gewoon 6 terug te krijgen van het OS in de eerste plaats.

Waarschijnlijk wel, maar dat lijkt me een klein implementatie detail en geen groot probleem.

Da's inderdaad speculatie. Als je een betere verklaring hebt hoor ik het graag. Ik ben geen guru op het multiprocessing gebied.

Ik ken beide apps ook niet.

MBV schreef op maandag 27 augustus 2007 @ 14:51:
Oh nee? Waarom haperen mijn MP3's dan in windows zodra ik een nieuwe pagina in Firefox laad? Load blijft onder de 80% (single-core), ondanks dat Winamp een real-time prioriteit heeft.

Slechte hardware of drivers.

Over de Windows scheduler: wat Windows volgens mij wel mist is om te kunnen zeggen dat deze app (of priority class) minimaal 90% van de CPU tijd beschikbaar moet hebben. Nu draait een game met dezelfde priority als de meeste andere processen en als zo'n proces dan CPU bound is, dan verliest de game zo 1/3 van zijn CPU tijd en dat is niet handig.
Hoe lang zijn de time slices tegenwoordig eigenlijk in Windows?

[ Voor 70% gewijzigd door Olaf van der Spek op 27-08-2007 15:05 ]

[.oisyn]

Olaf van der Spek schreef op maandag 27 augustus 2007 @ 14:43:
[...]

Is dat zo? Waar komt die info zo ineens vandaan dan?
Bij IO (of een timer) heb je een interrupt en daarna kan het CS proces toch direct die info verwerken?

Nou moet ik toegeven dat ik dat ook niet direct weet, maar jij beweert dus dat bij een interrupt de timeslice afgebroken wordt en de thread opnieuw gescheduled moet worden? Zou kunnen hoor .

Grijze Vos schreef op maandag 27 augustus 2007 @ 14:47:
[...]

Maar als jij met de hand zegt proces X mag geen toegang tot Core 6 & 7 (van de , en vervolgens vraagt de applicatie hoeveel cores er zijn, en dan 8 terug krijgt. Dan spawnt ie dus 8 threads, terwijl 6 even efficient zoniet meer efficient was geweest, want er zijn toch maar 6 cores beschikbaar. Is het dan niet beter om gewoon 6 terug te krijgen van het OS in de eerste plaats.

In de praktijk is het niet eens zo simpel als "geef me het aantal cores", want zelfs als je dat weet en je mag ze allemaal gebruiken is het wellicht niet handig om gewoon maar dat aantal threads te spawnen en het OS ze maar te laten verdelen over de verschillende cores. Wat je waarschijnlijk eigenlijk wilt is je process afinity mask ophalen (GetProcessAffinityMask() onder windows), daar het aantal threads uithalen, en dan elke thread op een specifieke core schedulen (SetThreadAffinityMask()), en dat ook nog eens om de zoveel tijd opnieuw doen omdat de user wellicht de boel heeft aangepast. Nog beter is het als het gewoon in de app zelf configureerbaar is.

MBV schreef op maandag 27 augustus 2007 @ 14:51:
[...]

Oh nee? Waarom haperen mijn MP3's dan in windows zodra ik een nieuwe pagina in Firefox laad? Load blijft onder de 80% (single-core), ondanks dat Winamp een real-time prioriteit heeft.

Beetje makkelijk om dan meteen de schuld bij Windows' scheduler te leggen, niet? Mijn eerste conclusie zou zijn dat winamp zuigt, waarschijnlijk omdat hij een te korte geluidsbuffer gebruikt en te weinig data van tevoren klaarzet, of dat jij je winamp gewoon niet goed geconfigureerd hebt. Gebruik je wel de directsound output plugin? En is je bufferlengte wel lang genoeg? En je prebuffer?

[Olaf van der Spek]

.oisyn schreef op maandag 27 augustus 2007 @ 15:12:
Nou moet ik toegeven dat ik dat ook niet direct weet, maar jij beweert dus dat bij een interrupt de timeslice afgebroken wordt en de thread opnieuw gescheduled moet worden? Zou kunnen hoor .

Nee, ik ken geen scheduler details, maar zoiets (als er een thread met een hogere prioriteit ready wordt) lijkt me wel een logische aanpak.

In de praktijk is het niet eens zo simpel als "geef me het aantal cores", want zelfs als je dat weet en je mag ze allemaal gebruiken is het wellicht niet handig om gewoon maar dat aantal threads te spawnen en het OS ze maar te laten verdelen over de verschillende cores. Wat je waarschijnlijk eigenlijk wilt is je process afinity mask ophalen (GetProcessAffinityMask() onder windows), daar het aantal threads uithalen, en dan elke thread op een specifieke core schedulen (SetThreadAffinityMask()), en dat ook nog eens om de zoveel tijd opnieuw doen omdat de user wellicht de boel heeft aangepast. Nog beter is het als het gewoon in de app zelf configureerbaar is.

Als het inderdaad handig is een thread aan een bepaalde core te binden kun je dat toch gewoon aan het OS overlaten?

[Grijze Vos]

.oisyn schreef op maandag 27 augustus 2007 @ 15:12:
[...]

In de praktijk is het niet eens zo simpel als "geef me het aantal cores", want zelfs als je dat weet en je mag ze allemaal gebruiken is het wellicht niet handig om gewoon maar dat aantal threads te spawnen en het OS ze maar te laten verdelen over de verschillende cores. Wat je waarschijnlijk eigenlijk wilt is je process afinity mask ophalen (GetProcessAffinityMask() onder windows), daar het aantal threads uithalen, en dan elke thread op een specifieke core schedulen (SetThreadAffinityMask()), en dat ook nog eens om de zoveel tijd opnieuw doen omdat de user wellicht de boel heeft aangepast. Nog beter is het als het gewoon in de app zelf configureerbaar is.

Olaf zegt het hierboven al. Als de scheduler weet dat er in principe 6 van de 8 cores zijn voor proces X, en proces X spawnt 6 threads, dan mag de scheduler die toch slim verdelen. Waarom zou de app zich hier dan bezig mee moeten houden?

Ik weet niet bijster veel af van multithreaded apps bouwen, dus misschien bekijk ik het te simplistisch. Maar als ik mag kiezen tussen de logica 1x in een slimme scheduler te stoppen, of elke applicatiedeveloper zelf laat lopen kutten met thread affinities instellen voor alle threads, dan lijkt me de eerste methode wenselijker.

[MBV]

.oisyn schreef op maandag 27 augustus 2007 @ 15:12:
Beetje makkelijk om dan meteen de schuld bij Windows' scheduler te leggen, niet? Mijn eerste conclusie zou zijn dat winamp zuigt, waarschijnlijk omdat hij een te korte geluidsbuffer gebruikt en te weinig data van tevoren klaarzet, of dat jij je winamp gewoon niet goed geconfigureerd hebt. Gebruik je wel de directsound output plugin? En is je bufferlengte wel lang genoeg? En je prebuffer?

Tja, op linux heb ik het met diverse muziekprogramma's nooit gemerkt. Ook al deed ik iets waardoor heel X leek te bevriezen, MP3's gingen door . En dan niet zoals met een windows-crash het buffer op een oneindige loop, nee, netjes de volgende blokjes van de HDD .
Uiteraard directSound, uiteraard staan mijn buffers lang genoeg om een piek van 0.2sec op de processor op te vangen.

[Alarmnummer]

.oisyn schreef op maandag 27 augustus 2007 @ 14:25:
[...]

Waar haal je vandaan dat die er niet zijn? Als je via taskmanager een proces op low of idle priority zet, dan zal hij niet je responsiviteit beinvloeden.

Dat ligt aan de scheduler. Onder windows krijgen low priority taken na verloop van tijd een 'hogere' prioriteit als ze niet uitgevoerd worden. Dit verhindert dat een low priority taak last heeft van starvation.

[.oisyn]

Olaf van der Spek schreef op maandag 27 augustus 2007 @ 15:27:
Als het inderdaad handig is een thread aan een bepaalde core te binden kun je dat toch gewoon aan het OS overlaten?

Waarschijnlijk wel idd, maar ik kan me voorstellen dat het in bepaalde gevallen beter voorkomen kan worden dat 2 threads van het proces op dezelfde core gerund worden, ipv dat 1 thread een ander proces deelt.

MBV schreef op maandag 27 augustus 2007 @ 16:00:
[...]

Tja, op linux heb ik het met diverse muziekprogramma's nooit gemerkt. Ook al deed ik iets waardoor heel X leek te bevriezen, MP3's gingen door . En dan niet zoals met een windows-crash het buffer op een oneindige loop, nee, netjes de volgende blokjes van de HDD .

Wat natuurlijk meer zegt over de implementatie van de players dan over de scheduler

Alarmnummer schreef op maandag 27 augustus 2007 @ 16:01:
[...]

Dat ligt aan de scheduler. Onder windows krijgen low priority taken na verloop van tijd een 'hogere' prioriteit als ze niet uitgevoerd worden. Dit verhindert dat een low priority taak last heeft van starvation.

Alleen als thread priority boosting aan staat voor die thread (by default btw), kun je uitzetten mbv SetThreadPriorityBoost()

[H!GHGuY]

@.oisyn
De kernel mag elke interrupt en system call gebruiken als mogelijk punt om de scheduler in gang te zetten. In de praktijk zal natuurlijk niet na elke system call of interrupt de scheduling opnieuw gebeuren (of ze zal op z'n minst in O(1) gebeuren) maar een low-prio thread zal zeker geen volledige timeslice krijgen als een high-prio thread op data wacht die plots beschikbaar is gekomen.

LauPro schreef op zondag 26 augustus 2007 @ 04:08:
Liever niet, ben het eens met Grijze Vos, want dan zullen vrijwel developers besluiten dat hun programma het maximum uit het systeem mag halen. En zeker op het Windows platform is wel gebleken dat dit soort keuzevrijheden voor de programmeur uiteindelijk niet ten goede van de eindgebruiker zijn gekomen. Het is mijns inziens aan het platform om te bepalen welk programma de meeste prioriteit mag hebben. (Eventueel op verzoek van de gebruiker.)

Helemaal niet.
Wat weet die "idiote" scheduler er nou van:
- Wat doet elke applicatie? Is het een game, browser, mailclient, news-reader (met bvb UUEncode), video/audio player, of wat dan nog.
- Hoe belangrijk vind IK elke applicatie. Misschien wil ik wel dat mijn video-encoding absoluut prioriteit krijgt op mijn mailclient, zelfs al ben ik een mail aan het typen.

Elke applicatie mag wat mij betreft proberen om die CPU onder tafel te krijgen. Als ik vind dat er iets te corrigeren is dan verander ik de prioriteit of affiniteit wel. (Er bestaan gerust tooltjes die dit automatisch doen voor je)

Dat klopt, maar mocht je zoiets als een SFTP server hebben draaien wordt het toch wat andere koek. In een game zijn FPS/response heel belangrijk voor de user experience. Dus ik heb dan liever dat ik 50% van mijn resources reserveer dan dat ik met een diaserie zit opgescheept.

Juist niet. Je hebt reeds 1 core die 100% van zijn tijd met jouw game bezig is. Er zal dus heus geen diashow ontstaan. Je framerate zal hoogstens omhoog gaan wanneer je 2de core niet bezig is met andere dingen.

Ik weet niet of dat handig is, want dan ontmoedig je juist om meerdere threads te gebruiken. Bovendien krijgt dan alle O(1)-geprogrammeerde software voorrang op MT software.

Dit is natuurlijk binnen de geciteerde context van een terminal server. De applicaties daar zijn meestal ook wel bedoeld om in een terminal server te draaien en er kan dus gerust met dit in het achterhoofd worden geprogrammeerd.

Wat er bij CFS bijvoorbeeld nog niet in zit is ketenpriorisatie met het oog op de user experience (deze scheduler modules zullen nog worden ontwikkeld). Als ik op de achtergrond aan het compileren ben, dan wordt mijn systeem nog steeds merkbaar trager zelfs met de laagste prioriteit (19). Wat het systeem dus moet doen is kijken welke processen impact hebben op mijn user experience en die verhoogte prioriteit geven (zal een samenwerking worden tussen de WM, X11 en de kernel).

Ik ben blij dat je aangeeft dat dit een module wordt. Zie puntje 2 hierboven. Door die module te gebruiken geef je aan dat je user-experience voorneemt op achtergrond-taken wat ze ook zijn.

Je moet wel de overhead van thread meerekenen. Ik denk dat 16 threads die bij een 8-core systeem elk 50% van een core gebruiken minder efficent zijn dan 8 threads die elk een volledige core gebruiken. Nu hoeft dat niet in het extreme te worden doorgevoerd, maar aannames zijn fataal wil ik maar even aangeven .

Dat zal wel gaan meevallen. Als je app echt CPU-bound is en je ook effectief de "volle-100%" kan benutten dan zullen die 100 context switches per seconde per processor weinig uitmaken.

Ben eigenlijk wel volledig met je eens dat dit de taak is van de toolkits en platforms. Het zou onzinnig zijn als je een dergelijke watchdog in elke applicatie in zou moeten bouwen.

Akkoord dat veel functionaliteit in toolkits en platforms moet komen. Maar zoals reeds gezegd mogen ze een developer niet hinderen als hij het wel degelijk beter weet dan de scheduler.

Zolang dat onder Windows met wazige parameters, taakbeheer of 3rd party tools moet gebruiken zal dat nooit echt veel gebruikt gaan worden. Misschien een paar gameserverboeren die de load een beetje eerlijk willen verdelen maar het is onwerkbaar als je dat steeds zelf moet instellen. En tevens vind ik het eigenlijk geen taak van de applicatie om te bepalen welke CPU's hij mag gebruiken.

Zoals aangehaald bestaan er wel tooltjes die zorgen dat je dit niet telkens opnieuw moet instellen.

Bovendien denk ik dat dit ook weer allemaal afhangt van de context. Dat je bij jou terminal server oplossing het aantal threads optimaal wil hebben afhankelijk van de load en andere factoren kan ik gerust geloven. Dat je dus de verantwoordelijkheid wil overlaten aan een andere component is logisch maar de scheduler is imo geen goeie keus. Andere mensen hebben andere noden en de developer moet beslissen welke dat zijn.

Men denkt volgens mij op dit punt vrij veel in hokjes. Als het gaat om process priorisatie dan moet dit voor een process op alle vlakken gebeuren, zowel CPU-tijd alswel extern geheugen en I/O.

Je wil eigenlijk zeggen dat de veelgebruikte metriek van CPU-tijd tekort schiet en gelijk heb je.

[Olaf van der Spek]

H!GHGuY schreef op maandag 27 augustus 2007 @ 21:15:
Dat zal wel gaan meevallen. Als je app echt CPU-bound is en je ook effectief de "volle-100%" kan benutten dan zullen die 100 context switches per seconde per processor weinig uitmaken.

Vergeet locking issues niet.

[flowerp]

Olaf van der Spek schreef op maandag 27 augustus 2007 @ 14:45:
[...]
Waarom heb je daar virtualisatie voor nodig? Prioriteiten voor CPU, disk en netwerk IO moeten dat toch ook gewoon zonder virtualisatie op kunnen lossen?

Virtualisatie betekent toch eigenlijk ook gewoon dat de 'standaard' besturingssystemen falen op belangrijke punten qua beveiliging en resource management?

In feite is een 'standaard' besturingssysteem al als een VM te beschouwen. Veel resources zoals de toegang tot het scherm, de toegang tot het geheugen en diverse soorten toegang tot de hardware worden al virtueel aan een process voorgeschoteld. Een applicatie die geschreven is voor een bepaald OS kan dan ook vrij makkelijk op een andere machine draaien die ook dat OS draait. In de oude dagen waar een applicatie specifiek voor een bepaalde machine was geschreven en dus direct de hardware benaderde, was zoiets niet mogelijk.

Natuurlijk weet jij dat wel, want bij een vak als Operating Systems zul je dat vast wel hebben gehad

In dat licht gezien is de techniek achter de VM een doortrekking van de lijn die met het hele concept van protecting operating systems al in gang is gezet. Op deze manier vormt een VM nog een iets hogere abstractie laag, die als aanvulling/verdere ontwikkeling van je OS gezien kan worden.

[flowerp]

MBV schreef op maandag 27 augustus 2007 @ 16:00:
[...]
Tja, op linux heb ik het met diverse muziekprogramma's nooit gemerkt. Ook al deed ik iets waardoor heel X leek te bevriezen, MP3's gingen door .

Onder OS X eigenlijk het zelfde. Een lowly G3 op minder dan een halve Ghz met 320MB blijft in itunes gewoon m'n MP3's spelen, eigenlijk ongeacht welke gruwelijk load ik op dat oude beestje loslaat. Heel soms hapert ie wel even, maar dat is echt heel soms.

[flowerp]

Een interessant artikel:

http://www.infoq.com/news...allel-hierarchies-pattern

Multi-core processors offer new performance opportunities. Shekhar Borkar from Intel highlighted, however, that software development practices have to be retooled to leverage this potential.

[MNeMoNiCS]

flowerp schreef op woensdag 29 augustus 2007 @ 15:19:
Een interessant artikel:

http://www.infoq.com/news...allel-hierarchies-pattern


[...]

Wat is er dan zo interessant aan dit artikel? Dat het woord parallellisme erin voorkomt?

[H!GHGuY]

flowerp schreef op woensdag 29 augustus 2007 @ 15:19:
Een interessant artikel:
http://www.infoq.com/news...allel-hierarchies-pattern

Ik moest meteen denken aan de "future"s van onze Herb.

eenvoudig voorbeeld in pseudocode:

C++:

future<PartialResult1> Compute1(const Argument1& arg);
future<PartialResult2> Compute2(const Argument2& arg);
future<Result> Compose(const PartialResult1& res1, const PartialResult2& res2);

Result Computation(const Argument1& const arg1, const Argument2& const arg2)
{
   future<PartialResult1> res1(Compute1(arg1));
   future<PartialResult2> res2(Compute2(arg2));
   return Compose(res1.Get(), res2.Get()).Get()
}

Kunnen er 4 of meer/minder threads geholpen hebben aan het berekenen van de return value.
(meer aangezien de Compute/Compose functies nog threads kunnen gebruiken, minder aangezien er niet noodzakelijk een thread gespawned hoeft te worden per "active" call.)

Ik denk dus dat die Mexicaan helemaal niets nieuws maakt. In tegendeel, het stadium waar Herb reeds in zit met zijn onderzoek lijkt me verder te zijn dan waar deze onderzoeker is.

[Alarmnummer]

H!GHGuY schreef op donderdag 30 augustus 2007 @ 19:21:
[...]


Ik moest meteen denken aan de "future"s van onze Herb.

eenvoudig voorbeeld in pseudocode:

C++:

future<PartialResult1> Compute1(const Argument1& arg);
future<PartialResult2> Compute2(const Argument2& arg);
future<Result> Compose(const PartialResult1& res1, const PartialResult2& res2);

Result Computation(const Argument1& const arg1, const Argument2& const arg2)
{
   future<PartialResult1> res1(Compute1(arg1));
   future<PartialResult2> res2(Compute2(arg2));
   return Compose(res1.Get(), res2.Get()).Get()
}

Kunnen er 4 of meer/minder threads geholpen hebben aan het berekenen van de return value.
(meer aangezien de Compute/Compose functies nog threads kunnen gebruiken, minder aangezien er niet noodzakelijk een thread gespawned hoeft te worden per "active" call.)

Ik denk dus dat die Mexicaan helemaal niets nieuws maakt. In tegendeel, het stadium waar Herb reeds in zit met zijn onderzoek lijkt me verder te zijn dan waar deze onderzoeker is.

Ik heb ook de indruk dat hij niets nieuws maakt. Het hele verhaal met hierarchisch taken parallelliseren is niet nieuw. In Java 7 komen ook nog wat 'goodies' om dit in Java nog iets eenvoudiger te maken:

http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166ydocs/

[flowerp]

MNeMoNiCS schreef op woensdag 29 augustus 2007 @ 22:41:
[...]
Wat is er dan zo interessant aan dit artikel? Dat het woord parallellisme erin voorkomt?

Om te beginnen:

Multi-core processors offer new performance opportunities. Shekhar Borkar from Intel highlighted, however, that software development practices have to be retooled to leverage this potential.

Open deur misschien, maar weer een bevestiging (de zoveelste) dat je niet zomaar op je oude manier kunt door developen maar dat je je aanpak echt zult moeten herzien. Dit topic loopt nu bijna een jaar en nog steeds zie ik bergen programmeurs die het hoogstens denken er even bij te doen.

Heel voorzichtig begin ik wel al wat andere geluiden te horen. Bij een development bedrijf waar een kennis van me werkt hebben ze pas een paar programmeurs van de oude garde laten gaan omdat deze na al eens eerder in hun leven de overstap van procedureel naar OO gemaakt te hebben nu niet meer mee konden of willen gaan naar de parallelle aanpak. Goed dit is momenteel een uitzondering, maar voor hoe lang nog?

Als we straks weer in de zoveelste crisis zitten waarbij programmeurs in bosjes moeten smeken om een baan (zoals in 2002), dan is voor een bedrijf natuurlijk de keuze makkelijk. Kies ik voor de nieuwe lichting programmeur voor wie parallel werken 'er gewoon bij hoort', of kies ik voor de verstokte programmeur die 7/8 ~ 15/16 van de dan beschikbare CPU's laat leggen omdat hij of zij parallel werken 'onzin' vind?

[Alarmnummer]

flowerp schreef op donderdag 30 augustus 2007 @ 21:01:
Open deur misschien, maar weer een bevestiging (de zoveelste) dat je niet zomaar op je oude manier kunt door developen maar dat je je aanpak echt zult moeten herzien. Dit topic loopt nu bijna een jaar en nog steeds zie ik bergen programmeurs die het hoogstens denken er even bij te doen.

Idd. Concurrency control is echter wel een erg complex onderwerp die veel developers toch liever links laten liggen. Als je niet op let, dan heb je in de korste keren ook totaal onbegrijpbare code waar je geen uitspraak meer kunt doen over thread veiligheid.

Als we straks weer in de zoveelste crisis zitten waarbij programmeurs in bosjes moeten smeken om een baan (zoals in 2002), dan is voor een bedrijf natuurlijk de keuze makkelijk. Kies ik voor de nieuwe lichting programmeur voor wie parallel werken 'er gewoon bij hoort', of kies ik voor de verstokte programmeur die 7/8 ~ 15/16 van de dan beschikbare CPU's laat leggen omdat hij of zij parallel werken 'onzin' vind?

Concurrency control in zijn huidige vorm zal denk ik voor de meeste developers niet zo snel gesneden koek worden. Ik denk dat goeie frameworks/componenten de pijn kunnen verzachten zodat mensen zich kunnen focussen op de core logica, maar je bent nog steeds een berg kennis nodig om deze goed toe te kunnen passen.

[.oisyn]

H!GHGuY schreef op donderdag 30 augustus 2007 @ 19:21:
[...]


Ik moest meteen denken aan de "future"s van onze Herb.

.oisyn schreef op dinsdag 16 januari 2007 @ 12:31:
Fair enough, hier is de thread-library proposal voor C++09: http://www.open-std.org/j...cs/papers/2006/n2094.html

't Gaat momenteel erg hard met de C++ evolution (mag ook wel als 2009 de target is). De huidige proposals over futures en parallel processing in het algemeen zijn nu:
Proposed Text for Parallel Task Execution
Thread Pools and Futures

[ Voor 31% gewijzigd door .oisyn op 30-08-2007 22:21 ]

[flowerp]

Alarmnummer schreef op donderdag 30 augustus 2007 @ 21:00:
[...]

Ik heb ook de indruk dat hij niets nieuws maakt. Het hele verhaal met hierarchisch taken parallelliseren is niet nieuw.

Dat verhaal is zeker niet nieuw. Op de zelfde site als waar die javadoc staat, kun je ook deze paper van Doug Lea vinden:

http://gee.cs.oswego.edu/dl/papers/fj.pdf

Deze paper is van 1999 ofzo, en ik kan me herinneren dat ik de concepten als eens eerder ben tegengekomen (onder de naam scatter/gatter).

Dit concept is vooral toepasbaar voor recursieve problemen. Fibonnaci is natuurlijk het schoolvoorbeeld hier (letterlijk ), maar ook sorteren (zoals quicksort) valt hieronder. Beide voorbeelden worden dan ook door Doug genoemd in deze paper.

Voor een probleem zoals genoemd in het begin van dit topic is dit minder geschikt (Verwijderd in "[alg] Gebruik maken van multiple cores"). In zo'n geval zou ik eerder voor een grid computing oplossing gaan. In het verleden ben ik eens een tijdje bezig geweest met Globus (http://www.globus.org/toolkit/). Tegenwoordig zie ik b.v. vaak dingen over GridGain.

Een grid infrastructuur kun je gewoon lokaal op je computer gebruiken. Opschalen naar een cluster is redelijk triviaal. Wel is de overhead van communicatie mogelijk groter dan enkele andere oplossingen zodat dit het beste voor redelijk onafhankelijke (sub) tasks gebruik kan worden.

Alarmnummer schreef op donderdag 30 augustus 2007 @ 21:20:
Concurrency control in zijn huidige vorm zal denk ik voor de meeste developers niet zo snel gesneden koek worden. Ik denk dat goeie frameworks/componenten de pijn kunnen verzachten

Inderdaad, het is weer net zoals met OO. Dat concept bestond al velen jaren, maar je moest moeilijk doen met structs or 'records' waarin je dan weer functie pointers opnam en arrays met referenties naar andere structs wat dan weer de subclasses waren etc. Een paar die-hards gebruikte het wel, maar het werd pas echt gebruikt toen je gewoon class foo {}; kon zeggen.

[MNeMoNiCS]

Vraagje aan de mensen die hier zo hard schreeuwen dat multi-core onontkoombaar is: zijn jullie 5 jaar geleden ook allemaal op MMX en SSE instructies gedoken, welke een vorm van data parallellisme toestaan? Zo nee, waarom toen niet en nu wel?

[.oisyn]

Sorry, maar mijn antwoord is toch echt ja . Daarnaast is het echt compleet niet te vergelijken. Sommige processen zijn idd te parallelliseren dmv SIMD. Een raytracer is een uitstekend voorbeeld, de efficientste implementaties maken gebruik van SSE instructies om 4 pixels tegelijk uit te rekenen (ipv de SSE registers te gebruiken als 4d vectoren in 3d berekeningen). Echter, lang niet alle processen doen parallelle berekeningen, en als dat niet het geval is ben je nergens met SSE.

[ Voor 83% gewijzigd door .oisyn op 31-08-2007 00:33 ]

[Alarmnummer]

MNeMoNiCS schreef op vrijdag 31 augustus 2007 @ 00:05:
Vraagje aan de mensen die hier zo hard schreeuwen dat multi-core onontkoombaar is

Ik denk dat je beter de realiteit moet volgen. Het aantal cores in machines gaat de komende jaren alleen maar stijgen, alle bekende fabrikanten (sun, intel, amd) gaan het aantal cores vergroten.

De Sun Niagara II kan al 64 threads parallel draaien.
http://www.theregister.co.uk/2005/12/07/niagara_two_deets/

Deze Intel chip heeft 80 cores!
http://blogs.pcworld.com/staffblog/archives/004701.html

: zijn jullie 5 jaar geleden ook allemaal op MMX en SSE instructies gedoken, welke een vorm van data parallellisme toestaan? Zo nee, waarom toen niet en nu wel?

Ik ontwikkel Java software en werk niet tegen bepaalde instructie-sets doordat Java platform onafhankelijk is. En 5 jaar geleden was ik nog niet zo veel met concurrency control bezig.

[ Voor 11% gewijzigd door Alarmnummer op 31-08-2007 09:47 ]

[Alarmnummer]

flowerp schreef op donderdag 30 augustus 2007 @ 23:25:
[...]


Dat verhaal is zeker niet nieuw. Op de zelfde site als waar die javadoc staat, kun je ook deze paper van Doug Lea vinden:

http://gee.cs.oswego.edu/dl/papers/fj.pdf

Deze paper is van 1999 ofzo, en ik kan me herinneren dat ik de concepten als eens eerder ben tegengekomen (onder de naam scatter/gatter).

Jup.. Scatter Gatherer (Fork/Join) staat ook in "Patterns for Parallel Programming". Leuk boek om door te lezen en om alle kreten eens op een rijtje te krijgen.

In het verleden ben ik eens een tijdje bezig geweest met Globus (http://www.globus.org/toolkit/). Tegenwoordig zie ik b.v. vaak dingen over GridGain.

Daar heb ik nog niets mee gedaan (wel wat over gelezen). Ik ben op dit moment vooral aan het spelen met Terracotta omdat het zo 'not in your face' is.

Inderdaad, het is weer net zoals met OO. Dat concept bestond al velen jaren, maar je moest moeilijk doen met structs or 'records' waarin je dan weer functie pointers opnam en arrays met referenties naar andere structs wat dan weer de subclasses waren etc. Een paar die-hards gebruikte het wel, maar het werd pas echt gebruikt toen je gewoon class foo {}; kon zeggen.

Hmmm.. maybe... maar ik ben minder regels kwijt om onbegrijpbare concurrent code te schrijven, dan oo code.

Bekijk het volgende stukje:

code:

void foo()throws InterruptedException{
   synchronized(a){
      synchronized(b){
         b.wait();
      }
   }
}

Zie je het probleem?

Alhoewel dit natuurlijk ook leuke instinkertjes zijn:

code:

class Foo{
   void match(Integer i){println("Tis een integer");}

   void match(Object o){println("Tis een object");}

   void foo(){
      Object o = new Integer(1);
      match(o);
   }
}

[ Voor 7% gewijzigd door Alarmnummer op 31-08-2007 09:54 ]

[Olaf van der Spek]

Alarmnummer schreef op vrijdag 31 augustus 2007 @ 09:29:
Ik ontwikkel Java software en werk niet tegen bepaalde instructie-sets doordat Java platform onafhankelijk is.

Heeft Java geen (vector) functies die gebruikmaken van die SIMD instructies dan?
In C++ hoef je (volgens mij) ook niet direct met assembly aan de slag om ze te gebruiken, maar je moet wel speciale functies gebruiken, de compiler is (vaak) niet slim genoeg om ze zelf te generenen.

[.oisyn]

Alarmnummer schreef op vrijdag 31 augustus 2007 @ 09:33:

code:

void foo()throws InterruptedException{
   synchronized(a){
      synchronized(b){
         b.wait();
      }
   }
}

Zie je het probleem?

Een mogelijke deadlock als de thread die b.notify() moet doen ook eerst synchronized op a? Maar het zal wel iets met code reordering zijn, of andere vaagheden wegens lack of bepaalde garanties van de VM

Olaf van der Spek schreef op vrijdag 31 augustus 2007 @ 10:15:
[...]

Heeft Java geen (vector) functies die gebruikmaken van die SIMD instructies dan?
In C++ hoef je (volgens mij) ook niet direct met assembly aan de slag om ze te gebruiken, maar je moet wel speciale functies gebruiken, de compiler is (vaak) niet slim genoeg om ze zelf te generenen.

Ik had het hier toevallig gisteren nog over met iemand op een gamedevelopment forum. Iemand vroeg om een reden waarom C# code mogelijk niet net zo snel kon zijn als C++ code. Mijn antwoord was SIMD intrinsics, met daarbij de voetnoot waarom ik het niet snapte dat de VM designers (MS, Sun) niet gewoon een speciaal vector type als native taal-element toevoegde, zodat de JIT compiler makkelijk SIMD assembly kan genereren als dat beschikbaar is. Dat uit generieke code analyseren is namelijk een veel lastiger probleem.

We hebben zelf een math library met vector en matrix classes ontwikkeld die gewoon direct naar inline SIMD assembly code compileert voor alle major platforms (PC, Xbox, Xbox360, PS2, PS3, GC, Wii).

[ Voor 55% gewijzigd door .oisyn op 31-08-2007 11:21 ]

[MNeMoNiCS]

.oisyn schreef op vrijdag 31 augustus 2007 @ 00:29:
Echter, lang niet alle processen doen parallelle berekeningen, en als dat niet het geval is ben je nergens met SSE.

Wat is jouw definitie van een parallelle berekening? En als daar volgens jou dan geen sprake van is, en je nergens bent met SSE, kom je er dan wel met meerdere kernen?

[MNeMoNiCS]

Alarmnummer schreef op vrijdag 31 augustus 2007 @ 09:29:
[...]

Ik denk dat je beter de realiteit moet volgen. Het aantal cores in machines gaat de komende jaren alleen maar stijgen, alle bekende fabrikanten (sun, intel, amd) gaan het aantal cores vergroten.

De Sun Niagara II kan al 64 threads parallel draaien.
http://www.theregister.co.uk/2005/12/07/niagara_two_deets/

Deze Intel chip heeft 80 cores!
http://blogs.pcworld.com/staffblog/archives/004701.html

Ten eerste, die machines zijn bedoeld als servers en dat je daar voldoende (zinnige!) threads hebt om zoveel cores bezig te kunnen houden bestrijd ik ook niet. Ik vraag me af waar jij thuis zoveel cores voor nodig hebt (behalve voor sponsoring van Essent/Nuon/etc).

Ik ontwikkel Java software en werk niet tegen bepaalde instructie-sets doordat Java platform onafhankelijk is.

Dus als Java geen ondersteuning gaat bieden voor "the next best thing, whatever it may be", dan gaat dat moois aan jou voorbij?

En 5 jaar geleden was ik nog niet zo veel met concurrency control bezig.

Ah toen richtte je je nog op sequentiele exception handling?

[MNeMoNiCS]

Alarmnummer schreef op vrijdag 31 augustus 2007 @ 09:33:
[...]


Bekijk het volgende stukje:

code:

void foo()throws InterruptedException{
   synchronized(a){
      synchronized(b){
         b.wait();
      }
   }
}

Zie je het probleem?

Het probleem begint al als je zoiets durft op te schrijven- of denkt dergelijke wazige constructies nodig te moeten hebben

Alhoewel dit natuurlijk ook leuke instinkertjes zijn:

code:

class Foo{
   void match(Integer i){println("Tis een integer");}

   void match(Object o){println("Tis een object");}

   void foo(){
      Object o = new Integer(1);
      match(o);
   }
}

Als je ooit zoiets nodig gehad hebt begin ik me ernstig zorgen te maken of je wel het goede vak gekozen hebt. Probeer het de volgende keer eens met polymorphisme.

[MBV]

Ehm, dat is toch precies wat hij hier gebruikt? Alles overerft van Object Ik kan me zo voorstellen dat een 'noob' deze 2 functies heeft, met als doel dat hij alleen de bekende dingen wil afvangen. Of hij probeert een functie uit een base-class te overriden. Als je dan vervolgens iets uit een verzameling haalt is het altijd een Object (in Java4), dus moet je eerst expliciet casten voor de functie werkt. Best een instinkertje.

Maar los daarvan: hij probeert even een statement te maken. Het is veel makkelijker om multi-threaded in de soep te laten lopen dan OOD/OOP

[flowerp]

MNeMoNiCS schreef op zondag 02 september 2007 @ 23:43:
[...]
Wat is jouw definitie van een parallelle berekening? En als daar volgens jou dan geen sprake van is, en je nergens bent met SSE, kom je er dan wel met meerdere kernen?

Ik ben bang dat jouw kennis nog iets te kort schiet als je deze vraag gaat stellen. Natuurlijk bestaan er een groot aantal soorten van parallellisme, die elke via een specifieke aanpak uitgebuit kunnen worden. SSE, of in het algemeen vector instructies werken door 1 operatie tegelijk toe te passen op meerdere waarden. Vandaar dat dit ook dikwijls SIMD (Single Intruction Multiple Data) genoemd wordt.

Het soort parallellisme waar vector instructies op werken is data parallellisme. Een heel simpel voorbeeld voor dergelijke operaties is wanneer je een lange array van waarden hebt die je alle met 1 wilt ophogen. In plaats van elke keer 1 instructie in te lezen, deze te decoden, dan de volgende waarde in te lezen en de operatie er op uit te voeren, lees en decode je de instructie maar 1 keer, en past deze toe op meerdere waarden tegelijk (SIMD). Een stap verder gaan echte vector processors (of units), die ook de data kunnen pipelinen en elke cycle 1 of meerdere waarden aan die ene instructie kunnen blijven voeden.

Dit soort parallellisme is totaal iets anders dan het soort wat je probeert op te lossen met meerdere threads. In het laatste geval gaat het om een vrij grove vorm van parallellisme, waarbij ook weer 2 sub-soorten te onderscheiden zijn; architectonische subsystemen (de audio thread, de ui thread, etc) en de scatter/gather aanpak voor (met name) recursieve problemen.

Weer een geheel andere soort van parallellisme, die ook weer via een geheel andere techniek wordt uitgebuit is ILP (Instruction Level Parallelism). Instruction pipelining, meerdere functional units, out of order execution in je CPU etc zijn technieken die je hier voor gebruikt.

In deze thread gaat het dus specifiek om het 2de soort parallellisme.

SIMD/Vector operaties zijn in Java niet of moeilijk te realiseren. Dat is een tekortkoming van Java. Niemand heeft hier echter gezegd dat Java de perfecte taal zou zijn. Het soort programma's waar je SIMD voor nodig hebt (met name scientific programming en image (pixel) processing) is ook niet helemaal Java's terrein. C++ wordt op die vlakke veel meer gebruikt en heeft daar dan ook veel betere support voor. Mensen die zich op die terreinen begeven maken dan ook wel -zeer zeker- gebruik van vector instructies!

Ik hoop dat je inziet dat jouw eerdere vraag stelling lichtelijk 'ongeïnformeerd' was, om het voorzichtig uit te drukken.

[Alarmnummer]

MNeMoNiCS schreef op zondag 02 september 2007 @ 23:51:
[...]
Het probleem begint al als je zoiets durft op te schrijven- of denkt dergelijke wazige constructies nodig te moeten hebben

Het punt dat gemaakt wordt ontgaat je. Gezien jouw kennis en ervaring moet het voor jou geen enkel probleem zijn om het concurrency probleem uit te kunnen leggen. Waag eens een poging zou ik zeggen.

Als dat gelukt is, dan zou je misschien kunnen uitleggen waarom dit effect een van de meest gebruikte oo technieken (compositie) zo gevaarlijk maakt binnen concurrency control (met het oog op liveness problemen).

Ik denk dat je genoeg hints hebt gekregen.

Als je ooit zoiets nodig gehad hebt begin ik me ernstig zorgen te maken of je wel het goede vak gekozen hebt. Probeer het de volgende keer eens met polymorphisme.

Ik ben blij dat je een oogje in het zeil houd voor me.

[ Voor 19% gewijzigd door Alarmnummer op 03-09-2007 09:26 ]

[Olaf van der Spek]

MNeMoNiCS schreef op zondag 02 september 2007 @ 23:43:
Wat is jouw definitie van een parallelle berekening? En als daar volgens jou dan geen sprake van is, en je nergens bent met SSE, kom je er dan wel met meerdere kernen?

Een parallelle berekening (of beter SIMD) is als je een bepaalde berekening op meerdere inputs tegelijk toepast.
Bijvoorbeeld het optellen van twee vectors.
De compilatie van een enkel bestand is waarschijnlijk lastig te parallelliseren, maar meerdere bestanden tegelijk compileren op meerdere kernen is eenvoudig te doen.

[.oisyn]

MNeMoNiCS schreef op zondag 02 september 2007 @ 23:43:
[...]


Wat is jouw definitie van een parallelle berekening? En als daar volgens jou dan geen sprake van is, en je nergens bent met SSE, kom je er dan wel met meerdere kernen?

Na het mooie verhaal van flowerp heb ik eigenlijk nog maar 1 ding toe te voegen: in een thread doe je willekeurige operaties (vergelijkingen, berekeningen, API functies aanroepen, etc.), en met SSE doe je identieke operaties, waarbij het soort operaties ook nog eens gelimiteerd is (wiskundige berekeningen op floats en/of ints). Om terug te gaan naar mijn raytracer-voorbeeld, daar is de berekening die je voor elke pixel moet doen hetzelfde - de variabelen zijn alleen anders. Zodra je echter in de ene parallelle taak bijvoorbeeld moet optellen, en in de andere parallelle taak een vergelijking moet doen, dan kan SSE je daarbij niet helpen, omdat de operaties (optellen, vermenigvuldigen, etc) op alle componenten hetzelfde moeten zijn.

MNeMoNiCS schreef op zondag 02 september 2007 @ 23:51:

Het probleem begint al als je zoiets durft op te schrijven- of denkt dergelijke wazige constructies nodig te moeten hebben

[...]

Als je ooit zoiets nodig gehad hebt begin ik me ernstig zorgen te maken of je wel het goede vak gekozen hebt. Probeer het de volgende keer eens met polymorphisme.

Je blaast wel erg hoog van de toren voor iemand die het blijkbaar nog niet helemaal begrepen heeft.

[ Voor 20% gewijzigd door .oisyn op 03-09-2007 11:21 ]

[.oisyn]

Alarmnummer schreef op maandag 03 september 2007 @ 09:06:
Als dat gelukt is, dan zou je misschien kunnen uitleggen waarom dit effect een van de meest gebruikte oo technieken (compositie) zo gevaarlijk maakt binnen concurrency control (met het oog op liveness problemen).

Maar geef je nog het antwoord op wat er fout kan gaan met dat stukje code?

[Alarmnummer]

.oisyn schreef op maandag 03 september 2007 @ 11:19:
[...]

Maar geef je nog het antwoord op wat er fout kan gaan met dat stukje code?

Ik had gehoopt dat onze 'expert' het had willen doen. Maar je gaf het antwoord meteen al in het begin: het voorbeeld is erg deadlock gevoelig.

Als je voor signal op de conditievariable ook dezelfde 2 locks nodig bent, dan heb je een leuk deadlock scenario.

[MNeMoNiCS]

flowerp schreef op maandag 03 september 2007 @ 00:27:
[...]

Ik hoop dat je inziet dat jouw eerdere vraag stelling lichtelijk 'ongeïnformeerd' was, om het voorzichtig uit te drukken.

Je kan een vraag uit onwetendheid stellen, maar ook om mensen aan het denken te zetten of een discussie op gang te brengen...

Want hiervoor ging het ineens over uitgebreid over schedulers, ten eerste is dat een heel andere discussie en ten tweede blijkt wel weer dan mensen zoveel verschillende wensen hebben dat een implementatie nooit voor iedereen kan voldoen.

[MNeMoNiCS]

Alarmnummer schreef op maandag 03 september 2007 @ 09:06:
[...]
Het punt dat gemaakt wordt ontgaat je. Gezien jouw kennis en ervaring moet het voor jou geen enkel probleem zijn om het concurrency probleem uit te kunnen leggen. Waag eens een poging zou ik zeggen.

het feit dat jij concurrency problematisch schijnt te vinden lijkt me iets te vertellen over je begrip van deze materie.

Als dat gelukt is, dan zou je misschien kunnen uitleggen waarom dit effect een van de meest gebruikte oo technieken (compositie) zo gevaarlijk maakt binnen concurrency control (met het oog op liveness problemen).

Ik denk dat je genoeg hints hebt gekregen.

Geachte heer, een methode body met daarin enkele synchronisatie primitieven is een onvolledig voorbeeld. Om een deadlock te krijgen heb je minimaal 2 processen/threads nodig. Vertel me eerst maar eens welke processen welke code parallel uitvoeren.

[MNeMoNiCS]

Olaf van der Spek schreef op maandag 03 september 2007 @ 09:33:
[...]

Een parallelle berekening (of beter SIMD) is als je een bepaalde berekening op meerdere inputs tegelijk toepast.
Bijvoorbeeld het optellen van twee vectors.
De compilatie van een enkel bestand is waarschijnlijk lastig te parallelliseren, maar meerdere bestanden tegelijk compileren op meerdere kernen is eenvoudig te doen.

Data parallellisme, door jou aangeduid is slechts één type van parallelle berekening. Ik probeerde degene die erop deze term gebruikte erop te wijzen dat er veel meer soorten parallellisme zijn.

Meerdere bestanden tegelijk compileren is ook een vorm van data parallellisme. Het feit dat je de compilate van een enkel bestand als eenheid van je berekening kiest wil niet zeggen dat dit de enige mogelijkheid is. Compileren zou je ook als een pipeline berekening kunnen implementeren waarbij bijvoorbeeld aparte threads zorgen voor het scannen, parsen, boom optimaliseren en code genereren.

[MNeMoNiCS]

.oisyn schreef op maandag 03 september 2007 @ 11:15:
Na het mooie verhaal van flowerp heb ik eigenlijk nog maar 1 ding toe te voegen: in een thread doe je willekeurige operaties (vergelijkingen, berekeningen, API functies aanroepen, etc.), en met SSE doe je identieke operaties, waarbij het soort operaties ook nog eens gelimiteerd is (wiskundige berekeningen op floats en/of ints). Om terug te gaan naar mijn raytracer-voorbeeld, daar is de berekening die je voor elke pixel moet doen hetzelfde - de variabelen zijn alleen anders. Zodra je echter in de ene parallelle taak bijvoorbeeld moet optellen, en in de andere parallelle taak een vergelijking moet doen, dan kan SSE je daarbij niet helpen, omdat de operaties (optellen, vermenigvuldigen, etc) op alle componenten hetzelfde moeten zijn.

Ik probeerde je te laten inzien dat jouw definitie van "parallelle berekening" alleen data parallellisme lijkt te bevatten...

Je blaast wel erg hoog van de toren voor iemand die het blijkbaar nog niet helemaal begrepen heeft.

Dat lijkt inderdaad de algemeen geldende mening hier te zijn, ik zou bijna aan mezelf gaan twijfelen...

[MNeMoNiCS]

Alarmnummer schreef op woensdag 05 september 2007 @ 07:42:
[...]

Ik had gehoopt dat onze 'expert' het had willen doen. Maar je gaf het antwoord meteen al in het begin: het voorbeeld is erg deadlock gevoelig.

Als je voor signal op de conditievariable ook dezelfde 2 locks nodig bent, dan heb je een leuk deadlock scenario.

Zoals eerder gezegd, je voorbeeld is onvolledig. Benoem eerst maar eens de exacte processen.

En Alarmnummer, als jij nou ook een expert op het gebied van parallellisme wil worden, stop er dan eerst eens mee om operationeel te denken over parallelle processen, want jij kan nooit alle mogelijke executie traces/interleaving nalopen, tenzij het heel eenvoudige processen betreft maar dan betwijfel ik wat je als expert waard bent.

[ Voor 25% gewijzigd door MNeMoNiCS op 06-09-2007 00:04 ]

[Olaf van der Spek]

MNeMoNiCS schreef op woensdag 05 september 2007 @ 23:45:
Meerdere bestanden tegelijk compileren is ook een vorm van data parallellisme. Het feit dat je de compilate van een enkel bestand als eenheid van je berekening kiest wil niet zeggen dat dit de enige mogelijkheid is. Compileren zou je ook als een pipeline berekening kunnen implementeren waarbij bijvoorbeeld aparte threads zorgen voor het scannen, parsen, boom optimaliseren en code genereren.

Dat zou kunnen, maar levert volgens mij geen enkel voordeel op.

[MNeMoNiCS]

Olaf van der Spek schreef op donderdag 06 september 2007 @ 00:02:
[...]

Dat zou kunnen, maar levert volgens mij geen enkel voordeel op.

Om maar eens een voorbeeld te noemen: load balancing.

[Olaf van der Spek]

MNeMoNiCS schreef op donderdag 06 september 2007 @ 00:05:
Om maar eens een voorbeeld te noemen: load balancing.

Ik volg je niet. Load balancing van wat?

[MBV]

MNeMoNiCS schreef op donderdag 06 september 2007 @ 00:05:
[...]


Om maar eens een voorbeeld te noemen: load balancing.

Zou je eens willen beginnen met minder posts direct achter elkaar te zetten? Op GoT schijnt het gebruikelijk te zijn om 3 berichten na elkaar in 1 bericht te stoppen

En Load balancing? Dat is toch dat je een multi-threaded proces (bijv IIS of Apache) over meerdere PC's verdeelt? Dat heeft hier absoluut niks mee te maken, dus misschien denk ik in de verkeerde richting.

[ Voor 23% gewijzigd door MBV op 06-09-2007 00:58 ]

[.oisyn]

MNeMoNiCS schreef op woensdag 05 september 2007 @ 23:47:

Ik probeerde je te laten inzien dat jouw definitie van "parallelle berekening" alleen data parallellisme lijkt te bevatten...

Ik heb je reactie nu 3x doorgelezen maar ik kan maar niet een punt ontdekken dat je nou eigenlijk wilt maken. Het kan aan mij liggen, dus wellicht kun je het een en ander verduidelijken:

Je vraagt: als je multicore zo onontkoombaar vindt, heb je dan ook gebruik gemaakt van MMX en SSE (waarbij je de vraag stelt alsof je een "nee" verwacht)
Ik zeg: ja, maar SSE biedt slechts een kleine subset van mogelijke parallellisatie
Jij zegt: als je niets hebt aan SSE, heb je dan wel wat aan meerdere kernen?

Dus tenzij je me gewoon wilt overhoren als een docent op school, wat wil je dan in hemelsnaam met die laatste vraag? De enige conclusie die ik eruit kan trekken is dat je zelf niet snapt hoe SSE werkt (hence mijn reactie). Nee, met SSE kun je idd geen task parallellisatie doen, no shit. Sterker nog, SIMD is geeft slechts een subset van data parallellisatie, wat het hele punt was van mijn eerste reactie. Maar goed, ik krijg inmiddels de indruk dat je dat zelf ook wel snapt.

Misschien is het handig om in het vervolg gewoon meteen to the point te komen ipv met allerlei vragen hopen iemand in een bepaald hoekje te krijgen. Dat scheelt een hoop onduidelijkheid
(zeker als je maar eens in de x dagen reageert). Je kan dan wel een discussie op gang willen brengen, maar je kan nou niet bepaald zeggen dat het nu zo lekker loopt

Dat lijkt inderdaad de algemeen geldende mening hier te zijn, ik zou bijna aan mezelf gaan twijfelen...

Ach als jij maar in jezelf gelooft...

[ Voor 15% gewijzigd door .oisyn op 06-09-2007 11:01 ]

[Alarmnummer]

MNeMoNiCS schreef op woensdag 05 september 2007 @ 23:40:
[...]
het feit dat jij concurrency problematisch schijnt te vinden lijkt me iets te vertellen over je begrip van deze materie.

Dat zal het zijn. Misschien kun je me nog redden van mijn onwetendheid, wijze meester en kan ik ooit in je voetsporen treden...

Geachte heer, een methode body met daarin enkele synchronisatie primitieven is een onvolledig voorbeeld. Om een deadlock te krijgen heb je minimaal 2 processen/threads nodig.

in principe 1 is ook voldoende maar dat terzijde.

Vertel me eerst maar eens welke processen welke code parallel uitvoeren.

Tja.. andere dompies zoals .oisyn zagen het direct omdat ze de materie erachter begrijpen. Als jij het had begrepen dan het je het ook gezien.

code:

class Foo{
     final Object a = new Object();
     final Object b = new Object();

     void foo()throws InterruptedException{
         synchronized(a){
            synchronized(b){b.wait();}
         } 
    }

    void bar(){
      synchronized(a){
           synchronized(b){b.notify();}
      }
    }
}

methode foo en bar worden door verschillende threads aangeroepen.

En aub niet direct klagen over het feit dat je het niet zo moet toe passen. Maar probeer
1) te kijken waardoor het probleem op technisch niveau optreed
2) te kijken wat voor consequenties het heeft voor oo design en concurrency, maw mag je zo maar ergens gaan waiten als je niet weet wat er verder allemaal gelocked is? (nu is het je wel heel makkelijk gemaakt)

[ Voor 51% gewijzigd door Alarmnummer op 06-09-2007 08:46 ]

[Alarmnummer]

MNeMoNiCS schreef op woensdag 05 september 2007 @ 23:40:
het feit dat jij concurrency problematisch schijnt te vinden lijkt me iets te vertellen over je begrip van deze materie.

Het feit dat jij niet weet hoe complex het kan zijn, zegt denk ik eerder iets over jou kennis en ervaring.

[ Voor 5% gewijzigd door Alarmnummer op 06-09-2007 08:47 ]

[PrisonerOfPain]

.oisyn schreef op vrijdag 31 augustus 2007 @ 11:14:
We hebben zelf een math library met vector en matrix classes ontwikkeld die gewoon direct naar inline SIMD assembly code compileert voor alle major platforms (PC, Xbox, Xbox360, PS2, PS3, GC, Wii).

SIMD (of SSE in dit geval) werkt een heel stuk beter als je het over de gehele linie doorvoert. Een Matrix/Vector class levert amper performance winst op in vergelijking tot wat haalbaar (ongeveer vier maal zo snel). Ik heb het al eerder gepost, maar de huidige compiler optimalisaties trekken dat nog lang niet terwijl het process handmatig niet zo heel lastig is (maar wel rommelig kan worden door alle intrinsics in je source-code).

[ Voor 4% gewijzigd door PrisonerOfPain op 06-09-2007 08:11 ]

[Alarmnummer]

Olaf van der Spek schreef op donderdag 06 september 2007 @ 00:02:
[...]

Dat zou kunnen, maar levert volgens mij geen enkel voordeel op.

Pipelined parallellisme is een vorm van algoritmische parallellisme en met
a) een core kun je er voor zorgen dat je resources beter gebruikt worden. Je krijgt dan niet sequentieel burst van io en dan cpu, maar de bursts blijft aanhouden totdat een van de resources helemaal verzadigd is.
b) meerdere cores kun je ook meerdere gebruiken (handig als je probleem cpu bound is).

Pipes and Filters is wel een van de meest bekende architectural patterns die een pipeline als basis heeft.

[ Voor 14% gewijzigd door Alarmnummer op 06-09-2007 11:34 ]

[.oisyn]

PrisonerOfPain schreef op donderdag 06 september 2007 @ 08:10:

SIMD (of SSE in dit geval) werkt een heel stuk beter als je het over de gehele linie doorvoert. Een Matrix/Vector class levert amper performance winst op in vergelijking tot wat haalbaar (ongeveer vier maal zo snel). Ik heb het al eerder gepost, maar de huidige compiler optimalisaties trekken dat nog lang niet terwijl het process handmatig niet zo heel lastig is (maar wel rommelig kan worden door alle intrinsics in je source-code).

Nee, die intrinsics heb je dus niet nodig als je gewoon een fatsoenlijke vector class hebt die die intrinsics implementeert. En natuurlijk is het aan de programmeur om dat ding dan ook daadwerkelijk te gebruiken. Dus als hij 4 floats met iets wil vermenigvuldigen, dan kan hij dat het beste met een vector doen (nou ok, dat is een beetje te kort door de bocht, maar you get the point).

[ Voor 15% gewijzigd door .oisyn op 06-09-2007 11:02 ]

[Olaf van der Spek]

Alarmnummer schreef op donderdag 06 september 2007 @ 08:54:
Pipelined parallellisme is een vorm van algoritmische parallellisme en met
a) een core kun je er voor zorgen dat je resources beter gebruikt worden. Je krijgt dan niet sequentieel burst van io en dan cpu, maar de bursts blijft aanhouden totdat een van de resources helemaal verzadigd is.
b) meerdere cores kun je ook meerdere gebruiken (handig als je probleem cpu bound is).

Pipes and Filters is wel een van de meest bekende architectural patterns die een pipeline als basis heeft.

Maar in het geval van compilatie lijkt het me erg veel complexer zonder dat het extra voordeel oplevert, aangezien je ook gewoon meerdere compilaties naast elkaar kunt draaien.

[flowerp]

Olaf van der Spek schreef op donderdag 06 september 2007 @ 15:27:
[...]
Maar in het geval van compilatie lijkt het me erg veel complexer zonder dat het extra voordeel oplevert, aangezien je ook gewoon meerdere compilaties naast elkaar kunt draaien.

Inderdaad Een pipeline (een constrained pipe & filter graph) is overigens zeker wel een mooi concept om parallellisatie te implementeren. Bij compileren plaats ik wil mijn vraagtekens of dit inderdaad het meest effectief is. Een pipeline is namelijk handig bij data streams waarbij de bewerking per 'item' dermate complex zijn dat ze opgedeeld kunnen worden, maar waarbij de items eigenlijk niet los (onafhankelijk) van elkaar geprocessed kunnen worden. In hardware implementaties haal je dan nog voordelen eruit dat elke processing stap (filter) heel gespecialiseerd uitgevoerd kan worden (hoeft alleen die hardware te bevatten die nodig is voor die stap).

Pipelines hebben ook nadelen. De stappen moeten gebalanceerd zijn, en als 1 stap om wat voor reden dan ook er wat langer over doet, kun je een pipeline stall krijgen.

Bij het compileren van veel talen zijn veel van je afzonderlijke items (de compilation units) echter onafhankelijk. Je kunt dan net zo goed de items in zijn geheel onafhankelijk en parallel processen. D.w.z. in Java bijvoorbeeld 1 class in z'n geheel per core compileren.

Dat laatste heeft bovendien als potentieel voordeel dat alle tussen producten van het compilatie process (token, symbol table, syntax tree, intermediate code, etc) niet telkens van de cache van de ene core naar de cache van de andere core verhuist hoeven te worden. Aan de andere kant, als de compiler code zelf niet in zijn geheel in de cache van een core past, zal deze wel telkens moeten wisselen als de core een andere stap gaat doen in het compilatie proces.

[Alarmnummer]

flowerp schreef op donderdag 06 september 2007 @ 20:43:
[...]
Dat laatste heeft bovendien als potentieel voordeel dat alle tussen producten van het compilatie process (token, symbol table, syntax tree, intermediate code, etc) niet telkens van de cache van de ene core naar de cache van de andere core verhuist hoeven te worden. Aan de andere kant, als de compiler code zelf niet in zijn geheel in de cache van een core past, zal deze wel telkens moeten wisselen als de core een andere stap gaat doen in het compilatie proces.

Door allerlei caching technieken zoals write through caches (dus cache wijziging meteen doorsturen over de bus naar main memory) en sniffing caches (cache wijzigingen in main memory weer naar zich toe trekt, door te luisteren naar de bus) hoeven caches minder out of sync te raken dan je zou denken.

Maar ik ben het verder met je eens. Hoe hoger op je in het verhaal kunt parallelliseren, hoe eenvoudiger het parallelliseren meestal is.

Pipelines hebben ook nadelen. De stappen moeten gebalanceerd zijn, en als 1 stap om wat voor reden dan ook er wat langer over doet, kun je een pipeline stall krijgen.

Op het moment dat volgordelijkheid tussen items minder belangrijk is, kun je er voor kiezen om een stap weer parallel uit te laten voeren:
1) meerdere items van dezelfde stap parallel schakelen (verhogen aantal threads voor de stap)
2) de stap zelf weer parallelliseren (fork/join bv)

[ Voor 30% gewijzigd door Alarmnummer op 07-09-2007 09:40 ]

[Olaf van der Spek]

Alarmnummer schreef op vrijdag 07 september 2007 @ 09:31:
Door allerlei caching technieken zoals write through caches (dus cache wijziging meteen doorsturen over de bus naar main memory) en sniffing caches (cache wijzigingen in main memory weer naar zich toe trekt, door te luisteren naar de bus) hoeven caches minder out of sync te raken dan je zou denken.

Vergeet ook shared caches niet.

[LauPro]

Voor de liefhebbers van CFS. Er is inmoddels een "Completely Unfair Scheduler" uitgebracht waarmee je applicaties harde voorrang kan geven. Bijvoorbeeld dat een game nooit gestoord mag worden door andere processen. Dit is in mijn ogen een hele grote vooruitgang. Het is alleen nog even een PITA om system wide zo'n policy aan te leggen voor al je applicaties (een fancy GUI is wel handig). Maar ik hoop dat KDE ergens de bal op pakt.

http://kerneltrap.org/Lin...pletely_Unfair_Scheduling

[MBV]

Sorry, geen tijd om veel tekst te lezen, maar hoe gaat die scheduler om met applicaties die ergens op aan het wachten zijn, bestandje ofzo? Dat is het probleem met schedulers: je krijgt er nog wel eens priority inversion door, of dat een spel aan het busy-waiten is op een netwerkverbinding, die nou juist door een andere applicatie wordt hersteld. Heeft die scheduler iets van PIP of PCP ofzo?

[LauPro]

Ik heb zelf de source niet gechecked. Maar wat ik kan afleiden is dat het systeem in principe 'resource wide' werkt. Dus er wordt ook gekeken (in deze scheduler) naar I/O prioriteit.

Daarnaast zul je in zo'n policy moeten vastleggen dat een dhcpcd natuurlijk op een hoger niveau dan de game staat, maar dit zijn geen processen die heel zwaar zijn. Het gaat met name om file-serving deamons e.d..

[Olaf van der Spek]

LauPro schreef op vrijdag 07 september 2007 @ 22:13:
Ik heb zelf de source niet gechecked. Maar wat ik kan afleiden is dat het systeem in principe 'resource wide' werkt. Dus er wordt ook gekeken (in deze scheduler) naar I/O prioriteit.

Daarnaast zul je in zo'n policy moeten vastleggen dat een dhcpcd natuurlijk op een hoger niveau dan de game staat, maar dit zijn geen processen die heel zwaar zijn. Het gaat met name om file-serving deamons e.d..

Dus gewoon file transfers op een lagere prioriteit zetten?

[LauPro]

Dat denk ik niet, kan ook gelden voor cron jobs, koetjes, compilaties op de achtergrond.

[H!GHGuY]

een collega van me wees me op een artikel in Dr.Dobb's over rapidmind.

Het framework laat toe om in C++ parallellisme uit te drukken.

De voorbeeldjes die ik heb gezien lijken me echter nogal omslachtig.
Anderzijds kan het framework niet enkel van multicore processoren gebruik maken, maar ook van GPU's en de Cell processor.

[misfire]

Gebruikt hier al iemand tools voor het analyseren van multi-core applicaties? Mijn ervaring met klassieke profilers/tracers is dat ze de waarneming te veel beïnvloeden omdat ze zelf allerlei synchronisatie en overhead toevoegen. De mogelijkheid om te analyseren hoe goed de applicatie gebruik maakt van meerdere cores lijkt mij minstens zo belangrijk als het ontwerpen/programmeren.

De tools die ik ken:

* DTrace kan op verschillende niveaus allerlei multicore gedrag monitoren met minimale side-effects. DTrace is helaas alleen beschikbaar op Solaris, binnenkort ook op OS X.
* Azul heeft hardware-ondersteuning voor diagnose van threading gedrag. Dit schijnt echt helemaal de bom te zijn. Voor een grote organisatie kan het alleen om deze reden al interessant zijn om een Azul doosje te kopen.
* Lock Analyzer ziet er ook interessant uit, maar dit is zo nieuw dat ik hier nog niet mee heb kunnen hobbyen.

Nog andere tools die de moeite waard zijn?

[flowerp]

misfire schreef op woensdag 12 september 2007 @ 23:07:
Lock Analyzer ziet er ook interessant uit, maar dit is zo nieuw dat ik hier nog niet mee heb kunnen hobbyen.

Deze ziet er inderdaad zeer interessant uit en is voornamelijk handig als je veel fine-grained parallellisme toepast. Wel is het erg jammer dat deze alleen te gebruiken is in combinatie met de IBM jre.

[flowerp]

Op een haar na is het nu precies 2 jaar geleden sinds de start van deze thread, dus misschien leuk voor een kleine update van de huidige situatie.

Wat is er in de tussentijd veranderd? Zoals voorspeld is dual core absoluut een standaard item geworden. Je moet nu moeite doen om nog een single core te vinden. Van laptop, tot aan desktop en server, alles is nu tenminste dual-core.

Daarnaast zijn quad-cores ook een absolute commodity geworden, hoewel ze nog steeds niet zo wijdverspreid zijn als de dual cores. Een zeer snelle quad-core kost momenteel bij een computer winkel om de hoek (b.v. Mycom) slechts zo'n 179,- (zie http://www.mycom.nl/Products/654.aspx?View=0). Het is bovendien bij deze winkel ook de best verkochte CPU:

code:

MyCom TOP 5 Processoren
1 Intel Core 2 Q6600 €179,95
2 Intel Core 2 Duo E7300 €124,95
3 AMD Athlon 64 X2 5200+ €73,95
4 Intel Core 2 Duo E8500 €199,95
5 Intel Core 2 Duo E8400 €169,95

Tevens geeft deze shop een makkelijk overzicht van hun aanbod, hier een overzicht van de CPUs die ze aanbieden per aantal cores:

code:

Aantal cores
1x 3
2x 16
3x 2
4x 8
(totaal 34 cpus)

Omdat MyCom typisch een winkel is die het huis-tuin en keuken publiek bedient, is dit denk ik wel een goede indicator voor de (nl) markt.

Tegelijkertijd zijn ook onlangs de Nehalem CPUs van intel aangekondigd, wat een geheel nieuwe generatie betreft. Ook nu is er weer geen sprake van een significante verhoging van de clock speeds. De stelling van sommige tweakers destijds dat multi-core een tijdelijke hype is en dat intel op korte termijn de clock snelheid weer omhoog gaat gooien, is dus nog steeds geen waarheid gebleken. In ieder geval de komende 2 generaties (zo'n +- 2 ~ 3 jaar) gaan ze nog steeds niet naar de 5 tot 10Ghz schalen.

Wel zal quad core zich dus nog meer gaan doorzetten en zullen er binnenkort ook hex cores komen. Oct core systemen zijn voor het grote publiek nog onbekend, maar voor zo'n 2000,- kan een pro gebruiker zich al een workstation aanschaffen met een dual quad core. Hoewel 2000,- veel geld is, is het voor veel pro gebruikers wel op te brengen zodat er daadwerkelijk al een handjevol mensen is die anno 2008 een oct core systeem hebben (het is tevens de default config van de 2400,- kostende Mac Pro).

Aan de development kant zie ik echter nog steeds niet heel erg veel programmeurs echt inhaken op parellel ontwikkelen. Men blijft denken "Multithreaded programmeren is (te) moeilijk", ondanks dat er steeds meer high-level dingen in libraries komen (b.v. de concurrency package vanaf Java 5) om het stukken makkelijker te maken.

Vanaf de library/platform kant zit er wel degelijk verdere ontwikkeling in. Een bekend platform wat traditioneel concurrency per user juist tegenwerkte (Java EE) begint nu langzaam ook toe te geven (zie b.v. http://gee.cs.oswego.edu/...ncyee-interest/index.html en http://jcp.org/en/jsr/detail?id=236).

Tegelijkertijd gaat de standard edition van Java voor de nieuwe versie 7 (verwacht voor 2010) nog een flink stuk verder: http://www.infoq.com/news/2007/07/concurrency-java-se-7 :

Big (32+) multicores will be coming out in volume during the lifetime of Java 7, and having this framework in place will allow people running them to get relatively simple speedups for computation-intensive tasks. Right now, forkjoin works best on machines like Sun Niagaras and Azuls, which are the only current processors of the form that will soon be common. It also works well on standard SMPs. In general, you don't get many speedup benefits with less than 4 processors though -- the main targets are in the dozens to hundreds of processors range.

Hoewel ik het de laatste tijd wat minder volg, begrijp ik dat diverse andere platformen dan Java een vergelijkbare kant op gaan.

De enige die dus nog echt achter lijken te blijven zijn de applicatie programmeurs die het allemaal in de praktijk moeten gaan gebruiken. Ik verwacht dat als quad-core echt de minimale config is geworden voor zowel laptops als desktops en octs nog maar een appel en een ei kosten, dat men er dan -echt- niet meer om heen kan. Het blijft nog even koffie dik kijken wanneer dat gebeurt, maar ik gok op ongeveer nogmaals een jaar of 2.

[LauPro]

flowerp schreef op zondag 09 november 2008 @ 14:56:
Tegelijkertijd zijn ook onlangs de Nehalem CPUs van intel aangekondigd, wat een geheel nieuwe generatie betreft. Ook nu is er weer geen sprake van een significante verhoging van de clock speeds. De stelling van sommige tweakers destijds dat multi-core een tijdelijke hype is en dat intel op korte termijn de clock snelheid weer omhoog gaat gooien, is dus nog steeds geen waarheid gebleken. In ieder geval de komende 2 generaties (zo'n +- 2 ~ 3 jaar) gaan ze nog steeds niet naar de 5 tot 10Ghz schalen.

Sowieso is het nog steeds technisch een hele prestatie om 10Ghz te gaan bereiken en aangezien de energiezuinigheid ook steeds een grotere rol speelt is het ook niet wenselijk om die kant op te gaan met de huidige techniek.

Tevens is er bij een gemiddelde computer al de vraag naar multithreading: het scenario dat ik al eerder schetste, er staat een p2p-applicatie aan, videochat, paar webbrowsers met interactieve flash-applicaties, officepakket etc. Dat is gewoon een omgeving waar een single cpu systeem niet op ingesteld is - of je moet een HELE goede scheduler en manager hebben die nog niet bestaat voor bijv. Windows.

Wel zal quad core zich dus nog meer gaan doorzetten en zullen er binnenkort ook hex cores komen.

Tja hex, oct, dec geef met maar een verwaande term. Over 10 jaar hebben 32-core processoren mainstream en 8-core mobile devices etc.

Aan de development kant zie ik echter nog steeds niet heel erg veel programmeurs echt inhaken op parellel ontwikkelen. Men blijft denken "Multithreaded programmeren is (te) moeilijk", ondanks dat er steeds meer high-level dingen in libraries komen (b.v. de concurrency package vanaf Java 5) om het stukken makkelijker te maken.

Het is moeilijk om te bevatten; het heeft imo namelijk geen nut om dit op applicatieniveau te regelen, dit blijft een taak van de libraries/platform. Je moet niet op applicatieniveau allemaal schedulers willen moeten bouwen voor MT. Tevens blijft het in veel softwarehuizen een financiële afweging. Het is vaak goedkoper om een hardwareupgrade te doen dan een rewrite naar een MT-applicatie (voor zover het - nogmaals - nut heeft). Bovendien zijn veel softwarehuizen afhankelijk van 3rd party bedrijven als Microsoft en MySQL waardoor er helemaal geen nut heeft om de applicatie verder te optimaliseren als het platform singlecore blijft. Wat wil je precies, dat allemaal multithreaded applicaties staan te wachten op 1 single threaded proces?

De enige die dus nog echt achter lijken te blijven zijn de applicatie programmeurs die het allemaal in de praktijk moeten gaan gebruiken.

Ik vind dit werkelijk een sneer die helemaal nergens voor nodig is, het is niet aan de 'applicatie programmeurs' om te bepalen of een applicatie multithreaded moet worden, dat is aan de software architecten en vooral het financiële budget dat beschikbaar is. Los van de wenselijkheid van het parallelliseren van software is dat in heel veel gevallen een platformkwestie. Je moet juist deze vraag neerleggen bij toolkit-/platformontwikkelaars als .Net, Java, QT, GTK - waarvan vooral de laatste bijvoorbeeld alleen wat work-a-rounds heeft geïntroduceerd voor de ondersteuning van threads. Pak die eens aan in je betoog en dwing niet de codekloppers tot work-a-rounds zolang er geen fatsoenlijke interfaces e.d. beschikbaar zijn.

Het blijft nog even koffie dik kijken wanneer dat gebeurt, maar ik gok op ongeveer nogmaals een jaar of 2.

Mijn inschatting is dat er onder het gros van de huidige applicaties (Financial, CRM, CMS etc) verdomd weinig zal gebeuren. Microsoft heeft bijvoorbeeld aangegeven dat ze veel naar webservice based applicaties willen (Office Live! o.a.). Dit geeft al een totaal ander systeemmodel dan de klassieke fat client. Ik denk eerlijk gezegd dat de komende jaren het toenemende aantal cores gewoon puur de gebruikersbeleving gaat verbeteren en niets meer dan dat. Dit past prima binnen het huidige model zoals een gemiddelde desktop is opgebouwd en daar zijn absoluut geen drastische hervormingen van applicatiesoftware voor nodig zoals in dit topic wordt gesuggereerd. Nu niet en de komende 10 jaar niet.

[MBV]

@LauPro: misschien heb je gelijk. Dat zou betekenen dat er voor eindgebruikers geen motief meer komt om te gaan upgraden: waar nu voor veel mensen de P4 3GHz processor snel zat is, heeft een upgrade vanaf een Core2Duo dus geen enkel nut meer, omdat de programmeurs er geen tijd in stoppen. Erg jammer voor de hardwareindustrie, en voor de consumenten: die zullen gewoon moeten blijven wachten, ongeacht het aantal cores.

Toolkit-schrijvers zijn er kennelijk ook niet in geinteresseerd: als hun gebruikers (dus applicatie-ontwikkelaars) er niet om vragen, gaan zij het niet schrijven. Misschien komt er binnen afzienbare tijd (bijv. een jaar na de introductie van Nehalem) een toolkit gebaseerd op (GPL dus) Qt o.i.d., die wél eenvoudige multithreading mogelijk maakt.

Schedulers in je applicatie lijkt mij (theoretisch gezien) niet nodig: je deelt je applicatie op in kleine taakjes (elk een thread), en je OS scheduled die threads. Helaas is de scheduler van Windows niet echt geweldig, dus zal je dat waarschijnlijk alsnog binnen je eigen applicatie of de VM moeten doen.

Ik heb trouwens ook ooit iets gehoord van een COBOL/Fortran variant toegespitst op multithreaded programmeren. Hoe is dat afgelopen?

[ Voor 6% gewijzigd door MBV op 10-11-2008 10:06 ]

[.oisyn]

LauPro schreef op maandag 10 november 2008 @ 03:18:
Het is moeilijk om te bevatten; het heeft imo namelijk geen nut om dit op applicatieniveau te regelen, dit blijft een taak van de libraries/platform.

Compleet niet mee eens. Als je denkt multicore programming iets is wat wel voor je gedaan kan worden (of dat nou door een library of door de compiler gebeurt) ipv dat je het zelf moet doen heb je totaal geen verstand van wat multicore programming nou precies inhoudt. Natuurlijk zullen libraries en compilers je helpen, maar om daar zinnig gebruik van te maken moeten applicaties echt op een compleet andere manier opgezet worden dan momenteel het geval is. En natuurlijk zal het voor veel van de kleinere applicaties niet echt boeien hoeveel cores er nou gebruikt worden, maar daar hebben we het hier niet over.

Bovendien zijn veel softwarehuizen afhankelijk van 3rd party bedrijven als Microsoft en MySQL waardoor er helemaal geen nut heeft om de applicatie verder te optimaliseren als het platform singlecore blijft. Wat wil je precies, dat allemaal multithreaded applicaties staan te wachten op 1 single threaded proces?

Commence finger-pointing! Zij moeten eerst!

[Confusion]

flowerp schreef op zondag 09 november 2008 @ 14:56:
[..]

Ik voel eigenlijk zelden de noodzaak tot expliciete multithreading. Ik heb nog nooit een applicatie multithreading gemaakt omdat ik uit performance overwegingen voor 1 gebruiker zijn load over meerdere cores wilde spreiden. De enige reden om applicaties multithreading te maken was om asynchrone communicatie met andere systemen mogelijk te maken, om de responsiviteit te verhogen.

Je kan je cores toch prima benutten door gebruikers parallel af te handelen?

[MBV]

.oisyn schreef op maandag 10 november 2008 @ 11:34:
[...]

Commence finger-pointing! Zij moeten eerst!

Sterker nog: zij zijn eerst. MySQL schaalt best aardig tot iets van 8 cores, MSSQL vast nog veel beter, en PostgreSQL heeft al helemaal geen moeite met veel cores. De DB kan vaak prima schalen over meerdere cores. Ik had eigenlijk begrepen dat hij bedoelde dat het zware werk daar wordt gedaan, dus dat het niet uitmaakt of je zelf multi-threaded werkt.
Zie ook:
MySQL concurrency
postgre concurrency
Volgens mij nog steeds de beste vergelijking tussen MySQL en Postgre die ik tot nu toe ben tegengekomen

Confusion schreef op maandag 10 november 2008 @ 12:51:
[...]

Ik voel eigenlijk zelden de noodzaak tot expliciete multithreading. Ik heb nog nooit een applicatie multithreading gemaakt omdat ik uit performance overwegingen voor 1 gebruiker zijn load over meerdere cores wilde spreiden. De enige reden om applicaties multithreading te maken was om asynchrone communicatie met andere systemen mogelijk te maken, om de responsiviteit te verhogen.

Je kan je cores toch prima benutten door gebruikers parallel af te handelen?

Dan moet je even terugzoeken in dit thread. Ik geloof dat flowerp het probleem had dat het systeem weliswaar optimaal benut werd met 8 gebruikers (als er 8 cores waren), maar dat effectief maar 2 cores werden gebruikt o.i.d. omdat de zware taken maar zelden werden uitgevoerd. Dan zat iemand dus minuten te wachten op resultaat, terwijl er 7 cores iets uit hun neus haalden

[ Voor 11% gewijzigd door MBV op 10-11-2008 13:10 ]

[Exirion]

LauPro schreef op maandag 10 november 2008 @ 03:18:
Het is moeilijk om te bevatten; het heeft imo namelijk geen nut om dit op applicatieniveau te regelen, dit blijft een taak van de libraries/platform.

Zoals iemand hierboven al zei: dit is echt onzin en je snapt dan niet precies waar het over gaat. Automatiseren van optimalisaties is alleen mogelijk op microniveau. Een compiler kan vaak bepalen hoe bepaalde bewerkingen of hoogstens een statement/loopje te optimaliseren valt. Een compiler kan echter niet de intelligentie van een ontwikkelaar vervangen die op een hoger niveau de grote lijnen van een algoritme en de structurering van de data optimaliseert.

[MBV]

Toch heeft hij wel een punt: veel libraries maken het nou niet bepaald makkelijk om multithreaded te werken. Als er support komt in de vorm van speciale talen voor multithreading (waarbij je eenvoudig kan aangeven dat een loopje 'unrolled' mag worden naar meerdere threads, dat soort werk) of libraries met hetzelfde effect, dan zal het meer gebruikt worden dan wanneer je handmatig forks zou moeten maken.

[.oisyn]

Waarom zouden die libraries het makkelijk maken als applicaties toch singlethreaded blijven? Waarom moeten zij eerst om? Laat die applicaties eerst eens fatsoenlijk hun datastructuren en logica zo rangschikken dat het goed te multithreaden valt. Commence finger pointing! Zij moeten eerst!

(Dit nog even naast het feit dat er allang dergelijke tools en libraries bestaan, maar dat willen de meeste mensen niet weten omdat dat betekent dat ze hun code ineens op een heel andere manier moeten gaan schrijven, en dat willen ze helemaal niet)

[Confusion]

MBV schreef op maandag 10 november 2008 @ 13:06:
Dan moet je even terugzoeken in dit thread. Ik geloof dat flowerp het probleem had dat het systeem weliswaar optimaal benut werd met 8 gebruikers (als er 8 cores waren), maar dat effectief maar 2 cores werden gebruikt o.i.d. omdat de zware taken maar zelden werden uitgevoerd. Dan zat iemand dus minuten te wachten op resultaat, terwijl er 7 cores iets uit hun neus haalden

Als er een extreem zware taak is die voor piekbelasting zorgt en daarmee anderen wachttijd bezorgd, dan is dat natuurlijk bij een uitstek een moment om die taak te parallelliseren. Maar ik ben dat soort taken nog niet tegengekomen en als ze gewoon niet veel voorkomen, dan is er geen enkele reden om John Programmer multithreaded te leren programmeren. Dat kunnen we dan prima blijven overlaten aan de mensen die het wel kunnen behapstukken.

[MBV]

@Confusion: ik snap best dat niet elk php-scriptje nu multithreaded moet, het maakt veel te vaak niet uit. Maar er waren vandaag een paar mensen die zeiden dat het nergens voor nodig is, en die mensen slaan de plank IMHO volledig mis.

@.oisyn: welke? Uiteraard zal elke toolkit zeggen dat ze extreem geschikt zijn, maar ik ben wel benieuwd over welke toolkits jij het nu hebt

[.oisyn]

To name a few: OpenMP, de Intel compiler suite (die kan loops automatisch parallelliseren), de Intel thread building blocks libraries, en dan zijn er nog HPC libraries als RapidMind, en al die andere dingen waar ik ooit eens over gelezen heb maar waarvan ik de naam niet meer weet. Google maar. M'n punt is dat parallelle software een andere code opzet vereist waarvoor je heel andere denkpatronen moet gebruiken dan de standaard sequentiele die de meeste mensen momenteel gebruiken.

[Janoz]

LauPro schreef op maandag 10 november 2008 @ 03:18:
Het is moeilijk om te bevatten; het heeft imo namelijk geen nut om dit op applicatieniveau te regelen, dit blijft een taak van de libraries/platform.

Misschien ten overvloede aangezien het hierboven al meerdere keren aangehaald is, maar ook ik vind dat je hier fundamenteel de mist in gaat. Een library of platform is niet iets dat op magische wijze je proces omzet naar meerdere parallel lopende deel processen. Het enige dat een library kan doen is je juist beperken in je mogelijkheden wanneer ze bijvoorbeeld niet thread save zijn.

Je moet niet op applicatieniveau allemaal schedulers willen moeten bouwen voor MT.

Je proces paralleliseerbaar maken is iets anders dan schedulers schrijven. Paralleliseerbaar maken is je hoofd proces zo opdelen in brokken dat deze onafhankelijk van elkaar uitgevoerd kunnen worden. Pas daarna kan tooling het voor je overnemen.

Tevens blijft het in veel softwarehuizen een financiële afweging. Het is vaak goedkoper om een hardwareupgrade te doen dan een rewrite naar een MT-applicatie (voor zover het - nogmaals - nut heeft).

Dit gaat ze dus niet meer helpen. Zoals in de kick van flowerp al aangegeven werd groeit de hardware niet meer in de hoogte (meer megaherzt, meer instructies per seconde serieel), maar in de breedte (meer cores, meer instructies per seconde parallel). Nieuwe hardware neerzetten zorgt er alleen maar voor dat de applicatie even snel blijft draaien, maar dat er meer cores uit hun neus gaan vreten.

Bovendien zijn veel softwarehuizen afhankelijk van 3rd party bedrijven als Microsoft en MySQL waardoor er helemaal geen nut heeft om de applicatie verder te optimaliseren als het platform singlecore blijft. Wat wil je precies, dat allemaal multithreaded applicaties staan te wachten op 1 single threaded proces?

Je vergelijking backfired. Juist omdat die 3rd party bedrijven al met multithreaded implementaties gekomen zijn is dat signle threaded proces waar iedereen op wacht precies die applicatie waarvan jij het niet nodig vindt dat het aangepast wordt .

Ik vind dit werkelijk een sneer die helemaal nergens voor nodig is, het is niet aan de 'applicatie programmeurs' om te bepalen of een applicatie multithreaded moet worden, dat is aan de software architecten en vooral het financiële budget dat beschikbaar is.

Pertinent niet waar. Het paralleliseerbaar zijn van een applicatie heeft impact op alle niveaus. Het is niet moeilijk, maar er zijn enkele zaken waar rekening mee gehouden moet worden. Dan kunnen de architecten dat wel leuk gaan uitdenken, maar als John the Programmer (zoals eerder aangehaald) een non-threadsave lijst overal gaat lopen aanroepen krijg je alsnog carnage.

Los van de wenselijkheid van het parallelliseren van software is dat in heel veel gevallen een platformkwestie. Je moet juist deze vraag neerleggen bij toolkit-/platformontwikkelaars als .Net, Java, QT, GTK - waarvan vooral de laatste bijvoorbeeld alleen wat work-a-rounds heeft geïntroduceerd voor de ondersteuning van threads. Pak die eens aan in je betoog en dwing niet de codekloppers tot work-a-rounds zolang er geen fatsoenlijke interfaces e.d. beschikbaar zijn.

Mijn inschatting is dat er onder het gros van de huidige applicaties (Financial, CRM, CMS etc) verdomd weinig zal gebeuren. Microsoft heeft bijvoorbeeld aangegeven dat ze veel naar webservice based applicaties willen (Office Live! o.a.). Dit geeft al een totaal ander systeemmodel dan de klassieke fat client. Ik denk eerlijk gezegd dat de komende jaren het toenemende aantal cores gewoon puur de gebruikersbeleving gaat verbeteren en niets meer dan dat. Dit past prima binnen het huidige model zoals een gemiddelde desktop is opgebouwd en daar zijn absoluut geen drastische hervormingen van applicatiesoftware voor nodig zoals in dit topic wordt gesuggereerd. Nu niet en de komende 10 jaar niet.

Qua voorspelling ben ik het helemaal met je eens, maar de conclusie dat MT-programming daarom onzin is, is niet een conclusie die ik zou trekken. De hoeveelheid clientside applicaties zal zeker afnemen, maar het totaal aan applicaties niet. De afname zal ruimschoots gecompenseerd worden met serverside applicaties die via een ASP model aan de gebruikers aangeboden wordt. Deze zullen ook gebouwd moeten worden.

[LauPro]

MBV schreef op maandag 10 november 2008 @ 10:05:
@LauPro: misschien heb je gelijk. Dat zou betekenen dat er voor eindgebruikers geen motief meer komt om te gaan upgraden: waar nu voor veel mensen de P4 3GHz processor snel zat is, heeft een upgrade vanaf een Core2Duo dus geen enkel nut meer, omdat de programmeurs er geen tijd in stoppen. Erg jammer voor de hardwareindustrie, en voor de consumenten: die zullen gewoon moeten blijven wachten, ongeacht het aantal cores.

Het is gewoon pertinent onwaar dat mensen geen snelheidsverschil merken bij een dual core tov single core systeem. Als je een OS zou schrijven waar alles in 1 thread draait (non-smp) dan heb je gelijk, alleen de huidige moderne OS'en zijn nu eenmaal smp en dus is er per definitie een snelheidswinst met multi core systemen vs single core. Verder is het single core concept in de grotere rekencentra al decennia afgeschreven, het is gewoon de initiatiefloosheid van de processorfabrikanten dat er nu pas (afgelopen jaren) multi core processoren op de markt zijn, die hadden 10 jaar geleden al moeten bestaan. Toen moest iedereen namelijk dure 2way systemen kopen met exotische chipsets voor een beetje performance.

Toolkit-schrijvers zijn er kennelijk ook niet in geinteresseerd:

Dan heb je de strekking van op opmerking niet helemaal begrepen, want Java bijvoorbeeld is de afgelopen tijd hard op weg om alle Java software gewoon per definitie threadable te maken en ook veel functies te bieden die de developer ondersteunen. Tevens loopt QT imo erg voorop als het gaat om toolkitintegratie van threads.

Schedulers in je applicatie lijkt mij (theoretisch gezien) niet nodig: je deelt je applicatie op in kleine taakjes (elk een thread), en je OS scheduled die threads. Helaas is de scheduler van Windows niet echt geweldig, dus zal je dat waarschijnlijk alsnog binnen je eigen applicatie of de VM moeten doen.

Je ontkracht jezelf een beetje, je hebt altijd een threadmanager nodig als je een deftige threaded applicatie hebt, ik ben van mening dat dat een taak is van het platform danwel de toolkits.

Ik heb trouwens ook ooit iets gehoord van een COBOL/Fortran variant toegespitst op multithreaded programmeren. Hoe is dat afgelopen?

Ik zou het niet weten en eerlijk gezegd zelf zo'n oude koe lekker laten liggen .

.oisyn schreef op maandag 10 november 2008 @ 11:34:
Compleet niet mee eens. Als je denkt multicore programming iets is wat wel voor je gedaan kan worden (of dat nou door een library of door de compiler gebeurt) ipv dat je het zelf moet doen heb je totaal geen verstand van wat multicore programming nou precies inhoudt.

Dit heb ik nergens gezegd dit is een conclusie die je nu uit lucht trekt.

En natuurlijk zal het voor veel van de kleinere applicaties niet echt boeien hoeveel cores er nou gebruikt worden, maar daar hebben we het hier niet over.

Die 'veel kleinere applicaties' zijn wel 90% van de markt waar de gebruiker mee te maken heeft.

Commence finger-pointing! Zij moeten eerst!

Daar is toch niets mis mee? Hell er zijn zelfs libs die gewoon nog niet threadsafe zijn, wat heeft het dan in godsnaam voor een nut om je applicatie alvast te threaden, het blijft een keten met afhankelijkheden.

Exirion schreef op maandag 10 november 2008 @ 13:32:
Zoals iemand hierboven al zei: dit is echt onzin en je snapt dan niet precies waar het over gaat. Automatiseren van optimalisaties is alleen mogelijk op microniveau. Een compiler kan vaak bepalen hoe bepaalde bewerkingen of hoogstens een statement/loopje te optimaliseren valt.

Ik heb het nergens over het automatiseren van optimalisaties maar wel dat de implementatie van bijvoorbeeld een threadmanager in toolkit/platform hoort te zitten en niet in de applicatie (ja uitzonderingen daargelaten). Als je op deze manier geforceerd expliecite multithreading (zoals Confusion dat zo mooi zegt) gaat invoeren dan voorspel ik een hoop ononderhoudbare code. Het staat buiten kijf dat als je threads wil toepassen in je applicatie de architectuur en de datastructuren in je applicatie wel threadsafe moeten zijn (wat vaak ingrijpende consequenties heeft).

Janoz schreef op maandag 10 november 2008 @ 15:50:Het enige dat een library kan doen is je juist beperken in je mogelijkheden wanneer ze bijvoorbeeld niet thread save zijn.

En dat is nog in veel situaties het geval, het is toch belachelijk dat anno 2008 iets als glibc gewoon nog niet threadsafe is. Imo ook wel weer tekenend voor het C-genootschap.

Je proces paralleliseerbaar maken is iets anders dan schedulers schrijven. Paralleliseerbaar maken is je hoofd proces zo opdelen in brokken dat deze onafhankelijk van elkaar uitgevoerd kunnen worden. Pas daarna kan tooling het voor je overnemen.

Paralleliseerbaar maken is iets waarbij je door je platform/toolkit moet worden ondersteund anders blijf je wielen opnieuw uitvinden.

Dit gaat ze dus niet meer helpen. Zoals in de kick van flowerp al aangegeven werd groeit de hardware niet meer in de hoogte (meer megaherzt, meer instructies per seconde serieel), maar in de breedte (meer cores, meer instructies per seconde parallel). Nieuwe hardware neerzetten zorgt er alleen maar voor dat de applicatie even snel blijft draaien, maar dat er meer cores uit hun neus gaan vreten.

Capaciteitsproblemen uiten zich vaak niet via indivuele gebruikers met individuele applicaties die traag zijn het gaat vaak om grote multi user applicaties waar een bottleneck in de (al parallelle) verwerking zit. Het plaatsen van extra hardware heeft dan weldegelijk nut.

Je vergelijking backfired. Juist omdat die 3rd party bedrijven al met multithreaded implementaties gekomen zijn is dat signle threaded proces waar iedereen op wacht precies die applicatie waarvan jij het niet nodig vindt dat het aangepast wordt .

Nogmaals voor veel applicaties is het niet nodig om te threaden (neem bijv. een Calc, misschien wat wiskundige vergelijkingen oplossen oid).

Pertinent niet waar. Het paralleliseerbaar zijn van een applicatie heeft impact op alle niveaus. Het is niet moeilijk, maar er zijn enkele zaken waar rekening mee gehouden moet worden. Dan kunnen de architecten dat wel leuk gaan uitdenken, maar als John the Programmer (zoals eerder aangehaald) een non-threadsave lijst overal gaat lopen aanroepen krijg je alsnog carnage.

Dat is dan aan de architect om te bepalen welke lists gebruikt mogen worden etc. Dit heeft weinig met voorkeuren van individuele developers te maken, als je multithreaded programmeert moet alles gewoon threadsafe zijn punt.

Qua voorspelling ben ik het helemaal met je eens

Dat doet me deugt.

[Janoz]

LauPro schreef op maandag 10 november 2008 @ 17:55:

En dat is nog in veel situaties het geval, het is toch belachelijk dat anno 2008 iets als glibc gewoon nog niet threadsafe is. Imo ook wel weer tekenend voor het C-genootschap.

Eensch

Paralleliseerbaar maken is iets waarbij je door je platform/toolkit moet worden ondersteund anders blijf je wielen opnieuw uitvinden.

Met ondersteunen alleen ben je er nog lang niet. Waar het om gaat is dat het ook een andere benadering vergt. Je moet voor je probleem niet alleen een oplossing bedenken, maar die oplossing ook nog zo in stukken kunnen knippen dat je kleine onafhankelijke deel oplossing krijgt. Een platform of toolkit kan je enkel handvatten geven, maar het opsplitsen zul je toch echt zelf moeten doen.

Capaciteitsproblemen uiten zich vaak niet via indivuele gebruikers met individuele applicaties die traag zijn het gaat vaak om grote multi user applicaties waar een bottleneck in de (al parallelle) verwerking zit. Het plaatsen van extra hardware heeft dan weldegelijk nut.

Precies mijn punt. Opschalen werkt alleen als de applicatie parallel kan werken. Jij gebruikte de 'gooi er meer hardware tegenaan'-argumentatie in de context van een minder performante singlecore applicatie.

Nogmaals voor veel applicaties is het niet nodig om te threaden (neem bijv. een Calc, misschien wat wiskundige vergelijkingen oplossen oid).

Je gaf zelf al aan dat software steeds meer naar een ASP model zou groeien. Ik durf te stellen dat de meeste op dit moment geschreven applicaties al onder de noemer 'webapp' vallen.

Dat is dan aan de architect om te bepalen welke lists gebruikt mogen worden etc. Dit heeft weinig met voorkeuren van individuele developers te maken, als je multithreaded programmeert moet alles gewoon threadsafe zijn punt.

De list was enkel een voorbeeld. Er zijn 1001 dingen waar je rekening mee moet houden wanneer je in een multithreaded omgeving ontwikkeld. Je kunt niet van een architect verwachten dat hij constant over de schouders van zijn teamgenoten kijkt of ze het wel goed doen.

Dat doet me deugt.

[.oisyn]

LauPro schreef op maandag 10 november 2008 @ 17:55:
Het is gewoon pertinent onwaar dat mensen geen snelheidsverschil merken bij een dual core tov single core systeem. Als je een OS zou schrijven waar alles in 1 thread draait (non-smp) dan heb je gelijk, alleen de huidige moderne OS'en zijn nu eenmaal smp en dus is er per definitie een snelheidswinst met multi core systemen vs single core. Verder is het single core concept in de grotere rekencentra al decennia afgeschreven, het is gewoon de initiatiefloosheid van de processorfabrikanten dat er nu pas (afgelopen jaren) multi core processoren op de markt zijn, die hadden 10 jaar geleden al moeten bestaan. Toen moest iedereen namelijk dure 2way systemen kopen met exotische chipsets voor een beetje performance.

Of dit nou waar is of niet, wat is je punt nu eigenlijk? Of ben je gewoon maar doelloos aan het ranten?

Die 'veel kleinere applicaties' zijn wel 90% van de markt waar de gebruiker mee te maken heeft.

Heel goed, waar de gebruiker mee te maken heeft. Niet 90% van de complete ICT markt, bij lange na niet zelfs. Vind je het heel erg als ik de kleine minderheid even onder het tapijt schuif?

Daar is toch niets mis mee? Hell er zijn zelfs libs die gewoon nog niet threadsafe zijn, wat heeft het dan in godsnaam voor een nut om je applicatie alvast te threaden, het blijft een keten met afhankelijkheden.

Diezelfde redenatie kun je andersom ook aanpassen. Waarom moeten er thread-safe libs gemaakt worden als applicaties niet geparallelliseerd worden? Dus ja, daar is weldegelijk wat mis mee. Verandering krijg je niet door op de andere partij te wachten.

Ik heb het nergens over het automatiseren van optimalisaties maar wel dat de implementatie van bijvoorbeeld een threadmanager in toolkit/platform hoort te zitten en niet in de applicatie (ja uitzonderingen daargelaten).

En er zijn zat van die toolkits, dus daar hoef je niet op te wachten.

En dat is nog in veel situaties het geval, het is toch belachelijk dat anno 2008 iets als glibc gewoon nog niet threadsafe is. Imo ook wel weer tekenend voor het C-genootschap.

Ho ho, wil je die GNU prutsers die aan libc werken (want dat zijn het, als hun lib nog altijd niet thread-safe is) en de developers die hun zaken wél op orde hebben (MS, Intel) niet over 1 kam scheren? Als ik kijk naar de geschiedenis van VC++ waar ik bekend mee ben, dan hebben bieden zij iig al sinds versie 5 (1998) een thread-safe library. En ik geloof dat de singlethreaded variant niet meer bestond vanaf de 2002 of 2003 editie.

[Confusion]

LauPro schreef op maandag 10 november 2008 @ 17:55:
En dat is nog in veel situaties het geval, het is toch belachelijk dat anno 2008 iets als glibc gewoon nog niet threadsafe is. Imo ook wel weer tekenend voor het C-genootschap.

offtopic:
Volgens mij is dat FUD. Even Googlen leert mij dat de glibc wel degelijk threadsafe is.

[Exirion]

Confusion schreef op maandag 10 november 2008 @ 19:32:

offtopic:
Volgens mij is dat FUD. Even Googlen leert mij dat de glibc wel degelijk threadsafe is.

Ja en nee. Officieel is glibc al jaren thread-safe maar in de praktijk zijn er genoeg dingen die fout gaan met multithreading. Soms door 'vergeten' functies die niet safe blijken, en soms domweg door bugs.

[MSalters]

Ik denk dat je niet glibc als bijzonder moet beschouwen puur omdat er threading bugs in zitten. Ik heb nog van weinig libraries gehoord dat er bewijsbaar geen bugs in zitten, en uit ervaring moet ik daarom aannemen dat er in andere libraries ook bugs zitten. Minder, misschien, maar zeker niet 0.

[Soultaker]

Exirion schreef op maandag 10 november 2008 @ 20:36:
Officieel is glibc al jaren thread-safe maar in de praktijk zijn er genoeg dingen die fout gaan met multithreading. Soms door 'vergeten' functies die niet safe blijken, en soms domweg door bugs.

Over wat voor dingen heb je het dan? Er zijn een aantal historische functies die inherent niet reentrant zijn (ctime() en dat soort dingen); die zou je threadsafe kunnen maken met thread local storage e.d. maar eigenlijk moet je als programmeur gewoon de reentrant functies gebruiken.

De belangrijkste C library functies waar threading relevant is, lijken mij de geheugenallocatiefuncties. Die zijn zo essentieel dat ik aanneem dat daar over nagedacht is en dat die dus wel gewoon threadsafe zijn. Wat blijft er dan precies over waar de fouten nog in zitten?

.oisyn schreef op maandag 10 november 2008 @ 18:41:
Ho ho, wil je die GNU prutsers die aan libc werken (want dat zijn het, als hun lib nog altijd niet thread-safe is) en de developers die hun zaken wél op orde hebben (MS, Intel) niet over 1 kam scheren? Als ik kijk naar de geschiedenis van VC++ waar ik bekend mee ben, dan hebben bieden zij iig al sinds versie 5 (1998) een thread-safe library.

Overigens zitten in in de Windows C library wel minder/andere dingen dan in glibc. glibc bevat behalve de standaard C library ook allerlei POSIX en gereleateerde functies zoals sockets, terminals, process control, enzo. Windows heeft daar vaak hele andere API's voor die in andere libraries zitten (b.v. winsock voor sockets). Daarintegen zitten in de MSVCRT wel weer allerei C++ functies die juist weer niet in glibc zitten. Al met al is de vergelijking dus een beetje van appels met peren.