[alg] Gebruik maken van multiple cores

[Verwijderd]

Ik weet wat je bedoelt, en ik snap dat jij een iets politiek correctere aanpak hanteert.
Maar afgezien daarvan weet jij natuurlijk ook wel dat men vooral dit soort argumenten hanteert om Microsoft zwart te maken. Zoals je zelf aangeeft, raakt het argument op zich kant noch wal.
Ook al is het niet specifiek op Microsoft gericht, maar slechts op DirectX, dan nog vind ik het trolling (gezien jouw reactie ben je het in zoverre wel met me eens, het is ongefundeerde kritiek, flaming, trolling, etc). Dat ik voor het gemak even geen onderscheid maak tussen DirectX en Microsoft moet je maar zien als een hyperbolische stijlfiguur.

Ik word inderdaad kotsmisselijk van dat eeuwige ongeinformeerde geblaat en derdehands non-argumenten, dat meen ik serieus.. Ik hoor die flauwekul al jaren, de maat is vol. ik hanteer dus een zero-tolerance beleid.
Ik ben verdomme zelf ook OpenGL-developer, ga mij de les niet lezen (over jump-to-conclusions gesproken!)

[ Voor 28% gewijzigd door Verwijderd op 13-11-2006 13:06 ]

[.oisyn]

Point taken. Anyway, "Gebruik maken van multiple cores" was de topictitel geloof ik

[MBV]

Verwijderd schreef op maandag 13 november 2006 @ 12:44:
Afgezien daarvan is het bijzonder off-topic, dus ga je anti-Microsoft trolling even lekker ergens anders doen. Bah wat heb ik toch een hekel aan jullie gekregen.

Wat ik heb gezien was OpenGL beter te doen qua initialisatie etc. Helaas nog nooit erg veel mee gedaan, dus als het in complexe applicaties anders werkt, dan geloof ik je graag. Exuses voor OT geblaat, ben ik nou eenmaal goed in

En anti-MS? Moet je eens naar wat posts van mij in het Ubuntu-topic zoeken, daar heb ik een 3-posts lange rant tegen Linux ik kijk nu tegen een gnome-desktop aan, voor de goede orde. er zijn alleen nog teveel dingen die makkelijker moeten voor niet-programmeurs

Los daarvan is een van de charmes van OpenGL dat het een open standaard is, die (toen hij nog veel gebruikt werd) ook goed ondersteund was op veel OS'en. Tegenwoordig is het op windows helaas iets minder, en in vista zal het er ook niet sneller op worden. Ook de ondersteuning vanuit de driver-schrijvers valt tegen heb ik begrepen, en de standaard is inmiddels verouderd. Volgens mij allemaal mdat MS heeft gekozen voor DirectX, wat toen nog geen meerwaarde was. En dat is dus wel anti-ms

[ Voor 33% gewijzigd door MBV op 13-11-2006 14:18 ]

[Verwijderd]

MBV schreef op maandag 13 november 2006 @ 14:14:
[...]


Wat ik heb gezien was OpenGL beter te doen qua initialisatie etc. Helaas nog nooit erg veel mee gedaan, dus als het in complexe applicaties anders werkt, dan geloof ik je graag. Exuses voor OT geblaat, ben ik nou eenmaal goed in

Excuses aanvaard.

En anti-MS? Moet je eens naar wat posts van mij in het Ubuntu-topic zoeken, daar heb ik een 3-posts lange rant tegen Linux ik kijk nu tegen een gnome-desktop aan, voor de goede orde. er zijn alleen nog teveel dingen die makkelijker moeten voor niet-programmeurs

Tsja, dat je kritiek hebt op het een, garandeert natuurlijk nog niet dat je voor het ander bent
Gezonde kritiek mag van mij best, ook als het het product van je keuze is. Je verbetert producten immers alleen zolang je niet tevreden bent, eigenlijk moet je dus nooit tevreden zijn.

Om weer on-topic te gaan... ik hoop dat de kritiek op multicore hier ook gezonde kritiek betreft, die de compiler/toolbouwers moet aansporen om betere voorzieningen te leveren, en niet dat het vanuit een afkeer of onwil is om multithreaded code te gebruiken.

Ik ben persoonlijk gewend om voor een enkel proces het onderste uit de kan te halen, wat de hardware betreft, dus voor mij ligt het gebruik van multithreaded code in het verlengde daarvan.
Maar ik kan me wel vinden in sommige argumenten... Soms is het inderdaad zoveel meer overhead om meerdere threads te gebruiken dat je er niets mee wint (zoals het eerste algoritme in mijn thread op een Athlon X2 niet sneller is, en op een Pentium D zelfs iets trager, en op dual CPU-systemen ongetwijfeld ook). En soms heeft het ook geen zin... komen we weer bij de bekende 80-20 regel (of was het intussen 90-10?)... 80% van de tijd wordt in 20% van de code verbruikt. Voor de andere 80% loont het meestal niet om moeite te gaan steken in optimalisaties... dus ook het multithreaden zal daaronder vallen.
Maar, zoals hierboven al gezegd... nooit tevreden zijn, altijd blijven zoeken naar nieuwe manieren om je code sneller en efficienter te krijgen.
Het is een way-of-life naar mijn mening. Je wordt er pas goed in als je het blijft doen, en ervaring opdoet.

[MBV]

tja, voor jouw wel. Helaas zijn er veel te veel werkgevers waar het prima is zolang het maar werkt. Een php-pagina waar 3+n queries voor nodig zijn, terwijl alles in 1 query zou kunnen, mag ik niet gaan herschrijven. Waarom zou je, voorlopig werkt het toch nog? En vorige week moest het al live, dus ga die bugs erin maar fixen. Een dom sorteer/weergeef-algoritme dat bij elke pagina wordt gebruikt, is n^3. Maar het werkt toch?
Dat de meest cruciale pagina daardoor een laadtijd van een seconde heeft boeit eigenlijk niet. Gelukkig mag ik die wel gaan herschrijven, omdat hij absoluut niet te onderhouden was.
gevolg, en nu ook oorzaak, van zware onderbezetting van de it-afdeling. _{nee, ik ga niet neerzetten waar dat is, heb nog collega's nodig}

[ Voor 13% gewijzigd door MBV op 13-11-2006 17:35 ]

[LauPro]

@MBV: Persoonlijk vind ik het probleem dat je noemt los van dit topic staan. Er kunnen tientalle redenen zijn waarom software slecht in elkaar wordt gebouwd. In de meeste gevallen is dat omdat software ontwikkelen niet voor iedereen een kunstvorm is maar een commerciële activiteit. En commercieel gezien is het handig om software te leveren waar net ff een easter egg in zit die na een paar maanden naar voren komt (oh, we hadden toch meer bestellingen dan verwacht) welke je daarna weer kan fixen tegen een leuk uurtarief.

Technisch gezien voor een programmeur is het handiger om alles liefst zo fail-safe te doen, althans ik ken weinig mensen die het leuk vinden om telkens maar weer problemen op te lossen die zijn veroorzaakt door foute keuzes in het verleden (waar je destijds misschein tot gedwongen was?).

Onderbezetting is gewoon bullshit imo, dan moet je maar wat minder werk aannemen. Programmeren is een serieuze zaak, waar fouten soms (financieel) veel impact kunnen hebben dus daar moet je goed aan kunnen werken.

[MBV]

onderbezetting komt doordat de interne automatisering is leeggelopen.
goed. Na 20 posts door mij afdwalen: valt er nog iets te zeggen over MT?

[LauPro]

Denk dat het wel duidelijk is. Bij specifieke applicaties vergelijkbaar met een groot Office-pakket, CAD-achtig systeem of fotobewerkingsprogramma (of pure benchmark/wetenschappelijke berekeningen) kan het zeker voordelen bieden met name als het gaat om renderen. Maar in doorsnee applicaties alles in een thread gooien is waanzin. Zorgt niet alleen voor lastig onderhoudbare code maar ook voor zeer lastig debugbare code.

[ Voor 6% gewijzigd door LauPro op 13-11-2006 22:15 ]

[Olaf van der Spek]

LauPro schreef op vrijdag 10 november 2006 @ 02:15:
[...]
Heb je toevallig naar Apache2 gekeken? Daar zit een interessant stukje job-scheduling in. Ze noemen het zelf MPM's: Multi-Processing Modules. Deze zorgen ervoor dat Apache schaalt van 1 tot theoretisch een oneindig aantal cores (laten we zeggen 2⁶⁴ ). De MPM's voor 8+ cores zijn eigenlijk nog een beetje beta voor zover ik begrijp, maar de architectuur is al klaar voor de toekomst.

MPMs zijn geintroduceerd zodat ze bijvoorbeeld en een multi-processing versie voor Linux konden hebben en een multi-threading versie voor Windows. En dat houdt echt niet op bij 8 threads/processes.

Bij Apache trad vroagâh eigenlijk het probleem op waar we nu op neer komen. In het verleden was het gebruikelijk dat Apache bij PHP voor elke request een nieuwe thread (een proces zelfs) aan maakte (CGI-mode zegmaar). Dit zorgde ervoor als de doorlooptijd van een PHP-script 100ms is dat je al snel een paar duizend treads kon hebben bij populaire sites (zoals Tweakers). Men heeft toen juist PHP als module in Apache gezet zodat er een minimaal aantal thread werd gemaakt en ze rest komt in de fifo queue. Toch sta ik eigenlijk wel te trappelen om PHP met Apache in CGI-mode eens te benchmarken op een 80-core processor tegen een Apache met PHP-module. Want ik denk dat het helemaal niet zoveel uit gaat maken meer (totdat je alle 80 cores bezet hebt natuurlijk).

Het probleem met CGI is dat voor elk request de hele initialisatie van PHP moet worden gedaan en dat is erg duur. Een extra process is niet zo heel erg duur.
Toch is de Apache architectuur met mod_php niet ideaal IMO. Een thread met async netwerk IO die alle requests leest, meerdere worker threads die de responses genereren of meerdere worker processes (FastCGI) voor PHP is veel beter. En ik weet wel zeker dat PHP CGI een ramp is vergeleken met de module of FastCGI.

MBV schreef op zaterdag 11 november 2006 @ 14:29:
Ik zeg dus absoluut niet dat je daarmee een optimale oplossing kan bereiken, zeker niet. Voor de optimale oplossing moet je het beste algoritme implementeren in assembly. Voor een iets minder optimale oplossing moet je in C expliciet de threads gaan doen enzo. Maar met speciale talen, die meer beschrijven wat er moet gebeuren dan het daadwerkelijk uitvoeren, kan je met een (vooralsnog niet bestaande) compiler een redelijk goede MT-oplossing maken.

@flowerp: in dat specifieke geval kan dat idd niet.

Ik denk niet dat je tegenwoordig in assembly sneller bent dan in C, daar zijn de compilers te goed voor.

[ Voor 15% gewijzigd door Olaf van der Spek op 13-11-2006 22:33 ]

[Olaf van der Spek]

flowerp schreef op zondag 12 november 2006 @ 17:29:
Wellicht dat voor het gebruik van dit soort functies dan weer eerder libraries komen die diverse soorten berekeningen op dergelijke specialistische eenheden laten draaien. Zo zag je eerder dat Apple bijvoorbeeld libraries had om vector berekeningen te doen. Als de CPU altivec had gebruikte het die, zo niet dan werden er regulatiere instructies gebruikt. Een zelfde soort iets zie je nu ook al met libraries die GPU effecten bieden, en heel high-level zie je het met die kant en klare graphics engine die valve biedt.

Mischien dat via deze library weg programmeurs die 'tegen' multi-cores zijn toch zonder het te weten meerdere cores van werk gaan voorzien. Beetje irritant is dan alleen dat de hordes mindere programmeurs dingen gaan zeggen als dat de compiler hun code automatisch parallel maakt, maar goed daar moeten we dan maar mee leven

MS heeft al een library waarmee je zaken als array/vector operaties op de GPU kunt uitvoeren.

Voor veel applicaties is het inderdaad belangrijker om async IO te gebruiken dan om multi-threading te gebruiken. Maar helaas wordt async IO nog nauwelijks gebruikt en is er nauwelijks support voor in frameworks en talen (en operating systemen zelf). Hetzelfde geldt voor multi-threading.

Als je een applicatie hebt die max 10% CPU usage heeft, dan kun je gerust achterover leunen en niks doen, want het heeft echt geen zin daar multi-threading aan toe te voegen.

[Alarmnummer]

Olaf van der Spek schreef op maandag 13 november 2006 @ 22:37:
[...]
MS heeft al een library waarmee je zaken als array/vector operaties op de GPU kunt uitvoeren.

Voor veel applicaties is het inderdaad belangrijker om async IO te gebruiken dan om multi-threading te gebruiken. Maar helaas wordt async IO nog nauwelijks gebruikt en is er nauwelijks support voor in frameworks en talen (en operating systemen zelf).

Je moet niet vergeten dat threads niet meer zo duur zijn als ze ooit geweest zijn en dat asynchrone communicatie vaak veel complexer is dan synchrone communicatie. Ik zou niet snel een paar standaard programmeurs achter asynchrone sockets bv wilen zetten.

Op het moment dat je echt veel connecties naast elkaar wilt open hebben en je niet te veel threads naast elkaar wilt draaien (en threads zijn tegenwoodig ook niet zo deur meer, en geblokkeerde threads kosten in principe alleen geheugen, ze hoeven niet ingescheduled te worden) dan zou dit een taak moeten zijn van een component die dit voor je realiseerd en waar jij gewoon een threadpool in kan drukken met een setjes met handlers voor de request afhandeling (reactor/proactor).

Dit heeft meteen een ander voordeel: developers hoeven niet direct te werken met allerlei low level en gecompliceerde constructies (waaronder IPC)

Hetzelfde geldt voor multi-threading.

Ligt aan de taal/platform. Als je kijkt naar Java dan zijn standaard webapplicaties al voorzien van threads door de servlet container, voor message processing is er ook wel een container die de threading problematiek oplost. Alleen batch systemen die vergen wat meer moeite.

ps: ik kan hier trouwens even naar de 3 grote categorieen van serverside applicaties.

[Olaf van der Spek]

Alarmnummer schreef op maandag 13 november 2006 @ 22:46:
Je moet niet vergeten dat threads niet meer zo duur zijn als ze ooit geweest zijn en dat asynchrone communicatie vaak veel complexer is dan synchrone communicatie. Ik zou niet snel een paar standaard programmeurs achter asynchrone sockets bv wilen zetten.

Is dat niet vooral een gevolg van het ontbreken van framework support?

Op het moment dat je echt veel connecties naast elkaar wilt open hebben en je niet te veel threads naast elkaar wilt draaien (en threads zijn tegenwoodig ook niet zo deur meer, en geblokkeerde threads kosten in principe alleen geheugen, ze hoeven niet ingescheduled te worden) dan zou dit een taak moeten zijn van een component die dit voor je realiseerd en waar jij gewoon een threadpool in kan drukken met een setjes met handlers voor de request afhandeling (reactor/proactor).

Dit heeft meteen een ander voordeel: developers hoeven niet direct te werken met allerlei low level en gecompliceerde constructies (waaronder IPC)

Zolang de connecties onafhankelijk zijn gaat dat goed. Maar dat is niet (altijd) zo en dan krijg je toch locking issues. En dan heb ik denk ik liever async IO dan multi-threading, aangezien je met async IO eigenlijk precies weet waar je context switches zitten.

Ik zat te denken aan clients/servers die 100 - 1000 connecties aan moeten kunnen en dan worden threads toch wat lastiger.

Ligt aan de taal/platform. Als je kijkt naar Java dan zijn standaard webapplicaties al voorzien van threads door de servlet container, voor message processing is er ook wel een container die de threading problematiek oplost. Alleen batch systemen die vergen wat meer moeite.

ps: ik kan hier trouwens even naar de 3 grote categorieen van serverside applicaties.

Server-side is bijna inherent multi-threaded natuurlijk. Dat ging meer over client apps.

[ Voor 3% gewijzigd door Olaf van der Spek op 13-11-2006 22:56 ]

[Alarmnummer]

Olaf van der Spek schreef op maandag 13 november 2006 @ 22:54:
[...]
Is dat niet vooral een gevolg van het ontbreken van framework support?

Hmm tja.. dat zou kunnen.

Zolang de connecties onafhankelijk zijn gaat dat goed. Maar dat is niet (altijd) zo en dan krijg je toch locking issues. En dan heb ik denk ik liever async IO dan multi-threading, aangezien je met async IO eigenlijk precies weet waar je context switches zitten.

Ik denk niet dat veel mensen tot op dit niveau er mee bezig gaan. Het onderste wordt meestal niet uit de kan gehaald omdat de kennis/tijd ontbreekt en het daarom onbekend/erg duur is (en omdat het gewoon niet vaak nodig is). Meestal gebruik je een omgeving die allerlei faciliteiten ondersteunt. Ik maak binnen spring ook liever gebruik van kant en klare exporters die dit soort zaken op zich nemen.

Alleen in uitzonderlijke situaties zou ik hier naar gaan kijken (lees: ik ben het in praktijk nog nooit tegengekomen).

Ik zat te denken aan clients/servers die 100 - 1000 connecties aan moeten kunnen en dan worden threads toch wat lastiger.

Op moderne cpu's en os's: peanuts. Ik denk dat je bij de 10.000-100.000 problemen gaat zien. Maar hoe veel mensen maken dit soort applicaties? Ik zou dolgraag eens zo iets doen voor een klant, maar denk niet dat dit er ooit van zal komen.

Server-side is bijna inherent multi-threaded natuurlijk. Dat ging meer over client apps.

Clientside is saai

[TheNameless]

Even een reply uit mijn ogen (misschien een beetje off-topic, maar goed...)

Ik ben zelf bezig met Grid computing voor mijn werk (ik ben Scientific Software Engineer bij het AMC).
Bij het Grid-computing wordt er eigenlijk heel anders tegen parallel programmeren aan gekeken.

Als er een echt CPU intensief probleem is, wordt er allang niet meer gedacht aan het multithreading maar aan het opsplitsen van het probleem in jobs. Als deze jobs klaar zijn dan wordt alle output van de jobs samen gevoegd tot het uiteindelijk resultaat.

Ik zie hier ook reply's van mensen die het hebben over wiskundige problemen en dat daar multi-threading kan helpen, maar ik zie dit eigenlijk als een tussen oplossing die niet echt goed schaalbaar is (geheugen gebruik bijvoorbeeld?).

Zo hebben wij op het werk bijvoorbeeld een beeldbewerkings programma die met een redelijk verouderde CT scanner als beelden "spuger" al tegen de 1 Gigabyte geheugen gebruik aanloopt.
Met die nieuwere scanners loopt het gebruik al gauw op naar de 4 Gigabyte en dan wordt de scanner nog niet ten volle benut. Dit programma is al multi-threading maar nu krijgen we dus al geheugen problemen.

[MBV]

Ik denk dat veel mensen (gedeeltelijk uit onwetendheid) hier geen onderscheid maken tussen MT en jobs, en jobs als een vorm van MT zien. Waarom ook niet? Elke job is toch eigenlijk een thread, of zie ik iets heel erg over het hoofd?

_{oftewel: welke leraar van me wordt nu heel erg boos omdat ik heb zitten slapen}

[Verwijderd]

Tsja, het gebruik van threads in het Java-framework etc... da's leuk en aardig... Maar redelijk triviaal.
Ik denk dat het basiskennis voor iedere programmeur moet zijn om verschillende taken in verschillende threads te kunnen bouwen.
Maar het *echte* werk is dus async I/O en een algoritme opdelen in meerdere threads (of zelfs een hele grid van computers dus).
Dat is vaak heel lastig, en daarvoor zouden betere tools handig zijn, en sowieso bijscholing van programmeurs.
Maar het is een redelijk specifieke groep programmeurs, lijkt me. Computers zijn tegenwoordig zo snel dat alleen hele zware rekentaken niet binnen een paar seconden afgehandeld kunnen worden.
Voor de meeste code volstaat het waarschijnlijk wel om gewoon redelijk efficiente single-threaded code te hebben (zoals bv database-frontends, het zware werk wordt gedaan in de database-engine (geschreven door die specifieke groep programmeurs), je moet alleen de juiste queries formuleren om het efficient te maken).

Ik denk dat games op dit moment zo'n beetje de meest complexe software vormen... Het is een combinatie van graphics, physics, AI en realtime, wat allemaal behoorlijk lastige vakgebieden zijn. En om het allemaal samen te laten lopen, en efficient op meerdere cores, is helemaal lastig.
Dan kom je er niet met gewoon 1 thread per taak.
Vandaar dat ik het hybrid threading systeem van Valve zo interessant vind. Daarmee moet je zelfs de moeilijkste taken nog redelijk efficient samen kunnen laten lopen op een multicore-systeem (zolang de taken niet impliciet lineair zijn uiteraard).

[roy-t]

Kun je er als programmeur van uit gaan dat als je ene dual core proc hebt. Core1 exact even snel rekent als Core2. dus dat je in theorie bijvoorbeeld taken zou kunnen maken die realtime, lineair naast elkaar moeten lopen, dan bijv 1.sec moet wachten totdat je het resultaat van 1 en 2 op het zelfde moment krijgt? ik denk dat ik het heel slecht beschrijf zo..

[BertS]

Dat werkt natuurlijk alleen als je die twee procs voor 100% tot je beschikking hebt en er dus geen andere taken/processen draaien. Lijkt me nogal een cleanroom-situatie.

[Olaf van der Spek]

therat10430 schreef op dinsdag 14 november 2006 @ 17:48:
Kun je er als programmeur van uit gaan dat als je ene dual core proc hebt. Core1 exact even snel rekent als Core2. dus dat je in theorie bijvoorbeeld taken zou kunnen maken die realtime, lineair naast elkaar moeten lopen, dan bijv 1.sec moet wachten totdat je het resultaat van 1 en 2 op het zelfde moment krijgt? ik denk dat ik het heel slecht beschrijf zo..

Nee. Beide cores zouden bijvoorbeeld op een andere frequentie kunnen lopen.

[H!GHGuY]

therat10430 schreef op dinsdag 14 november 2006 @ 17:48:
Kun je er als programmeur van uit gaan dat als je ene dual core proc hebt. Core1 exact even snel rekent als Core2. dus dat je in theorie bijvoorbeeld taken zou kunnen maken die realtime, lineair naast elkaar moeten lopen, dan bijv 1.sec moet wachten totdat je het resultaat van 1 en 2 op het zelfde moment krijgt? ik denk dat ik het heel slecht beschrijf zo..

hoeft ook niet.
Ik kan wel een eenvoudige methode bedenken om het feit dat processor 1(die thread 1 draait) iets minder moet doen dan processor 2 (met thread 2) op te vangen. Je kan bvb de thread 2 een iets hogere prioriteit geven zodat andere systeemtaken de ruimte op processor 1 opvullen en niet thread 2 onnodig van de processor halen.

Je kan nu eenmaal geen thread at runtime gaan opdelen. (let op het woord "nu" )

Het komt er mijns inziens gewoon op neer dat er meer support moet komen voor MT dmv libraries, frameworks e.d. Misschien ook tools alla valgrind, coverity e.a. die een analyse kunnen maken van mogelijks gevaarlijke situaties in de code.
Dat dit in high-level talen als Java/C# en andere behoorlijk geregeld is is logisch, maar dat zijn in veel gevallen ook de talen waar performantie niet "het" criterium is. (waarmee ik zeker niet wil impliceren dat ze inherent traag zijn)
Anderzijds lijkt het me raar dat voor low-level talen als C++ dit soort ongein snel in een framework of library zal gegoten worden voor alledaags gebruik.

Ik heb ook mijn mini-library met klassen als CTask, CMutex, CSemaphore en andere...

[Olaf van der Spek]

H!GHGuY schreef op dinsdag 14 november 2006 @ 19:12:
Anderzijds lijkt het me raar dat voor low-level talen als C++ dit soort ongein snel in een framework of library zal gegoten worden voor alledaags gebruik.

Ik heb ook mijn mini-library met klassen als CTask, CMutex, CSemaphore en andere...

Boost heeft toch een thread lib?

[Verwijderd]

Het wrappen van OS-threads in een of andere leuke klasse (zoals bv Boost) is nog niet echt multithreaded programmeren.
De programmeur moet nog steeds zelf zorgen dat er geen race conditions, deadlocks etc komen, en als er met meerdere threads tegelijk gerekend wordt, moet de programmeur zelf dus meerdere threads maken, en ervoor zorgen dat deze op de juiste momenten worden gestart, gestopt en van data voorzien.

Wat we nog niet hebben, is een compiler waar je gewoon normale single-threaded code in stopt, en waar dan automagisch een efficient multithreaded algoritme uit rolt, wat 100% betrouwbaar werkt.

Ik denk ook dat we dat voorlopig nog niet gaan krijgen, omdat er gewoon geen simpele standaard-oplossing bestaat voor dit probleem.

OpenMP komt nog het dichtst in de buurt op het moment, denk ik. Daar kun je tenminste standaard C++-code met een paar simpele #pragma directives op meerdere cores tegelijk uit laten voeren. Je hoeft dus niet meer handmatig threads te gaan maken en beheren. Dit maakt de code ook een stuk makkelijker te beheren.
Maar de programmeur is nog wel zelf verantwoordelijk voor problemen met shared resources, en ook voor de optimalisatie. Als je OpenMP op de verkeerde manier inzet, kan je code juist langzamer worden ipv sneller.
Het vereist dus nog steeds extra specifieke kennis, en het blijft dus moeilijker dan singlethreaded code schrijven. Maar het is een begin.

[Alarmnummer]

Verwijderd schreef op dinsdag 14 november 2006 @ 09:39:
Tsja, het gebruik van threads in het Java-framework etc... da's leuk en aardig... Maar redelijk triviaal.

Als het triviaal zou zijn, dan zouden er niet zo veel fouten mee gemaakt worden. En sowieso krijg je in de enterprise wereld weer met hele andere problemen te maken zoals business transacties die meerdere system transacties overspannen, of optimistic locking om de performance van de db op te krikken.

Dat is concurrency op een heel ander niveau.

En er worden ook genoeg systemen ontwikkeld worden die echt custom oplossingen nodig zijn. Ik kan het weten, ik ben er regelmatig mee bezig.

Wat voor ervaring heb jij met Enterprise Java en concurrency?

[ Voor 5% gewijzigd door Alarmnummer op 14-11-2006 20:27 ]

[Verwijderd]

Alarmnummer schreef op dinsdag 14 november 2006 @ 20:23:
[...]

Als het triviaal zou zijn, dan zouden er niet zo veel fouten mee gemaakt worden.

Ik bedoel natuurlijk in de context van multithreading.
Als je een component gebruikt die intern threads voor je gebruikt, zoals aangegeven werd, dan ben je technisch gezien wel aan het multithreaden, maar dat is dan het makkelijkste geval... en vaak verre van ideaal (geen load-balancing en dergelijke).
En vaak zijn het threads omdat die het gewoon makkelijk maken om iets te implementeren, zoals bv een server die meerdere clients tegelijk moet kunnen afhandelen.
Dat wordt ook op singlethreaded machines gedaan, en is dus vanuit praktisch oogpunt, en niet zozeer om multicore CPUs (optimaal) te benutten. Wat jij opnoemt zijn algemene problemen, en hebben eigenlijk niet zozeer iets te maken met het aantal cores waar je je code op zou richten.
Dit topic gaat toch meer over het optimaal benutten van meerdere cores, in alle gevallen, heb ik de indruk. Niet alleen de uitzonderingen dus.

[ Voor 6% gewijzigd door Verwijderd op 14-11-2006 21:25 ]

[Olaf van der Spek]

Alarmnummer schreef op maandag 13 november 2006 @ 23:11:
Op moderne cpu's en os's: peanuts. Ik denk dat je bij de 10.000-100.000 problemen gaat zien.

Met een default stack size van 1 mb heb je bij 10000 threads al 10 gb geheugen nodig. Oeps.

[flowerp]

Verwijderd schreef op dinsdag 14 november 2006 @ 21:24:
Dat wordt ook op singlethreaded machines gedaan, en is dus vanuit praktisch oogpunt, en niet zozeer om multicore CPUs (optimaal) te benutten.

Op een server wordt vaak het maximale aantal threads ingesteld in relatie met hoeveel requesten je per seconden tegelijk wilt kunnen afhandelen (waarbij je dan kijkt of bij dat aantal de turnaround time nog wel acceptabel is). Je maakt daarbij bij een single core machine eigenlijk niet radicaal andere afwegingen als bij een multi-core. De multi-core kan mischien meer requesten aan, maar dat zou een 2x zo snelle single core ook kunnen.

Bij 1 enkel probleem opsplitsen in meerdere threads met als enkel doel dat ene geheel te versnellen moet je hele andere afwegingen maken. Je aantal threads zou dan maximaal gelijk moeten zijn aan je aantal cores (als het 100% cpu bound is).

Ik vraag me af of ook echt iedereen dit laatste doet. Kijken jullie @runtime hoeveel cores de machine heeft en stem je daar je aantal (worker) threads dynamisch op af?

[Verwijderd]

flowerp schreef op dinsdag 14 november 2006 @ 22:31:
[...]


Op een server wordt vaak het maximale aantal threads ingesteld in relatie met hoeveel requesten je per seconden tegelijk wilt kunnen afhandelen (waarbij je dan kijkt of bij dat aantal de turnaround time nog wel acceptabel is). Je maakt daarbij bij een single core machine eigenlijk niet radicaal andere afwegingen als bij een multi-core. De multi-core kan mischien meer requesten aan, maar dat zou een 2x zo snelle single core ook kunnen.

Ja, dat is precies wat ik bedoel. Dat de multicore-CPU meer threads tegelijk kan draaien is leuk, maar je garandeert er niet mee dat je efficient bezig bent, omdat je het per request opdeelt, en verder niet kijkt naar hoe zwaar een request is. In theorie kan het nog steeds zo zijn dat 1 core een request moet doen waar ie een paar seconden mee bezig is, terwijl de andere cores alleen simpele requests doen, waar ze amper door worden beziggehouden.
Dan kom je een beetje bij dat hybrid threading van Valve's engine terecht...
Je zou dan dat zware request over een paar cores kunnen opdelen, zodat de responstijd verbeterd wordt. Maar je kunt nog wel wat cores vrij laten om ook nieuwe requests nog te kunnen verwerken.
Zo kun je de gemiddelde respons verbeteren, en de load veel beter balanceren.

Bij 1 enkel probleem opsplitsen in meerdere threads met als enkel doel dat ene geheel te versnellen moet je hele andere afwegingen maken. Je aantal threads zou dan maximaal gelijk moeten zijn aan je aantal cores (als het 100% cpu bound is).

Dat ligt een beetje aan het algoritme inderdaad... Ik heb op een dualcore met 2-4 threads getest, en soms liepen 4 threads beter dan 2. Dat heeft misschien ook deels met de OS-scheduler te maken... met meer threads heb je meer recht op timeslices van het systeem, om het zo maar uit te drukken.

Ik vraag me af of ook echt iedereen dit laatste doet. Kijken jullie @runtime hoeveel cores de machine heeft en stem je daar je aantal (worker) threads dynamisch op af?

Als het kan, dan doe ik dat ja. Met OpenMP is het vaak redelijk eenvoudig om het aantal threads at runtime in te stellen. Standaard maakt ie al evenveel threads aan als dat er cores zijn, maar dat is misschien niet altijd wat je wilt.
Verder hou ik soms ook zelfs rekening met de cachegrootte of cacheconfiguratie van een machine.
Maar dat ligt een beetje aan de aard van het algoritme.

[Confusion]

Verwijderd schreef op dinsdag 14 november 2006 @ 22:41:
Dan kom je een beetje bij dat hybrid threading van Valve's engine terecht...
Je zou dan dat zware request over een paar cores kunnen opdelen

Hoe bepaalt die engine de zwaarte van een requests? Als je daarvoor meta-informatie mee moet gaan geven, dan moet je wel zeker weten dat de gewichten die je toekent goed zijn, anders maak je het misschien wel erger.

[Verwijderd]

Confusion schreef op woensdag 15 november 2006 @ 09:18:
[...]

Hoe bepaalt die engine de zwaarte van een requests? Als je daarvoor meta-informatie mee moet gaan geven, dan moet je wel zeker weten dat de gewichten die je toekent goed zijn, anders maak je het misschien wel erger.

We zijn wel weer erg negatief ingesteld he
Waarom denk je niet positief, en aan hoeveel beter het is als je de zwaarte wel redelijk goed kunt bepalen (wat helemaal niet zo precies hoeft, zodra je 2 of 3 cores gebruikt voor een zware request, vliegt de respons-tijd al naar beneden, je kunt dus erg conservatief schatten...).

Je krijgt hier echt het idee dat ieder excuus aangegrepen wordt om vooral niet aan te hoeven passen.

[ Voor 7% gewijzigd door Verwijderd op 15-11-2006 09:41 ]

[Confusion]

Verwijderd schreef op woensdag 15 november 2006 @ 09:35:
We zijn wel weer erg negatief ingesteld he

Neu, ik wil alleen de risico's in kaart brengen. Als er een situatie kan ontstaan waarin een licht request als zwaar wordt ingeschat, dan kan een flinke serie van die lichte requests de cores gaan 'hoggen'. Als de zwaarte automatisch aan de hand van de code wordt bepaald, dan wil ik wat meer over het algoritme weten voor ik zoiets zou gebruiken. Als het op meta-informatie berust, dan moet er eerst goed gebenched worden.

Je krijgt hier echt het idee dat ieder excuus aangegrepen wordt om vooral niet aan te hoeven passen.

Welnee, bij spelen met threads is er tenminste nog iets te beleven .

[joepP]

Alarmnummer schreef op maandag 13 november 2006 @ 23:11:
Op moderne cpu's en os's: peanuts. Ik denk dat je bij de 10.000-100.000 problemen gaat zien. Maar hoe veel mensen maken dit soort applicaties? Ik zou dolgraag eens zo iets doen voor een klant, maar denk niet dat dit er ooit van zal komen.

Ik hoop dat je het hier over connecties hebt, en niet over threads? Een connectie op een webserver/database/applicatie is vaak namelijk helemaal geen thread.

Een programma dat 10.000 threads nodig heeft is zeer waarschijnlijk slecht ontworpen. Geen enkele processor/OS kan zoveel threads nog fatsoenlijk schedulen. De enige reden waarom een programma met zoveel threads nog fatsoenlijk zou kunnen performen is als het merendeel ervan niets staat te doen. Maar dan kan je veel beter een aantal jobs definieren, en die door een vast aantal workerthreads (100 misschien, maar waarschijnlijk eerder 10) laten afhandelen. Vergeet ook niet dat een thread standaard 1MB geheugen opsnoept.

[Verwijderd]

Confusion schreef op woensdag 15 november 2006 @ 10:53:
[...]

Neu, ik wil alleen de risico's in kaart brengen. Als er een situatie kan ontstaan waarin een licht request als zwaar wordt ingeschat, dan kan een flinke serie van die lichte requests de cores gaan 'hoggen'. Als de zwaarte automatisch aan de hand van de code wordt bepaald, dan wil ik wat meer over het algoritme weten voor ik zoiets zou gebruiken. Als het op meta-informatie berust, dan moet er eerst goed gebenched worden.

Da's allemaal wel leuk en aardig, maar allemaal zeer probleem-specifiek (wat is een request, hoe zwaar is zwaar, etc etc).
Je schrijft het op een manier alsof het een vraag is, alsof ik er op in moet gaan.
Dat kan alleen als ik me verdiept heb in het probleem, dus dat is hier niet van toepassing. We praten hier puur over hypothetische gevallen, en wat er mogelijk is aan (efficiente) multithreading.

Wat je er verder over kunt zeggen, is vooral de standaard theoretische open deuren intrappen, van vooral het juiste algoritme voor de juiste taak kiezen etc, maar dan zit je weer niet multithreaded-specifiek te praten, dus is het niet zo on-topic.

Dus, ik snap niet waar je heen wilt.

[Confusion]

Verwijderd schreef op woensdag 15 november 2006 @ 11:17:
We praten hier puur over hypothetische gevallen, en wat er mogelijk is aan (efficiente) multithreading.

OK, ik dacht dat je wist hoe zoiets in de praktijk over het algemeen aangepakt wordt en probeerde daar wat informatie over te krijgen; ik bedacht me hoe zoiets op een van mijn applicaties nuttig zou kunnen zijn in de toekomst, vandaar.

[Verwijderd]

joepP schreef op woensdag 15 november 2006 @ 11:00:
[...]

Ik hoop dat je het hier over connecties hebt, en niet over threads? Een connectie op een webserver/database/applicatie is vaak namelijk helemaal geen thread.

Een programma dat 10.000 threads nodig heeft is zeer waarschijnlijk slecht ontworpen. Geen enkele processor/OS kan zoveel threads nog fatsoenlijk schedulen. De enige reden waarom een programma met zoveel threads nog fatsoenlijk zou kunnen performen is als het merendeel ervan niets staat te doen. Maar dan kan je veel beter een aantal jobs definieren, en die door een vast aantal workerthreads (100 misschien, maar waarschijnlijk eerder 10) laten afhandelen. Vergeet ook niet dat een thread standaard 1MB geheugen opsnoept.

Dat is een heel goed punt, waar blijkbaar heel makkelijk overheen gestapt wordt.
Threads zijn nog steeds niet heel efficient, context switching, synchronisatie, thread-local-storage etc...
Gewoon meer threads ertegenaangooien is niet de manier.
Waarschijnlijk is er wel een goede vuistregel te vinden... iets van "Niet meer dan 2x het aantal cores aan actieve threads".

Het deel waar ik graag dieper op in zou gaan is het efficient aan het werk zetten en houden van zulke threads. Steeds nieuwe threads aanmaken en afsluiten is ook een veel gemaakte fout, bijvoorbeeld.
Ook het veelvuldig schrijven naar globaal geheugen kan een multithreaded systeem erg traag maken op meerdere cores. En zo zijn er veel meer valkuilen, waar veel ontwikkelaars vaak intuinen (kijk voor de grap eens naar mysql, en hoe belachelijk slecht dat schaalt naar veel cores, vergeleken met oa postgresql).

Wij programmeurs dachten vooral 'verticaal'.... we moeten meer 'horizontaal' leren denken.
In plaats van dit:
for (..)
a();
b();
c();
end for

Moet je meer denken aan:
for (..)
a();
end for

for (..)
b();
end for

for (..)
c();
end for

En de volgende stap is dan om er een 'watervalletje' van te maken.
a() maakt dus een werksetje klaar voor b(), etc etc.
De tweede batch van a() kan dus naast de eerste batch van b() draaien.
Etc... Uiteindelijk kun je dus a(), b() en c() tegelijk draaien, als een soort pipelining. En dan is je code dus 'horizontaal' (in het ideale geval kun je ook meerdere instanties van dezelfde bewerking naast elkaar draaien).

De volgende stap is om de load te balanceren.
Misschien is a() wel sneller dan b().
Dan heb je op een gegeven moment dus batches extra in de queue voor b(), en niets meer bij a().
Dan ga je dus de thread van a() inzetten voor b().

Dat is dus in een notendop een beetje de omschakeling die je moet gaan maken (je moet dus bijna letterlijk 90 graden draaien in je denkwijze).
De grap is dat de 'horizontale' methode eigenlijk bijna geen extra overhead heeft in het geval van maar 1 thread. In sommige gevallen is het zelfs bij 1 thread aan te raden, vanwege de betere cache coherency.

Maargoed, dit is de aanzet, wie gaat ermee verder?

[Olaf van der Spek]

joepP schreef op woensdag 15 november 2006 @ 11:00:
Ik hoop dat je het hier over connecties hebt, en niet over threads? Een connectie op een webserver/database/applicatie is vaak namelijk helemaal geen thread.

Helaas is dat in het geval van Apache 2.2, PHP en MySQL wel zo. Erger nog, bij Apache is het zelfs een proces in plaats van een thread.

[joepP]

Olaf van der Spek schreef op woensdag 15 november 2006 @ 12:53:
[...]

Helaas is dat in het geval van Apache 2.2, PHP en MySQL wel zo. Erger nog, bij Apache is het zelfs een proces in plaats van een thread.

Dat ga je niet menen.

Dat leidt tot gigantische performance problemen als het ineens druk wordt. Eerst moeten er meer threads (of zelfs processen...) gespawnded worden. Dat kost al behoorlijk wat performance, iets wat je in die situatie -juist- niet wilt. Daarna moeten die threads allemaal tegelijk dingen gaan doen, wat ook al niet prettig is inzake racing en I/O. Het gevolg is extra traagheid, nog meer threads, en een server die verschrikkelijk langzaam gaat reageren. De schaalbaarheid zal dus ook wel behoorlijk ruk zijn, of zelfs negatief in uitzonderlijke gevallen.

Ik mag toch hopen dat ze dit wel iets beter hebben doordacht? Of dat er een redelijke (als in: 100) limiet op het aantal threads zit? Waarom worden requests niet in een centrale queue gezet als een job, en dan door worker threads afgehandeld?

[Alarmnummer]

Olaf van der Spek schreef op dinsdag 14 november 2006 @ 21:45:
[...]

Met een default stack size van 1 mb heb je bij 10000 threads al 10 gb geheugen nodig. Oeps.

Een voorbeeld zegt meer dan 4000 woorden

code:

public class Main{


    public static void main(String[] args){
        Object condition = new Object();
        System.out.println("Creating threads");
        for(int k=0;k<4000;k++){
            Task task = new Task(condition);
            new Thread(task).start();
        }
        System.out.println("finished creating threads");
    }
    
    static class  Task implements Runnable{
        private Object condition;
        
        Task(Object condition){
            this.condition = condition;
        }
        
        public void run(){
            try{
                synchronized(condition){
                    condition.wait();
                }
            }catch(InterruptedException ex){
                ex.printStackTrace();
            }
        }
    }   
}

Dit programma kost mij onder Windows XP Pro 66.8 mb. (onder ibm jre 1.3.1)
met de sun jre 1.5 kost het 102.8 mb

En ik wil niet zeggen dat je als een kip zonder kop maar threads aan moet maken. Maar ik wil wel zeggen dat je onnodige complexiteit ,moet vermijden als er wellicht simpelere alternatieven zijn. Asynchrone communicatie is nu eenmaal complexer dan synchrone communicatie en daarom zijn er ook minder mensen in thuis (sowieso zijn veel developers niet echt thuis in io/thread gerelateerde problematiek).

[ Voor 10% gewijzigd door Alarmnummer op 15-11-2006 14:52 ]

[Alarmnummer]

joepP schreef op woensdag 15 november 2006 @ 11:00:
[...]

Ik hoop dat je het hier over connecties hebt, en niet over threads? Een connectie op een webserver/database/applicatie is vaak namelijk helemaal geen thread.

Ik heb het over threads in de jvm (ongeacht de applicatie).

Een programma dat 10.000 threads nodig heeft is zeer waarschijnlijk slecht ontworpen.

Die kans is aanwezig, Maar je moet zo nu en dan begrijpen dat tijden veranderen, dingen die vroeger duur waren zijn nu niet meer zo duur.

Geen enkele processor/OS kan zoveel threads nog fatsoenlijk schedulen. De enige reden waarom een programma met zoveel threads nog fatsoenlijk zou kunnen performen is als het merendeel ervan niets staat te doen.

exact.

Maar dan kan je veel beter een aantal jobs definieren, en die door een vast aantal workerthreads (100 misschien, maar waarschijnlijk eerder 10) laten afhandelen.

Dat kan, maar dan zit je weer met de complexiteit van asynchrone communicatie. Je moet dan een tradeof gaan maken. Verder ga ik zeker niet zeggen dat asynchrone communicatie slecht is (ik vind het zelf een heel interessant onderwerp) en zal zo nu en dan ook zeker een beter alternatief zijn.

[ Voor 7% gewijzigd door Alarmnummer op 15-11-2006 14:45 ]

[Olaf van der Spek]

Alarmnummer schreef op woensdag 15 november 2006 @ 14:34:
Een voorbeeld zegt meer dan 4000 woorden

Dit programma kost mij onder Windows XP Pro 66.8 mb.

Maar dat zijn user-level threads en geen native threads. Ook doen ze verdacht weinig.
En het zijn er 2,5x minder dan de eerder genoemde 10000.
Verder is het de vraag of de code minder complex wordt, aangezien je de complexiteit verschuift van async IO naar locking.

[Olaf van der Spek]

joepP schreef op woensdag 15 november 2006 @ 13:53:
Dat leidt tot gigantische performance problemen als het ineens druk wordt. Eerst moeten er meer threads (of zelfs processen...) gespawnded worden. Dat kost al behoorlijk wat performance, iets wat je in die situatie -juist- niet wilt.

Daar heb je preforking voor, waardoor je die threads/processes al hebt voordat je ze nodig hebt.

Ik mag toch hopen dat ze dit wel iets beter hebben doordacht? Of dat er een redelijke (als in: 100) limiet op het aantal threads zit? Waarom worden requests niet in een centrale queue gezet als een job, en dan door worker threads afgehandeld?

Uiteraard is er een limiet, maar daardoor kan Apache ook niet zoveel connecties tegelijkertijd afhandelen en wordt vaak een aparte andere server ingezet voor static files.
Het probleem wordt deels veroorzaakt door bagage uit het verleden en het feit dat PHP in de server zelf zit in plaats van buiten de server met FastCGI. PHP is dan weer niet veilig met multi-threading, dus kom je uit op meerdere processen.

[Alarmnummer]

Olaf van der Spek schreef op woensdag 15 november 2006 @ 14:56:
[...]
Maar dat zijn user-level threads en geen native threads. Ook doen ze verdacht weinig.

Java heeft al eeuwen geen green threads meer. Het zijn echt kernel level threads. Als ik in de TaskManager de threadcount zichtbaar maak, dan staat daar ook echt 4008.

En het zijn er 2,5x minder dan de eerder genoemde 10000.

Ik zal hiervoor ook even met de vm-settings moeten spelen aangezien alles nog op default staat.

Verder is het de vraag of de code minder complex wordt, aangezien je de complexiteit verschuift van async IO naar locking.

Deze redenatie kan ik niet volgen (moet het niet blocking ipv locking zijn?)

[ Voor 4% gewijzigd door Alarmnummer op 15-11-2006 15:14 ]

[Olaf van der Spek]

Alarmnummer schreef op woensdag 15 november 2006 @ 15:11:
Deze redenatie kan ik niet volgen (moet het niet blocking ipv locking zijn?)

Als je shared data hebt, heb je locking nodig voor die data. En locking is ook niet zo simpel.

[Alarmnummer]

Onder windows was ik in staat om 9x4000=36.000 threads op de starten voordat ik problemen begon te krijgen. Ik heb dit gedaan door 9 keer het proces vanaf de commandline op te starten.

Ik zal zometeen even kijken of ik het binnen 1 process kan realiseren.

Het lijkt me dus wel vrij duidelijk dat een os in staat is om meer dan 10.000 te kunnen beheren (uiteraard wil je ze niet allemaal naast elkaar actief hebben), En in dat opzicht is asynchrone communicatie weer iets handiger doordat je het daar iets eenvoudiger onder controle kunt houden. Er staat mij bij dat een linux kernel met de juiste aanpassingen meer dan 300k threads kan beheren.

[ Voor 43% gewijzigd door Alarmnummer op 15-11-2006 15:39 ]

[Alarmnummer]

Olaf van der Spek schreef op woensdag 15 november 2006 @ 15:23:
[...]
Als je shared data hebt, heb je locking nodig voor die data. En locking is ook niet zo simpel.

Ik snap niet hoe jij aan de stap komt dat je shared data nodig bent. Maar lijkt me eerlijk gezegd ook geen heel spannende discussie (voor nu)

[Verwijderd]

Olaf van der Spek schreef op woensdag 15 november 2006 @ 15:23:
[...]

Als je shared data hebt, heb je locking nodig voor die data. En locking is ook niet zo simpel.

Niet per se
Soms kun je wegkomen zonder locking, als je er bv vanuit kunt gaan dat je altijd een correcte waarde wegschrijft. Ik maak hier vaak dankbaar gebruik van. Als je een stuk code hebt dat goedkoper is om twee keer uit te voeren dan om 1 keer uit te voeren binnen een lock, dan bereken je het gewoon twee keer.
Bij alleen lezen heb je sowieso geen lock nodig natuurlijk.
Verder heb je op de x86 de lock-instructieprefix, en dankzij de CISC-heid van de processor kun je redelijk wat operaties in 1 keer doen met die prefix. In VC++ heb je hiervoor intrinsic-functies.
Het lezen en updaten van bv een shared bitmap of integer kan hiermee redelijk efficient, omdat je op hardware-niveau lockt, alleen voor 1 specifieke instructie. Vele malen efficienter dan een critical section (proces-breed) of een mutex/semaphore (systeem-breed).

De truc is dus om zo min mogelijk en zo efficient mogelijk te locken.

[Alarmnummer]

Verwijderd schreef op woensdag 15 november 2006 @ 15:33:
[...]
De truc is dus om zo min mogelijk en zo efficient mogelijk te locken.

Concurrency performance 101

Optimistic locking, in tegenstelling tot pessimistic locking, in een applicatie (dus niet zozeer in de db) kan ook een performance boost geven, als je weet dat de kans klein is dat een ander op dezelfde data actief is, en als je met optimisticlockingfailures om kunt gaan. Java heeft bv ook bepaalde structuren (bv sommige iterators) die deze locking techniek toepassen (en maakt ze meteen stuk minder deadlock gevoelig).

[ Voor 8% gewijzigd door Alarmnummer op 15-11-2006 15:45 ]

[Confusion]

Olaf van der Spek schreef op woensdag 15 november 2006 @ 12:53:
Helaas is dat in het geval van Apache 2.2, PHP en MySQL wel zo. Erger nog, bij Apache is het zelfs een proces in plaats van een thread.

Toch niet als je de worker variant gebruikt?

[Alarmnummer]

Verwijderd schreef op woensdag 15 november 2006 @ 11:36:
[...]
Dat is een heel goed punt, waar blijkbaar heel makkelijk overheen gestapt wordt.
Threads zijn nog steeds niet heel efficient, context switching, synchronisatie, thread-local-storage etc...
Gewoon meer threads ertegenaangooien is niet de manier.
Waarschijnlijk is er wel een goede vuistregel te vinden... iets van "Niet meer dan 2x het aantal cores aan actieve threads".

1) thread die niet in een runnable toestand staat, zal niet worden ingescheduled. Kosten voor een slapende thread zijn dus vrij laag (voornamelijk een geheugen kwestie)

2) in io-bound systemen wil je juist een 'groot' aantal threads atief hebben zodat de cpu door een thread gebruikt kan worden, als een andere thread op io staat te wachten. Hierdoor kan je een cpu dus effectief gebruiken. Bij cpu bound systemen zal het niet helpen om meer threads dan cores te hebben omdat je met 1 thread (per core) de cpu al volledig kunt belasten.

[TheNameless]

Er schijnen ook meer "lighweight" threads te zijn, namelijk fibers.

Iemand hier ervaring mee of meer informatie?

[Verwijderd]

Alarmnummer schreef op woensdag 15 november 2006 @ 15:43:
[...]

Concurrency performance 101

Kom op zeg, niet uit z'n verband rukken.
Ik geef eerst 3 manieren aan waarop je kunt locken, en dat is redelijk geavanceerde Windows-optimalisatie. Ik denk dat veel mensen niet eens van het bestaan van die intrinsics weten, of waarom ze vaak beter een critical section dan een mutex kunnen gebruiken (op de TU is mij alleen verteld over mutexen bv).
Dus niet concurrency performance 101.

Optimistic locking, in tegenstelling tot pessimistic locking, in een applicatie (dus niet zozeer in de db) kan ook een performance boost geven, als je weet dat de kans klein is dat een ander op dezelfde data actief is, en als je met optimisticlockingfailures om kunt gaan. Java heeft bv ook bepaalde structuren (bv sommige iterators) die deze locking techniek toepassen (en maakt ze meteen stuk minder deadlock gevoelig).

Ja, da's dus het verschil tussen de intrinsics en de critical sections/mutex/semaphores, eigenlijk.
Intrinsics zijn vooral handig om de lock zo kort mogelijk vast te houden...
Met critical sections etc is de overhead dusdanig dat je de lock vaak beter ook zo lang mogelijk vast kunt houden om de tijd weer een beetje in te halen.

Dan heb je natuurlijk ook nog de tussenvorm... een spinlock... Daar ga je de zaak niet op thread-niveau starten en stoppen, maar gewoon met een lusje wachten totdat een resource vrij is gegeven.
Dat is vooral geschikt als je ervanuitgaat dat het binnen korte tijd vrijkomt... Je spaart de overhead van thread starten/stoppen uit, maar je houdt wel de core bezet.
Die was ik nog vergeten te noemen.

[Olaf van der Spek]

Confusion schreef op woensdag 15 november 2006 @ 15:45:
Toch niet als je de worker variant gebruikt?

Dan niet, maar dan kun je mod_php niet meer gebruiken aangezien die niet thread-safe is of garandeerd te zijn.

[Alarmnummer]

TheNameless schreef op woensdag 15 november 2006 @ 16:01:
Er schijnen ook meer "lighweight" threads te zijn, namelijk fibers.

Iemand hier ervaring mee of meer informatie?

Fibers zijn geloof ik gewoon 'user space' threads. Dus threads die alleen binnen de applicatie bestaan, maar niet op os nivo. Er is dus 1 echte thread, die tig fibers kan draaien.

Threads binnen Ruby zijn ook user space threads (met alle issues van dien... bv 10 user space threads draaien op 1 kernel space threads dus meerdere cpu's kunnen niet worden gebruikt).

[Olaf van der Spek]

Alarmnummer schreef op woensdag 15 november 2006 @ 15:54:
1) thread die niet in een runnable toestand staat, zal niet worden ingescheduled. Kosten voor een slapende thread zijn dus vrij laag (voornamelijk een geheugen kwestie)

Maar dat geheugen is echt geen non-issue.

2) in io-bound systemen wil je juist een 'groot' aantal threads atief hebben zodat de cpu door een thread gebruikt kan worden, als een andere thread op io staat te wachten.

Of, alweer, async IO. Als je voor een functie 10 blocks nodig hebt, dan is daarvoor 10 threads starten niet zo handig. Sequentieel inlezen kan ook, maar dan kun je geen voordeel halen uit iets als NCQ.

[Verwijderd]

Alarmnummer schreef op woensdag 15 november 2006 @ 15:54:
[...]


1) thread die niet in een runnable toestand staat, zal niet worden ingescheduled. Kosten voor een slapende thread zijn dus vrij laag (voornamelijk een geheugen kwestie)

Ik had het uiteraard over actieve threads.
Verder zijn kosten voor slapende threads laag, maar er zit nogal wat overhead/responstijd bij het slapen en wakker maken van een thread. Dat is ook niet altijd wenselijk.
Vandaar mijn conclusie dat je niet zomaar meer threads ertegenaan moet smijten.

2) in io-bound systemen wil je juist een 'groot' aantal threads atief hebben zodat de cpu door een thread gebruikt kan worden, als een andere thread op io staat te wachten. Hierdoor kan je een cpu dus effectief gebruiken. Bij cpu bound systemen zal het niet helpen om meer threads dan cores te hebben omdat je met 1 thread (per core) de cpu al volledig kunt belasten.

Natuurlijk, maar je hebt 'groot' en 'groot'... Het getal 10000 dat genoemd werd, was dusdanig groot dat dat waarschijnlijk in geen enkel geval echt effectief zal kunnen draaien.
Het punt was een beetje dat je niet zomaar met threads moet smijten, maar dat je op een gegeven moment het aantal threads moet gaan beperken, en op een betere manier de data verwerken.
Met async I/O in Windows heb je ook minder threads nodig om asynchroon bestanden etc te bewerken. Een enkele thread kan dan zowel het event krijgen als de I/O klaar is en tussentijds data bewerken. Zo heb ik ooit een CRC-filechecker gemaakt die in 1 thread een CRC check uitvoerde zo snel als de harddisk de data kon aanleveren. Zo elegant krijg je het niet met alleen slapende threads.

[Alarmnummer]

Olaf van der Spek schreef op woensdag 15 november 2006 @ 16:08:
[...]
Maar dat geheugen is echt geen non-issue.

Je denkt te zwart wit

Als een klant ergens een gig ram in moet prikken voor 100 euro zodat hij 1000 threads extra kan draaien ipv dat hij bv 80uur*80euro per uur =6400 euro aan extra development moet uitgeven (voor non blocking io), dan is de keus vrij snel gemaakt.

Nogmaals: non blocking io is niet slecht, het is alleen complexer, minder mensen beheersen het, en daarom zullen de kosten van het bouwen ook hoger zijn. Daar zul je in het bedrijfsleven gewoon rekening mee moeten houden. Uiteraard zul je ook zo nu en dan voor non blocking oplossingen moeten kiezen, maar ik moet eerlijk zijn en zeggen dat ik ze niet nog niet vaak ben tegengekomen.

Of, alweer, async IO. Als je voor een functie 10 blocks nodig hebt, dan is daarvoor 10 threads starten niet zo handig. Sequentieel inlezen kan ook, maar dan kun je geen voordeel halen uit iets als NCQ.

Zie nog een keer mijn verhaal hier boven.

Als het met 10 threads ook werkt en minder geld kost om te bouwen, dan is dat ook goed. Voor thuis projecten en in de academische wereld kan je zo veel tijd er in steken als je maar wilt, maar in het bedrijfsleven (helaas) niet. Je zult daar de alternatieven naast elkaar neer moeten leggen en vaak heeft een alternatief met een lagere complexiteit de voorkeur.

[ Voor 6% gewijzigd door Alarmnummer op 15-11-2006 16:23 ]

[Verwijderd]

Alarmnummer schreef op woensdag 15 november 2006 @ 16:19:
[...]
Nogmaals: non blocking io is niet slecht, het is alleen complexer, minder mensen beheersen het, en daarom zullen de kosten van het bouwen ook hoger zijn. Daar zul je in het bedrijfsleven gewoon rekening mee moeten houden.

Volgens mij is dat precies het uitgangspunt van deze thread...
Er zijn nog te weinig mensen die dit soort technieken goed beheersen (zoals al genoemd, php niet threadsafe, Apache en mysql die niet efficient met threads/forks omgaan), en daarom zou er eigenlijk extra aandacht voor moeten zijn om mensen bij te scholen, net als destijds met OOP.
Dat zou een goede investering zijn, gezien de trend van multicore hardware op het moment.

[Alarmnummer]

Verwijderd schreef op woensdag 15 november 2006 @ 16:23:
[...]
en daarom zou er eigenlijk extra aandacht voor moeten zijn om mensen bij te scholen, net als destijds met OOP. Dat zou een goede investering zijn, gezien de trend van multicore hardware op het moment.

Hmm tja.. ik denk dat veel opleidingen blij mogen zijn als ze het huidige niveau vast kunnen houden ipv nog meer zaken erin stoppen. Ik ben het helemaal met je een dat het beter zou zijn, maar vraag me alleen af hoe haalbaar het is. En voor 99% van de developers lijkt het me toch handiger als threading door de omgeving opgelost gaat worden aangezien concurrency control volgens mij wel een van de slechtst begrepen onderwerpen is. (Niets is zo erg als een threading cowboy die het niet goed begrijpt). Ik ben al vaak genoeg systemen tegengekomen met new Thread(new Tak()).start() problemen (je hebt dan geen controle over het aantal threads en ook geen controle over de thread zelf). En allerlei compiler optimalisaties (reordenings) en visibility problemen worden volgens mij ook maar door een enkeling begrepen.

Voor veel serverside applicaties zal het niet uitmaken of ze op een multicore draaien of niet aangezien ze toch al multithreaded zijn. Mijn stelling is ook dat het voor de meeste enterprise java developers geen enkele invloed zal hebben.

[ Voor 24% gewijzigd door Alarmnummer op 15-11-2006 16:35 ]

[Verwijderd]

Alarmnummer schreef op woensdag 15 november 2006 @ 16:29:
[...]

En voor 99% van de developers lijkt het me toch handiger als threading door de omgeving opgelost gaat worden aangezien concurrency control volgens mij wel een van de slechtst begrepen onderwerpen is. (Niets is zo erg als een threading cowboy die het niet goed begrijpt).

Inderdaad, daarom pleitte ik eerder al voor betere compilers/tools om dit mogelijk te maken, maar ik denk dat de haalbaarheid hiervan nog lager is dan bijscholing, iig op korte termijn.

Voor veel serverside applicaties zal het niet uitmaken of ze op een multicore draaien of niet aangezien ze toch al multithreaded zijn. Mijn stelling is ook dat het voor de meeste enterprise java developers geen enkele invloed zal hebben.

Ja, voor die mensen is het vooral nuttig om te begrijpen op welke manier ze het beste gebruik kunnen maken van de multithreaded componenten die ze gebruiken. Een niveau hoger dus.
Zoals al aangegeven, ook bij serverside spul als Apache, php en mysql laat de schaalbaarheid te wensen over... ik kan me voorstellen dat dat voor enterprise Java ook geldt in bepaalde gevallen.

[Alarmnummer]

Verwijderd schreef op woensdag 15 november 2006 @ 16:59:
[...]
ik kan me voorstellen dat dat voor enterprise Java ook geldt in bepaalde gevallen.

Als ze ergens in staat zijn om complexe en niet schaalbare applicaties neer te zetten dan is het wel de Java Enterprise Wereld (vooral EJB heeft daar een handje van).

[joepP]

Olaf van der Spek schreef op woensdag 15 november 2006 @ 14:59:
[...]

Daar heb je preforking voor, waardoor je die threads/processes al hebt voordat je ze nodig hebt.

[...]

Uiteraard is er een limiet, maar daardoor kan Apache ook niet zoveel connecties tegelijkertijd afhandelen en wordt vaak een aparte andere server ingezet voor static files.
Het probleem wordt deels veroorzaakt door bagage uit het verleden en het feit dat PHP in de server zelf zit in plaats van buiten de server met FastCGI. PHP is dan weer niet veilig met multi-threading, dus kom je uit op meerdere processen.

Met andere woorden, achter de schermen zit een server met Apache/PHP grandioos te falen

Over blocking vs non-blocking: uiteraard is non-blocking beter qua performance in zware applicaties, maar over het algemeen kan je best wegkomen zonder. De complexiteit van de code is ook een issue, het gaat vaak niet alleen om performance. Zoals Alarmnummer terecht opmerkt zijn er maar weinig mensen die echt genoeg verstand van zaken hebben om dit soort software goed te ontwerpen en implementeren. Onderhoud wordt ook niet makkelijker, en debuggen al helemaal niet. Ook stelt de complexere code hoge eisen aan de documentatie van de code zelf, zowel incode als daarbuiten. Anders snapt na een jaartje zelfs de originele programmeur de code niet meer goed genoeg.

We moeten het wel pragmatisch blijven bekijken he

[Verwijderd]

Tsja, eigenlijk is de conclusie van deze thread dus grootschalige incompetentie onder programmeurs, en dat is niets nieuws

[MBV]

Alarmnummer schreef op woensdag 15 november 2006 @ 16:19:
[...]

Je denkt te zwart wit

Als een klant ergens een gig ram in moet prikken voor 100 euro zodat hij 1000 threads extra kan draaien ipv dat hij bv 80uur*80euro per uur =6400 euro aan extra development moet uitgeven (voor non blocking io), dan is de keus vrij snel gemaakt.

Doet me denken aan het verhaal van SAP R/3 live: 3-laags structuur, alles netjes geprogrammeerd, maar het was zo traag dat je het toen het uitkwam nauwelijks kon gebruiken. Dat wisten ze, en er werd doodleuk bij verteld dat je het pas echt kon gebruiken als de hardware over 3 jaar snel genoeg was

@ddbruin: php is thread-safe, de libs die het gebruikt alleen niet. Heel Unix is op forks gebaseerd, niet op threads, en daar gaat PHP de mist in: die gebruikt al die unix-dingen, die niet tegen multi-threaded kunnen. Legacy-troep dus.

Was dat in PHP5 trouwens niet verholpen?

[Alarmnummer]

Tja. Met dit soort argumenten kan ik ook niet veel.

In de praktijk moet je keuzes maken en complexiteit is meestal iets dat je moet vermijden. Je zult wel moeten weten of de gevolgen van je aanpak acceptabel zijn, als ze dat niet zijn dan heb je domweg de verkeerde keuze gemaakt (zoals in dit geval).

Verder ken ik het systeem niet, maar ik weet uit ervaring dat de standaard drie lagen structuur meestal niet de bottleneck van een systeem is. Dus ik vind je verhaal eigenlijk niet zo heel sterk en ik proef er eerlijk gezegd ook gebrek aan ervaring met dat soort systemen.

[MBV]

ehm, sorry. SAP R/3 is een antiek ERP systeem uit 1992: http://en.wikipedia.org/wiki/SAP_R/3. 3-lagen slaat op de client-server structuur: je hebt een client, een tussenserver en back-end server ofzo. Volgens mij was dat de laatste keer dat ze, zelfs van SAP, iets hebben uitgebracht dat toen het uitkwam niet goed draaide op de beschikbare hardware
_{mijn vader verkocht toen dat soort systemen, dus dat komt zo nu en dan terug}

[ Voor 11% gewijzigd door MBV op 15-11-2006 18:58 ]

[H!GHGuY]

Alarmnummer schreef op dinsdag 14 november 2006 @ 20:23:
[...]

Als het triviaal zou zijn, dan zouden er niet zo veel fouten mee gemaakt worden. En sowieso krijg je in de enterprise wereld weer met hele andere problemen te maken zoals business transacties die meerdere system transacties overspannen, of optimistic locking om de performance van de db op te krikken.

Dat is concurrency op een heel ander niveau.

En er worden ook genoeg systemen ontwikkeld worden die echt custom oplossingen nodig zijn. Ik kan het weten, ik ben er regelmatig mee bezig.

Wat voor ervaring heb jij met Enterprise Java en concurrency?

met triviaal bedoel ik bvb dit:

Java:

class MyDataClass
{
   public synchronized DataObject GetSomeData();
}

// of
class MyTask : Thread
{
  public void run();
}

Als je diezelfde synchronized in C++ moet doen heb je een stuk meer code en dus ook een stuk meer kans op problemen. Java voorziet nou eenmaal dingen die triviaal zijn in gebruik. Dat wil natuurlijk niet zeggen dat je ze niet fout kan gebruiken... (ik herinner me een post van jou over memory barriers etc etc - daarin werden enkele mooie "onzichtbare" fouten getoond)

Je kan je uiteindelijk in Java en co net iets meer bezig houden met "wat" dan met "hoe". Iets wat iemand anders voor jou heeft gedaan (als doel) zal over het algemeen beter zijn dan wat je zelf doet (als hulpmiddel)

[Verwijderd]

MBV schreef op woensdag 15 november 2006 @ 18:00:
[...]

@ddbruin: php is thread-safe, de libs die het gebruikt alleen niet. Heel Unix is op forks gebaseerd, niet op threads, en daar gaat PHP de mist in: die gebruikt al die unix-dingen, die niet tegen multi-threaded kunnen. Legacy-troep dus.

Tsja, dat is weer die vinger-wijs-cultuur waar je geen steek verder mee komt.
Het boeit mij geen kont of het door PHP zelf komt, of door de libraries die PHP gebruikt, het resultaat verandert niet... En inderdaad, zoals al gezegd... als jij die libraries gebruikt, weet je van tevoren dat het niet threadsafe is, dus faalt jouw ontwerp ook, vanwege je foute keuzes.
Ik wijs de vinger dus weer keihard terug naar PHP.
Ik wil geen excuses, ik wil oplossingen. En dus moeten de programmeurs ervoor zorgen dat ze weten hoe je efficient en robuust kunt multithreaden.

[Confusion]

Verwijderd schreef op woensdag 15 november 2006 @ 17:16:
Tsja, eigenlijk is de conclusie van deze thread dus grootschalige incompetentie onder programmeurs, en dat is niets nieuws

Ik heb alleen wel een beetje het idee dat iedere programmeur dit soort dingen roept. Het typische geval: 80% van de klas denkt dat ze bij de beste 20% horen.

In dit geval: dat iemand iets niet weet, betekent niet dat hij het niet kan leren. Lees een thread als deze en je weet weer heel wat meer van concurrency. Zoniet in detail, dan wel waar je rekening mee moet houden als het er op aankomt en dan kan je er op dat moment wel meer over leren.

[joepP]

Ik betwijfel toch of de meeste mensen (programmeurs) intelligent genoeg zijn om wat complexere multithreaded applicaties te schrijven. Het is bepaald niet triviaal, je stuit op allerhande lastige problemen en soms onverklaarbaar gedrag tgv bugs. Ook is het in talen zonder garbage collector behoorlijk naar om het geheugenbeheer netjes te doen. Verder heb je te maken met racing condities, deadlocks, gedeeld geheugen, etc. Plus dat de meeste talen niet bepaald heel erg ingesteld zijn op multithreaded werk, en debuggen bijna onmogelijk is.

Er zijn al hele volksstammen die het OO gebeuren niet eens goed bevatten, en concurrency is nog wel een paar stapjes ingewikkelder. Natuurlijk kan je mensen wat basisdingen wel leren, maar op een gegeven moment zal het toch ophouden. Voor concurrency is volgens mij meer inzicht (intelligentie) nodig dan voor het meeste programmeerwerk, waardoor er automatisch minder mensen goed mee om kunnen gaan.

Misschien behoor ik nu wel tot de 80% (hoewel ik die stelling van je een behoorlijk aanmatigende dooddoener vind eigenlijk)

[Verwijderd]

Confusion schreef op woensdag 15 november 2006 @ 20:25:
[...]

Ik heb alleen wel een beetje het idee dat iedere programmeur dit soort dingen roept. Het typische geval: 80% van de klas denkt dat ze bij de beste 20% horen.

Oh, maar dat denk ik helemaal niet. Dat jij met deze stelling komt, zegt vooral veel over jezelf, denk ik.
Ik constateer slechts dat teveel programmeurs van teveel onderwerpen te weinig weten. Daarbij zonder ik mezelf zeker niet uit. Ik ben me echter wel bewust van mijn beperkingen, en dan ben je al een aardig eind op de goede weg, denk ik.

In dit geval: dat iemand iets niet weet, betekent niet dat hij het niet kan leren. Lees een thread als deze en je weet weer heel wat meer van concurrency. Zoniet in detail, dan wel waar je rekening mee moet houden als het er op aankomt en dan kan je er op dat moment wel meer over leren.

Dat was ook precies mijn punt. "Raise awareness" zoals Oprah dat zou noemen.
In dit topic kunnen we mooi de problemen en mogelijke oplossingen opnoemen, waar ik zelf dus al een begin mee probeerde te maken, en anderen hebben ook praktische info toegevoegd. Maar de signaal-ruisverhouding in de thread is nog steeds behoorlijk laag, helaas.

[RobIII]

joepP schreef op woensdag 15 november 2006 @ 21:47:
Ik betwijfel toch of de meeste mensen (programmeurs) intelligent genoeg zijn om wat complexere multithreaded applicaties te schrijven. Het is bepaald niet triviaal, je stuit op allerhande lastige problemen en soms onverklaarbaar gedrag tgv bugs.

Nog maar even en iedere schlemiel kan multi-threaded programmeren Kwestie van creatief klikken

[Confusion]

joepP schreef op woensdag 15 november 2006 @ 21:47:
Misschien behoor ik nu wel tot de 80% (hoewel ik die stelling van je een behoorlijk aanmatigende dooddoener vind eigenlijk)

Het is het resultaat van een onderzoek waarbij men studenten ondervroeg naar hun vermeende positie in de groep. Dan blijkt 80% te denken dat ze tot de slimste, beste, meest vakkundige 20% van de klas behoort. Dat onderzoek is in andere soorten groepen herhaald en hoewel de verhouding wijzigt, blijft altijd meer dan de helft denken dat ze tot de beste 20% behoren. Dat is relevant, omdat dat dat betekent dat er een redelijke kans is dat een aanzienlijk deel van de programmeurs beter is dan een deel van de aanwezigen hier denkt dat ze zijn. Tenzij het zo is dat de beste 20% vaker op GoT komt en bovendien actiever aan dit soort threads deelneemt; dan gaat het feest niet door.

[MBV]

@confusion: als ik kijk naar de verhouding noob-topics t.o.v. complexere problemen, denk ik niet dat dat heel erg opgaat. Maar al met al hoor ik iig niet bij de 20% beste van dit topic . Op het HBO was ik wel een van de 5 die ERD's, OOD/OOP en dergelijke redelijk goed begreep. Bij de rest werkte dat al helemaal niet lekker. Nu op de TU/e voelt het net iets anders
Ik denk trouwens dat 50% van de 80% 'besten' ook gelijk hadden. Op hun gebied waren ze het beste, dat zie je heel vaak. De een is beter in het coden, ander in designen, ander in plannen.
@RobIII: sorry, doet het niet op linux. Maar WTF?! Waarom een gecomprimeerd bestand als een film in een zip gooien?

[Verwijderd]

Verwijderd schreef op woensdag 15 november 2006 @ 11:36:
Etc... Uiteindelijk kun je dus a(), b() en c() tegelijk draaien, als een soort pipelining. En dan is je code dus 'horizontaal' (in het ideale geval kun je ook meerdere instanties van dezelfde bewerking naast elkaar draaien).

Dit is eigenlijk weer een ander voorbeeld van hoe je met een ander paradigma soms bepaalde dingen bijna gratis krijgt die bij de geijkte aanpak veel moeite kosten.

Hoewel het eigenlijk geen paradigma is zoals logische, functioneel, of imperatief, kun je ook (delen van) programma's uitdrukken met een dataflow network. Eigenlijk is pipelining daar een vorm van (namelijk, een dataflow network zonder vertakkingen). Als de data continu is, kunnen de verschillende filters in het netwerk tegelijk draaien (lineair parallellisme). Vector processors werken al wat langer op een dergelijke manier.

Wat ook kan is dat bij vertakte data en feedback (cycles) elke vertakking in parallel afgehandeld kan worden (iteratief parallellisme). Bv, stel dat je deze relatief simpele graph hebt:

code:

A -> B
A -> C
B[1] -> A
B[2] -> A

-> = connector
Letter = filter
[cijfer] = port (wanneer weggelaten wordt default port gebruikt)

Stel dat A een multiplier is, C het scherm, en B een of andere splitter. Je kunt nu A, B en C in aparte threads draaien, maar je kunt ook initieel A,B,C in 1 thread draaien, en dan nadat B 2 outputs heeft geproduceert, deze twee outputs gebruiken om 2 threads van werk te voorzien die elk weer een geheel A,B,C netwerk draaien.

Naar dergelijke aanpakken kijk je bijvoorbeeld ook als je een algoritme in hardware gaat implementeren. (voor de liefhebbers, zie bv http://www.liacs.nl/research/CS/publications.html).

In het generieke geval is het nog niet helemaal triviaal om te bepalen welk gedeelte van een netwerk je efficiënt over meerdere cores verdeeld. Als de filters een hele korte executie tijd hebben dan is de overhead van communicatie veel groter dan het zelf doen. Er zal dus runtime een meting moeten plaatsvinden van deze executie tijd waarbij een scheduler bepaald wat er naar aparte threads gaat.

[Verwijderd]

Verwijderd schreef op donderdag 16 november 2006 @ 00:23:
[...]


Dit is eigenlijk weer een ander voorbeeld van hoe je met een ander paradigma soms bepaalde dingen bijna gratis krijgt die bij de geijkte aanpak veel moeite kosten.

Hoewel het eigenlijk geen paradigma is zoals logische, functioneel, of imperatief, kun je ook (delen van) programma's uitdrukken met een dataflow network. Eigenlijk is pipelining daar een vorm van (namelijk, een dataflow network zonder vertakkingen). Als de data continu is, kunnen de verschillende filters in het netwerk tegelijk draaien (lineair parallellisme). Vector processors werken al wat langer op een dergelijke manier.

Tsja... wat we eigenlijk zoeken is een soort uitbreiding van een bestaand paradigma, lijkt me.
Het imperatieve paradigma is in feite een abstractie van de machinetaal. Het vertaalt redelijk direct naar instructies.
Het object-georienteerde paradigma is dan weer een abstractie van het imperatieve paradigma... Je kunt objecten weer makkelijk vertalen naar structs, en virtuele functies zijn eigenlijk functiepointers, etc.
Ik denk dat we hier zoeken naar een nieuw paradigma waarbij je op een gestructureerde manier je dataflow-netwerk kunt beschrijven in objecten. Eigenlijk komt het dus een beetje neer op het formaliseren van een aantal restricties waardoor je je objecten zodanig gebruikt dat je de problemen met thread-unsafe code/variabelen vermijdt, en verder wat automatisering voor het creeren en synchroniseren van threads.
Dit zou dan weer in extensies voor C++ (of andere talen) geimplementeerd kunnen worden, en we hebben ons nieuwe paradigma.
Maar hoe het er precies uit moet zien, dat zal de ervaring leren, denk ik.
C++ is ook min of meer ontstaan doordat mensen jarenlang ervaring hadden met C en bepaalde dingen sowieso al 'object-georienteerd' oplosten.
OpenMP is al een begin, maar het lost het probleem van thread-safety nog niet op... Je moet zelf nog leren wat de restricties zijn, en die aan jezelf opleggen, want in C++ 'mag' alles nog.

[joepP]

Confusion schreef op woensdag 15 november 2006 @ 22:29:
[...]

Het is het resultaat van een onderzoek waarbij men studenten ondervroeg naar hun vermeende positie in de groep. Dan blijkt 80% te denken dat ze tot de slimste, beste, meest vakkundige 20% van de klas behoort. Dat onderzoek is in andere soorten groepen herhaald en hoewel de verhouding wijzigt, blijft altijd meer dan de helft denken dat ze tot de beste 20% behoren. Dat is relevant, omdat dat dat betekent dat er een redelijke kans is dat een aanzienlijk deel van de programmeurs beter is dan een deel van de aanwezigen hier denkt dat ze zijn. Tenzij het zo is dat de beste 20% vaker op GoT komt en bovendien actiever aan dit soort threads deelneemt; dan gaat het feest niet door.

Het is zwaar off-topic, maar leuk genoeg, dus ik ga er toch even op in. De uitspraak als zou concurrent programming "te moeilijk" zijn voor de meeste programmeurs is voor mijn rekening, niet voor de hele groep. Verder hebben we hier ook te maken met een selecte groep. Je stokpaardje hoef je dus niet van stal te halen

Verder heb ik vroeger op de Uni, waar je nog wel iets mag verwachten, genoeg voorbeelden gezien waaruit ik duidelijk kan opmaken dat concurrent programming niet geschikt is voor de meeste mensen. En dan heb ik het al over een select gezelschap. Zelf merk ik dat concurrent programming (voor mij) het lastigste is wat ik ben tegengekomen in mijn lange ervaring als programmeur, zowel privé als prof. Voor de duidelijkheid: ik bedoel lastig hier in de context van analytisch uitdagend, dus niet als kwantiteit aan kennis van frameworks oid. Zelfs met grondige kennis van synchronizatie primitieven, standaard oplossingen, threads, etc, ben je toch vooral aangewezen op analytisch talent, en dat ontberen de meeste mensen in meer of mindere mate. Ook programmeurs.

Ik ben dan ook arrogant (realistisch ) genoeg om te denken dat als ik het al lastig vind, de meeste mensen er niet goed mee zullen kunnen omgaan. Dat ligt deels aan het ontbreken van handige frameworks, maar voor het grootste deel aan de intrinsieke problematiek rond dit onderwerp.

[Verwijderd]

Verwijderd schreef op donderdag 16 november 2006 @ 00:44:
[...]
Tsja... wat we eigenlijk zoeken is een soort uitbreiding van een bestaand paradigma, lijkt me.
Het imperatieve paradigma is in feite een abstractie van de machinetaal. Het vertaalt redelijk direct naar instructies.
Het object-georienteerde paradigma is dan weer een abstractie van het imperatieve paradigma..

Het is overigens niet altijd duidelijk wanneer iets nou echt een paradigma is. Een dataflow network wordt meestal onder een software architectuur geschaard (algemene naam: pipe and filters) terwijl sommige het ook wel een design pattern noemen. Mischien dat je het pas een paradigma noemt als er directe language support voor is.

OpenMP is al een begin, maar het lost het probleem van thread-safety nog niet op... Je moet zelf nog leren wat de restricties zijn, en die aan jezelf opleggen, want in C++ 'mag' alles nog.

Vandaar dat echte language support toch wel beter is in dit geval. De (pre)compiler of de runtime kan dan aannames doen omdat die gespecificeerd zijn in een formele taal. Neem nou weer het dataflow network. Zoiets kun je natuurlijk perfect in C++ bouwen. Elk filter is dan een object die een aantal vaste functies heeft waaraan je via een soort listener systeem andere objecten koppelt. Dit lijkt dus een beetje op het veelgebruikte Observer pattern. Ik geloof dat direct X ook zo werkt voor haar rendering graph (de kenners hier kunnen daar vast meer over vertellen).

De compiler ziet natuurlijk niet de graph in je code. Die ziet alleen statements. Een adConnect() call is dan ook niet wezenlijk anders dan een doExecute(). Heb je echter language support, dan weet de compiler dat adConnect() en doExecute() essentiële basis concepten zijn.

Ik denk echter niet dat een dataflow taal een 'volledige' taal kan zijn. In imperatieve talen (turing complete) kun je in feite alles uitdrukken dat berekenbaar is. In een standaard dataflow taal gaat dat niet of heel lastig. Bovenop een andere taal zie ik wel zeker mogelijkheden. Je zou dan de graph gewoon in een domain taal specificeren, en deze kan gecompiled worden naar gewoon C++. De gegenereerde code kan dan zorg dragen voor het parallel uitvoeren van gedeeltes. Deze code kun je dan weer gewoon aanroepen in je normale C++ omgeving. (i.p.v. C++ kan het natuurlijk ook Java, C#, PHP, etc zijn).

[Verwijderd]

joepP schreef op donderdag 16 november 2006 @ 10:42:
[...]

Zelfs met grondige kennis van synchronizatie primitieven, standaard oplossingen, threads, etc, ben je toch vooral aangewezen op analytisch talent, en dat ontberen de meeste mensen in meer of mindere mate. Ook programmeurs.

Ja, kort door de bocht komt het er gewoon op neer dat je met veel factoren rekening moet houden, waardoor de kans groot is dat je fouten maakt. Niets is immers menselijker dan het maken van fouten.
Wat hier de doorslag geeft is de mate waarin iemand netjes en gestructureerd kan werken (minder fouten maken), en doelgericht problemen kan vinden en oplossen.
Dat heeft dus niets te maken met intelligentie, maar eerder met iets als discipline.
En het begrip 'verstrooide professor' geeft al aan dat intelligentie en dit type discipline niet altijd even goed samengaan... Misschien werkt het elkaar soms juist wel tegen, omdat een intelligent iemand een te breed vlak aan interesses heeft, en daardoor te gauw afgeleid is.

Waarvan deze post ook weer een mooi voorbeeld is, want we zijn enorm afgeleid en zwaar off-topic, en we vinden het nog leuk ook

Weer redelijk on-topic: We moeten dus aan de ene kant proberen een bepaald 'paradigma' te maken waardoor we dus zo gestructureerd mogelijk kunnen werken, en fouten kunnen uitsluiten, omdat we gewoon volgens een vaste methode werken... wat routine in de hand werkt.
En aan de andere kant komt het er gewoon op neer dat een programmeur zich moet trainen in de materie, denk ik. Ik kan natuurlijk alleen voor mezelf spreken, maar mijn eigen ervaring is dat zelfs de meest lastige dingen redelijk eenvoudig worden als je ze maar vaak genoeg doet. Je wordt er vanzelf in getraind om op bepaalde details te gaan letten, omdat je van je eigen fouten leert. Je moet dus eerst die fouten maken, dus vooral doen.

[ Voor 23% gewijzigd door Verwijderd op 16-11-2006 11:58 ]

[Verwijderd]

joepP schreef op donderdag 16 november 2006 @ 10:42:
Ik ben dan ook arrogant (realistisch ) genoeg om te denken dat als ik het al lastig vind, de meeste mensen er niet goed mee zullen kunnen omgaan.

Toch geldt ook dat oefening kunst baart. Ik weet van mezelf dat ik wel een sterk analytisch vermogen heb, maar dat ik zeker ook weer niet een genie ben. Toen ik nog op de uni zat rekende ik mezelf ook niet tot de beste 20%.

Waar ik wel een gedeelte van de voorsprong haal is om gewoon heel veel met de materie bezig te zijn. Als je al 10x eerder een probleem parallel hebt aangepakt is het de 11de keer echt makkelijker. Je vermijd automatisch de bekende valkuilen en weet eerder waar je op moet letten. Vandaar ook de eerdere stelling dat mensen die vanaf het begin af aan getraind zijn in parallel programmeren er waarschijnlijk toch een stuk minder moeite mee hebben. Vergeet niet dat een goede developer een combinatie is van talent, opleiding, ervaring en inzet.

[Confusion]

joepP schreef op donderdag 16 november 2006 @ 10:42:
De uitspraak als zou concurrent programming "te moeilijk" zijn voor de meeste programmeurs is voor mijn rekening, niet voor de hele groep. Verder hebben we hier ook te maken met een selecte groep. Je stokpaardje hoef je dus niet van stal te halen

Ik ging in op de stelling dat "er grootschalige incompetentie onder programmeurs" is. Dat geldt volgens mij wel voor de hele groep en hangt niet van de groep af.

Ik ben dan ook arrogant (realistisch ) genoeg om te denken dat als ik het al lastig vind, de meeste mensen er niet goed mee zullen kunnen omgaan.

Het is dus duidelijk wel nodig het stokpaardje van stal te halen, want je mist wat zo'n onderzoek over de menselijke geest duidelijk maakt: dat 80% van de aanwezigendat dacht en dat diversen daarvan het van jou dachten, toen jij 1 keer iets zei dat niet klopte.

Denk jij dat jou probleem zich niet leent voor het Factory pattern? Think again. Denk jij dat log4j net niet geschikt is voor jouw situatie? Think again. Denk jij dat je hier nu net wel die uitzondering kan maken om een NullpointerException af te vangen? Think again. Het is vreemd dat als de praktijk aantoont dat bepaalde dingen op een bepaalde manier werken, vele toch blijven roepen dat het voor hen niet geldt. 80% denkt dat ze tot de beste 20% behoren: dat geldt ook over jouw gedachten over hoe goed jij en anderen zijn in concurrent programming. Als je denkt dat je een uitzondering op de regel bent, dan moet je daarvoor redenen aanvoeren. Je eigen gevoel is geen reden, want de uitkomst van dit onderzoek is juist dat je eigen gevoel je belazert.

[Verwijderd]

henk en ik zitten duidelijk op 1 lijn
Ik wil er nog even aan toevoegen dat ik persoonlijk niet zo erg in het begrip 'talent' geloof.
Tenminste, niet in de zin van aangeboren vaardigheid.
Als ik weer voor mezelf spreek, merk ik dat alles waar ik 'talent' voor zou hebben, eigenlijk vooral datgene is dat ik zelf leuk vind om te doen, en daar dus erg gemotiveerd voor ben, en me er dus automatisch voor inzet om me op dat gebied te ontwikkelen.

Maar dat is mijn visie... Je kunt natuurlijk ook beweren dat ik die dingen juist zo leuk vind, en juist zo gemotiveerd ben omdat ik er een bepaalde aangeboren vaardigheid voor heb, en dat het me dus redelijk goed af gaat.

Die visie deel ik niet, ik denk zelf dat je je met voldoende inzet op bijna ieder gebied kunt ontwikkelen.
Programma's als Dancing With The Stars of Dancing On Ice lijken me daar een aardig voorbeeld van.
De deelnemers zijn dag in dag uit druk bezig met dansen en schaatsen, en na een paar maanden halen ze een behoorlijk hoog niveau (zelfs de wat mindere goden doen het na een paar maanden nog heel aardig). Ik denk dat dat voor een heel groot deel inzet is, en maar voor een klein beetje met aangeboren aanleg te maken heeft. Je ziet wel dat de een beter vooruit gaat dan de ander, maar uiteindelijk komen ze er allemaal wel, denk ik.

[Verwijderd]

Confusion schreef op donderdag 16 november 2006 @ 12:07:
[...]

80% denkt dat ze tot de beste 20% behoren: dat geldt ook over jouw gedachten over hoe goed jij en anderen zijn in concurrent programming.

Maar volgens mij gaat het daar niet om, maar wel om het feit dat 100% hier denkt dat hooguit die 20% beste programmeurs goed met multithreading om kunnen gaan, op dit moment.

En probeer je nu JoepP te verplichten dat hij bewijst dat hij bij die beste 20% hoort?
Dat hoop ik niet, want daar komt alleen maar een welles-nietes spelletje van, met een hoop haantjesgedrag... Zelfs al zou hij bij die beste 20% horen, dan zou jij dat niet willen toegeven. Ik denk dat jouw onbewuste motivatie in deze discussie ook is dat jij zelf ook denkt dat je bij die beste 20% hoort, en dat je graag ziet dat JoepP toch bij die 80% hoort, zodat je je eigen gevoel kunt verifieren.

[Alarmnummer]

Ok... en nu weer ontopic (als het maar gaat over threads/cores etc)

[Verwijderd]

Alarmnummer schreef op donderdag 16 november 2006 @ 12:20:
Ok... en nu weer ontopic (als het maar gaat over threads/cores etc)

Ziet er iemand nog wat in zo'n dataflow taal die apart gecompileerd wordt en dan gewoon te gebruiken is in je huidige software?

(het aparte compilatie idee is niet helemaal onbekend natuurlijk, in Java heb je bijvoorbeeld ook het concept van JSP source code die door een aparte compiler wordt gecompileerd naar 1 of meerdere Java classes)

[Alarmnummer]

Verwijderd schreef op donderdag 16 november 2006 @ 13:00:
[...]
Ziet er iemand nog wat in zo'n dataflow taal die apart gecompileerd wordt en dan gewoon te gebruiken is in je huidige software?

Ik denk dat mensen de concepten gewoon goed moeten begrijpen. En of je dan een DSL (Domain Specific Language) voor maakt is wat minder belangrijk. Ik ben zelf erg blij met http://channels.sourceforge.net. Ik ben op dit moment bezig om het project op te schonen, te laten draaien op raven (fuck you maven! en eat my shorts ant).

Met dit project icm mijn concurrency conctrol library kan je heel mooi processen aan elkaar rijgen.

Een andere belangrijk ''flow' domain is Business Process Execution Language. Maar dat richt zich wel op een veel hoger abstractie nivo (channels is erg low level). En het lijkt me ook lastig (lees onmogelijk) om een language te maken die op alle abstractie nivo's bruikbaar is. Ik zou me dus echt meer gaan focussen op het uitleggen van concepten zoals pipes & filters / queues / assembly lines / producers & consumers etc (en dan zit je ook al vrij low level)

Ik denk niet dat er zo veel behoefte is voor nog een language aangezien er al zo veel is en aangezien mensen toch niet weten hoe ze het moeten gebruiken.

[ Voor 12% gewijzigd door Alarmnummer op 16-11-2006 13:13 ]

[Confusion]

Verwijderd schreef op donderdag 16 november 2006 @ 12:16:
Maar volgens mij gaat het daar niet om, maar wel om het feit dat 100% hier denkt dat hooguit die 20% beste programmeurs goed met multithreading om kunnen gaan, op dit moment.

En dat ze het ondertussen zelf ook kunnen .

En probeer je nu JoepP te verplichten dat hij bewijst dat hij bij die beste 20% hoort?

Nee, en ik begrijp niet waarom jij en joepP mijn opmerking persoonlijk opvatten. Het is een algemene waarheid. Ik denk zelfs dat het aannemelijk is dat jullie tot de beste 5% behoren, vanwege de demografie van GoT bezoekers en thread deelnemers. Dat neemt niet weg dat het gevoel dat "veel programmeurs incompetent zijn" vooral berust op ongegronde ideeen aangaande de positie van jezelf in de groep en effecten als selectieve waarneming en confirmation bias. En dat leidt tot de bijzonder positieve conclusie dat waarschijnlijk veel meer programmeurs competent zijn dan we geneigd zijn te denken. Dat is het enige punt dat ik wilde maken.

[Verwijderd]

Confusion schreef op donderdag 16 november 2006 @ 13:42:
[...]

En dat ze het ondertussen zelf ook kunnen .

Dat heeft niemand gezegd. Dat jij dat aanneemt, zegt meer over jou dan over de mensen hier in deze thread.

Nee, en ik begrijp niet waarom jij en joepP mijn opmerking persoonlijk opvatten. Het is een algemene waarheid.

Lijkt me nogal logisch, als je ineens met die stelling aan komt zetten als 'reactie' op iemand z'n post, en in het geval van joepP dat je nog even lekker door gaat drammen.

Verder is het zoals al aangegeven helemaal geen algemene waarheid. Het is een stukje statistiek, wat zoals altijd onderhevig is aan de demografie, en die is zoals al opgemerkt, in deze thread waarschijnlijk heel anders dan destijds tijdens dat onderzoek.

Dat neemt niet weg dat het gevoel dat "veel programmeurs incompetent zijn" vooral berust op ongegronde ideeen aangaande de positie van jezelf in de groep en effecten als selectieve waarneming en confirmation bias.

Maar dat is juist geen 'gevoel'. Dit kun je ook makkelijk statistisch onderzoeken... Er is genoeg bewijs (oa makkelijk te vinden in sourceforge-projecten) dat veel mensen gewoon onvoldoende kennis hebben om voor bepaalde problemen goede, efficiente oplossingen te zoeken. Sowieso is dat wel logisch, omdat er veel meer projecten met allerlei specialistische eisen zijn dan dat er specialisten zijn op zo'n vakgebied. Dat is wel een algemeen geldende waarheid. Een logisch gevolg daarvan is dus dat er ook veel programmeurs zijn die niet weten wat ze met multithreading aan moeten.

En dat leidt tot de bijzonder positieve conclusie dat waarschijnlijk veel meer programmeurs competent zijn dan we geneigd zijn te denken. Dat is het enige punt dat ik wilde maken.

Dat is een onzin-conclusie. Afgezien van jouw 80-20-statement heeft niemand aangegeven in welke verhoudingen zij denken.
Jij denkt misschien dat 10% competent is, en dan blijkt het 20% te zijn...
Misschien dacht een ander dat het 30% was, en dan valt het tegen.
Je maakt dus nogal eens wat overdreven aannamen en generalisaties. Precies het soort fouten dat een programmeur niet moet maken.

[whoami]

Mensen, laten we het eens ontopic houden.
Zo'n lappen OT tekst is niet echt goed voor 't topic, en ik heb niet echt veel zin om te gaan trashen

[joepP]

Confusion schreef op donderdag 16 november 2006 @ 13:42:
Nee, en ik begrijp niet waarom jij en joepP mijn opmerking persoonlijk opvatten. Het is een algemene waarheid. Ik denk zelfs dat het aannemelijk is dat jullie tot de beste 5% behoren, vanwege de demografie van GoT bezoekers en thread deelnemers. Dat neemt niet weg dat het gevoel dat "veel programmeurs incompetent zijn" vooral berust op ongegronde ideeen aangaande de positie van jezelf in de groep en effecten als selectieve waarneming en confirmation bias. En dat leidt tot de bijzonder positieve conclusie dat waarschijnlijk veel meer programmeurs competent zijn dan we geneigd zijn te denken. Dat is het enige punt dat ik wilde maken.

Je punt is wel duidelijk, maar het snijdt volgens mij geen hout. Ik spreek uit ervaring, niet uit gevoel. Er is enorm veel rotzooi aan code geschreven, en veruit het grootste deel daarvan komt voort uit fundamentele denkfouten of gebrek aan kennis van de programmeur. Hoevaak kom je geen O(n^2) sorteeralgoritmen tegen, maken mensen gebruik van een array ipv een hash, etc etc.

Nu het bruggetje naar het topic: juist concurrent programming is ingewikkeld, en heel kwetsbaar voor mensen die de boel net niet goed beheersen. Ik zie ook niet heel snel een fatsoenlijk framework daar verandering in brengen. Want wat moet zo'n framework nou precies voor je oplossen?

De meeste eenvoudige problemen van concurrent programming komen voort uit gelijktijdig access tot dezelfde gegevens. Dit kan je op vele manieren oplossen, afhankelijk van de hoeveelheid writers, readers, of het erg is oude data te lezen, etc. De eenvoudigste oplossing is alles binnen een Critical Section te zetten, maar dat zorgt soms voor veel te lange wachttijden. Of je krijgt deadlocks, omdat threads op elkaar zitten te wachten. Hier zit een naar punt: aan de ene kant wil je performance door zo min mogelijk te wachten, aan de andere kant moet je niet te weinig access control doen: dan krijg je bugs.

Nog zo'n goor detail: geheugenbeheer. Hoe ga je zorgen dat allerlei aangemaakte objecten niet te vroeg vrijgegeven worden, maar ook niet blijven hangen? Voor talen zonder garbage collector wordt je bijna verplicht zelf iets met reference counting te doen, en dat is vervelend. Plus foutgevoelig, een keertje wat vergeten en je hebt een memoryleak. Aangezien concurrent applicaties vaak behoorlijk belangrijk zijn, of hele lange uptimes hebben, mag je hier geen fouten maken. Afsluiten van de applicatie op een nette manier kan ook flink problematisch zijn, wat doe je met threads die nog bezig zijn, of al een tijdje wachten op userinput/response?

Dan debugging/bugs fixen. Veruit de meeste applicaties zijn user-driver. Je drukt op een knop, en er gebeurt een specifieke actie. Als er iets mis gaat ontstaat een error, een mooie stacktrace, en je kan de boel bijna altijd repliceren. En dus debuggen en fixen. Bij concurrent programma's heb je de mogelijkheid dat een bug maar één op de miljoen keer optreedt. Repliceren kan je dus wel vergeten, en debuggen gaat al helemaal lastig met meerdere threads.

Ook leuk: frameworks die niet thread-safe zijn. Of datastructuren. Fileaccess. Vastlopers/trage respons van een ander proces. Foutafhandeling. Communicatie. Etc.

Een goed framework moet in ieder geval de debugging/logging een stuk makkelijker maken. Allerlei datastructuren aanbieden die threadsafe zijn zonder te traag te worden. Geheugenbeheer makkelijker maken. Communicatie tussen meerdere threads makkelijker/veiliger maken. Threads aanmaken, rapporteren en afsluiten makkelijker/duidelijker maken. En nog wel wat meer.

Maar zelfs als alles in hapklare brokken klaarligt is het voor veel gevallen nog steeds niet makkelijk. Daarom denk ik ook dat concurrent programming helemaal niet zo belangrijk wordt. Ik heb het al eerder gezegd: het is -of- triviaal, -of- erg lastig -of- de applicatie leent zich er helemaal niet voor.

[Olaf van der Spek]

joepP schreef op donderdag 16 november 2006 @ 15:07:
Nog zo'n goor detail: geheugenbeheer. Hoe ga je zorgen dat allerlei aangemaakte objecten niet te vroeg vrijgegeven worden, maar ook niet blijven hangen? Voor talen zonder garbage collector wordt je bijna verplicht zelf iets met reference counting te doen, en dat is vervelend. Plus foutgevoelig, een keertje wat vergeten en je hebt een memoryleak. Aangezien concurrent applicaties vaak behoorlijk belangrijk zijn, of hele lange uptimes hebben, mag je hier geen fouten maken.

Smart pointers?

[joepP]

In Delphi?

[Olaf van der Spek]

joepP schreef op donderdag 16 november 2006 @ 16:42:
In Delphi?

Hmm, Delphi.
Na Turbo Pascal 7 ben ik overgestapt naar C++, dus over Delphi weet ik echt niks.

[Verwijderd]

[quote]joepP schreef op donderdag 16 november 2006 @ 15:07:
[...]

Nu het bruggetje naar het topic: juist concurrent programming is ingewikkeld, en heel kwetsbaar voor mensen die de boel net niet goed beheersen. Ik zie ook niet heel snel een fatsoenlijk framework daar verandering in brengen. Want wat moet zo'n framework nou precies voor je oplossen?

Hmmm, op zich wel een interessante redenering. Aan de ene kant blijf ik bij het standpunt dat (serieuze!) mensen die gewoon vanaf dag 1 leren werken met concurency en/of er gewoon moeite voor doen het zeker wel onder de knie kunnen krijgen.

Aan de andere kant, je hebt inderdaad een hele groep mensen die gewoon niet iets wil leren en absoluut niet na willen denken over structuur of abstractie. Misschien dat dat de reden is dat PHP geen threading libraries heeft. Het overgrote deel van het PHP publiek is van het type prutser die denkt dat een informatica opleiding, design patterns, etc etc onzin is, want "zij hebben dat allemaal ook niet gedaan en hun PHP site'tje draait toch?". Daarom zie je in PHP ook dat MVC frameworks niet erg sterk in de belangstelling staan en ook het hele OO concept is pas veel later toegevoegd; pas toen er een (relatief) handjevol programmeurs PHP gingen gebruiken die wel serieus bezig was.

[H!GHGuY]

joepP schreef op donderdag 16 november 2006 @ 15:07:
Een goed framework moet in ieder geval de debugging/logging een stuk makkelijker maken. Allerlei datastructuren aanbieden die threadsafe zijn zonder te traag te worden. Geheugenbeheer makkelijker maken. Communicatie tussen meerdere threads makkelijker/veiliger maken. Threads aanmaken, rapporteren en afsluiten makkelijker/duidelijker maken. En nog wel wat meer.

Ik denk dat dat al een behoorlijke opsomming is van de minimum vereisten van een degelijk framework.

Al doende leert men. Dat was in de oertijd zo, dat is nu nog zo. Het enige verschil is dat je niet zomaar in 3 schoolvoorbeeldjes threading kan gaan samenvatten.
Onze cursus besturingssystemen die ook threading problemen behandelde was niet voor niets een vak waar velen last van hadden. Dit was dan bovendien nog theoretisch. Denk maar niet dat de helft van de klas al verder was gekomen dan "synchronized" in Java. Als je dan de mensen die het vak niet meehadden die problemen in de praktijk laat omzetten weet je dat er nog wel wat "doende" nodig is om te "leren".

Het is iets wat je kan leren. Het probleem is dat veel problemen subtiel zijn. Zelfs de knapste koppen en de meest thread ervaren mensen zullen nog subtiele fouten vergeten. Daarom zijn we mensen en geen machines.

[joepP]

Olaf van der Spek schreef op donderdag 16 november 2006 @ 17:27:
[...]

Hmm, Delphi.
Na Turbo Pascal 7 ben ik overgestapt naar C++, dus over Delphi weet ik echt niks.

Delphi is een soort Object Pascal, opzich een hele prettige taal. Alleen heb je (in versie 7 iig) geen operator overloading, geen generics, en een groot gebrek aan bepaalde datastructuren. Je hebt wel interfaces en reference counting, daarmee lukt het ook wel, maar praktisch is anders.

[Olaf van der Spek]

Ik vond net een interessant artikel over threading in C++: http://www.artima.com/cppsource/threads_meeting.html

[Verwijderd]

Olaf van der Spek schreef op donderdag 23 november 2006 @ 15:43:
Ik vond net een interessant artikel over threading in C++: http://www.artima.com/cppsource/threads_meeting.html

Inderdaad wel interessant deze. Leuk dat ook Herb Sutter weer wordt genoemd en dat het zelfde artikel over "the free lunch is over" ook daar wordt aangehaald.

[MSalters]

Niet zo gek dat Herb Sutter wordt aangehaald - de meeting was bij Microsoft, op zijn vakgebied, zijn initiatief zelfs. Iedereen die actief bezig is met de toekomst van C++ weet dat threading het grote probleem is wat opgelost moet worden met C++0x

[Verwijderd]

joepP schreef op donderdag 16 november 2006 @ 20:02:
Delphi is een soort Object Pascal, opzich een hele prettige taal. Alleen heb je (in versie 7 iig) geen operator overloading, geen generics, en een groot gebrek aan bepaalde datastructuren. Je hebt wel interfaces en reference counting, daarmee lukt het ook wel, maar praktisch is anders.

Sterker nog, Delphi is Object Pascal, met een uitgebreide library (VCL) en een IDE.
Operator overloading mis ik zelf niet echt. Wat is er mis met zelf een Add() method te schrijven i.p.v. de '+' te overloaden?
Generics komen pas in de .NET 2.0 versie, en het is maar de vraag of dat ook in de Win32 versie zal worden geimplementeerd. Danny Thorpe was daar wel mee bezig, maar die ging toen naar Google en vervolgens naar MS... Maar generics worden in 99% van de Java/.NET code die ik zie gebruikt in lists en collections. In Delphi is 't verdraaide simpel om een afgeleide van bv een TList of TStrings te maken waarbij je forceert dat 't object dat je erinstopt van een bepaald type is. OK, in C# kost je dat een paar regels code minder, maar het resultaat is gelijk.

Interfaces als pseudo-alternatief voor polymorphisme zie je in meer talen (Java, C#, etc.), en reference counting is niet te ontlopen. Alleen kun je 't in sommige omgevingen aan de garbage collector overlaten (en da's vaak best handig).

Al met al is Delphi idd best een prettige taal, met prima multithreading / multicore ondersteuning, om een beetje ontopic te blijven.

[vleppyniles]

Is het zo dat wanneer je een programma schrijft, je dat schrijft voor een specifiek aantal cores?

Of kan je programma's schrijven die gebruik maken van 2 cores (als je een dual core in je systeem hebt) maar ook die 4 cores benaderen als je dus een quad core hebt?

[Exirion]

vleppyniles schreef op woensdag 03 januari 2007 @ 10:34:
Is het zo dat wanneer je een programma schrijft, je dat schrijft voor een specifiek aantal cores?

Of kan je programma's schrijven die gebruik maken van 2 cores (als je een dual core in je systeem hebt) maar ook die 4 cores benaderen als je dus een quad core hebt?

Uiteraard is dit mogelijk. En er zijn (afhankelijk van het OS) ook gradaties in transparantie. Soms zul je het OS willen laten bepalen hoe het werk verdeeld wordt, en soms zul je het onderste uit de kan willen halen door zelf het werk zo efficient mogelijk te verdelen.