[alg] Gebruik maken van multiple cores

[Verwijderd]

Momenteel is het zeer duidelijk dat binnen afzienbare tijd de klok snelheden van de mainstream CPUs niet meer sterk omhoog zullen gaan, maar dat 'voorlopig' (volgens roadmaps tenminste de komende 5 jaar) er vooral ingezet zal worden op multiple cores. Zitten we momenteel op 2 a 4 cores, in de toekomst zullen dat er mogelijk velen tientallen zijn.

Ik vraag me dus af hoe de meeste developpers hier met dit gegeven omgaan. Wat ik in de praktijk zie is dat >90% van de mensen die ik tegen kom nog steeds doet alsof zijn of haar neus bloed. Het speelt natuurlijk wel mee dat eigenlijk ook wel 90% van de mensen tegenwoordig aan serverside programmeren doet, waarbij meerdere requesten van meerdere users altijd wel de cores kunnen opvullen, maar toch...

-echt- ontwerpen voor parallel programming zie ik nog bijna niemand doen. Met komt dikwijls niet verder als: "Nou, tsja... ik spawn weleens een threadje ergens voor". Een schrikbarend aantal mensen schijnt ook nog steeds vol overtuiging te denken dat multiple cores een tijdelijke hype is en dat "intel binnenkort gewoon weer de klok snelheden omhoog gaat gooien" (ook op tweakers dachten velen hier minder dan een jaar geleden nog zo over).

Op dit moment is het mischien nog net aan te verantwoorden. Als je de 2de core negeert dan laat je slechts (potentieel) 50% power liggen, en je kan er nog mee wegkomen door te stellen dat lang niet elke PC al dual core is.

Maar software plan je als het goed is toch een tijdje van te voren. Over een jaar als een grote meerdeheid dual draait en quads ook al lang niet meer puur exotisch zijn zullen klanten ook steeds meer gaan verlangen dat je ook alle cores in een systeem benut. Zelfs voor serverside kan dit gaan gelden. Je wilt namelijk niet dat 1 user lang moet wachten omdat ie een zware berekening uitvoert die slechts op 1 core kan draaien, terwijl de 15 andere cores in je server lichtelijk uit hun neus lopen te eten.

Vandaar dus mijn vraag, hoe serieus nemen jullie nu al ontwerpen voor meerdere cores?

Om in cijfers duidelijk te maken hoe de mensen hierover denken is mischien een pol wel handig:

Poll: Programmeer je voornamelijk client- of server side?
• Voornamelijk serverside
• Voornamelijk clientside
• Ongeveer gelijk

^{Ook een poll maken? Klik hier}

Poll: Hou jij in je software ontwerp rekening met meerdere cores?
• ja, wil aanwezige hardware optimaal benutten
• Een beetje, voor background tasks spawn ik wel eens een threadje
• nee, ik wacht tot compilers mijn code automatisch verdelen over threads
• nee, meeste software draait snel genoeg op single core
• nee, meer cores=onzin, intel moet snel weer de clock omhoog gooien
• nee, requesten van meerdere users gaan al automatisch naar cores

^{Ook een poll maken? Klik hier}

[ Voor 28% gewijzigd door Verwijderd op 09-11-2006 17:07 . Reden: Een pol om te kijken hoeveel mensen nu concurency belangrijk vinden ]

[MBV]

Ik hoop dat over een poosje de Intel-compiler zo slim omgaat met branching dat alles vanzelf gaat. Dat hoop ik voor alle mensen met legacy-software, en mensen die niet zo slim zijn om alles in threads uit te denken .
In het begin (nu) wordt dual core vooral gebruikt voor dingen die echt serieus lang duren, of voor multitasking. Voor de standaard-dingetjes hoeft het ook niet zo nodig: Word hoef je toch nooit op te wachten (behalve dan HDD-gebruik). De echt rekenintensieve dingen konden alleen op een cluster, en zullen met dual-core dus geen probleem hebben.
Voor de andere dingen zal je heel sterk de afweging moeten maken: is die extra tijd in testen/debuggen enzo het me waard? Want met zwaar multithreaded programmeren komen ook moeilijke race-problemen enzo.

Ik ben benieuwd wat de rest ervan denkt, ik ben op het moment niet bezig met een applicatie die daar geschikt voor is (o.a. qua taal )

[Verwijderd]

MBV schreef op dinsdag 07 november 2006 @ 00:26:
Voor de andere dingen zal je heel sterk de afweging moeten maken: is die extra tijd in testen/debuggen enzo het me waard? Want met zwaar multithreaded programmeren komen ook moeilijke race-problemen enzo.

Het is mischien een beetje zo dat het voor jouw en mischien ook wel voor mezelf "moeilijke race-problemen zijn". Toen ik nog informatica studeerde zag ik al dat er een zekere nadruk werd gelegd op concurency. In meerdere vakken kwam het thema terug Toch werd het in de praktijk nog helemaal niet als iets serieus gezien, maar echt als een academische oefening en meer niet. (dit was de tijd dat een 100Mhz CPU nog snel was btw)

Ik heb echter in de praktijk meegemaakt dat een generatie voor mij dezelfde soort problemen had met de overstap van procedurele naar OO code. Die oudere generatie kon niet met objecten omgaan, terwijl de nieuwe, jongere generatie het zo oppikte en de huidige generatie zich eigenlijk amper niet kan voorstellen wat het is om niet-OO te programmeren.

Zou het niet kunnen dat de nu komende generatie die vanaf het begin getraind wordt om parallel te denken hier veel makkelijker mee omgaat als de huidige generatie? Voor hun zijn race conditions en synchronisations misschien gewoon een 2de natuur, net zoals wij met het grootste gemak polymorphisme en inheritance etc toepassen. En ja, het zijn zulke simpele concepten maar ik heb 'oude' C programmeurs destijds hier echt kapot op zien gaan, tot op het punt van ontslag nemen aan toe.

[.oisyn]

Tja, het hangt natuurlijk puur af van de software die je maakt. De gemiddelde applicatie zal ook geen meerdere cores nodig hebben aangezien hij sowieso al niet eens 1% van de totale load van het systeem voor z'n rekening neemt. Ik denk dat het gros van de mensen hier wel in die doelgroep valt.

Uiteraard zijn wij er wel mee bezig, al is het alleen maar omdat we die kant worden opgeduwt door de consolefabrikanten (hoewel op de PC natuurlijk precies dezelfde situatie heerst...). Het blijft een moeilijk iets though, processen zijn erg moeilijk op te delen. Wat wij voornamelijk zien is niet zozeer dat bestaande code opgedeeld wordt over de cores (gebeurt natuurlijk wel, maar met een hele grove korrel), maar dat we de overige cores voor hele andere (nieuwe) dingen gaan gebruiken. Aan de andere kant doen we het ook al jaren; rendering, sound en disc IO lopen ook allemaal parallel aan de main core.

[Korben]

Het enige wat inderdaad wel meer gedaan wordt is afzonderlijke processen binnen een applicatie parallel laten lopen. Denk aan physics, AI, netwerkcode... Het probleem is dat sommige dingen niet effectief te parallelliseren zijn.

Denk aan het toepassen van een complex effect op een geluidsbestand. Elke sample die verwerkt wordt kan een vorige verwerkte sample nodig hebben voor de berekening. Als je dan parallelliseert gaat het alleen maar nog langzamer omdat na elk sample de thread ook nog moet wachten op de/een andere thread die het voorgaande sample verwerkt.

Een ander voorbeeld is het encoden van een MP3'tje. Ja, je kunt per frame een core er op los laten, maar dat kan dan alleen bij ABR, wat toch zeldzamer en zeldzamer wordt omdat het kwalitatief gewoon inferieur is. Als je met VBR gaat werken, moet je toch weer wachten op andere threads, of je moet naderhand met data gaan schuiven, wat óf heel veel geheugen kost, óf heel veel I/O, wat je voordeel gelijk de kop in drukt.

.oisyn schreef op dinsdag 07 november 2006 @ 00:55:
Tja, het hangt natuurlijk puur af van de software die je maakt. De gemiddelde applicatie zal ook geen meerdere cores nodig hebben aangezien hij sowieso al niet eens 1% van de totale load van het systeem voor z'n rekening neemt. Ik denk dat het gros van de mensen hier wel in die doelgroep valt.

Daarbij komt nog dat veel developers überhaupt nog moeten leren hoe ze efficiënt met de processor om moeten gaan, zelfs op 1 core. Nog steeds zijn er zoveel programma's die niet een UI thread en tenminste één worker thread hebben, en zelfs Windows-componenten maken zich hier schuldig aan.

[Alarmnummer]

Om in serverside problematiek te blijven:

De meeste servlet containers, applicatie containers, databases maken allemaal gebruik van meerdere threads, dus die meerdere cores die zullen wel gebruikt gaan worden (mits je os/kernel dat toelaat uiteraard). Het percentage rekenintensieve applicaties is erg klein tov het aantal webapplicaties dat gebouwd worden.

Dus ik denk dat 99% van de serverside java programmeurs zich onwetend kunnen houden (zoals ze nu ook doen aangezien de container de meeste thread problematiek al voor hun coordineerd). En isolation icm immutability (en database transactie die de echte concurrency control voor je uitvoert) is je grootste vriend om concurrency control gerelateerde complexiteit te reduceren

Voor die andere 1%... yess... eindelijk iets spannends We gaan trouwens nog veel visibility problemen krijgen door de introductie van multicores. Aangezien visibility problemen zich op singlecores niet zullen voordoen. Daarom leken de oude libraries altijd goed te werken, maar zulen ze op de multicores vaker onvoorspelbare problemen op gaan leveren.

[ Voor 11% gewijzigd door Alarmnummer op 07-11-2006 09:07 ]

[MBV]

Verwijderd schreef op dinsdag 07 november 2006 @ 00:46:

Zou het niet kunnen dat de nu komende generatie die vanaf het begin getraind wordt om parallel te denken hier veel makkelijker mee omgaat als de huidige generatie? Voor hun zijn race conditions en synchronisations misschien gewoon een 2de natuur, net zoals wij met het grootste gemak polymorphisme en inheritance etc toepassen. En ja, het zijn zulke simpele concepten maar ik heb 'oude' C programmeurs destijds hier echt kapot op zien gaan, tot op het punt van ontslag nemen aan toe.

Toch blijft je testen veel moeilijker: onder load kan zich ineens een crash voordoen, die zich zonder zware load niet had voortgedaan. Onder load van een ander proces kan zich een race-probleem voordoen wat niet ontstond bij volledige belasting door de applicatie zelf. Testen is een hele slag complexer geworden, doordat je de load mee moet nemen.

Tuurlijk heb ik wel wat threading gehad op het HBO (alhoewel dat veel te weinig is) en er zijn hier op de TU/e ook wat vakken die ik kan volgen hierover. Erg interessant natuurlijk, maar zeggen dat het net zo makkelijk wordt als OOd gaat me wat ver. OOd/OOp is niet inherent complexer, het is een andere manier van denken. _{ik ben van die generatie die zonder OO niet kan programmeren ja} .Met threads krijg je 'gratis' meer complexiteit, tenzij de compiler het automatisch (en goed) voor je oplost.[/ME]

[MTWZZ]

MBV schreef op dinsdag 07 november 2006 @ 09:14:
[...]
Tuurlijk heb ik wel wat threading gehad op het HBO (alhoewel dat veel te weinig is)

You lucky bastard
Volgens mij is dat al meer dan de gemiddelde HBO IT student krijgt en wat IMHO echt schandalig is.

[MBV]

Ik zat dan ook op de beste HBO informatica (Technische Informatica, TH Rijswijk), en zit nu op beste TU

[H!GHGuY]

Multi-core developen is voor 90% van de applicaties overkill. Eenvoudige programma's hebben het niet nodig. Andere zijn I/O bound. Je blijft dus over met de typische applicatie die 100% CPU eist met slechts een minimum aan I/O.

Noem binnen de 10 seconden 10 soorten applicaties die aan dit karakter voldoen. Om je even op weg te helpen: games, audio/video en-/decoding (mits beperkte bitrate) en daar zijn mijn 10 seconden reeds op.
Games zijn reeds mooi op weg. Audio en video decoding zijn soms behoorlijk moeilijk. Je kan een MPEG2 stroom gerust per GOP op een processor te encoden. Maar probeer dit niet met H.264.

Zelfs al kan je nog 10tallen applicatie-types noemen, het moet ook nog de moeite zijn en blijven. Ik kan me inbeelden dat het schedulen van verschillende processen op verschillende cores bij multi-tasking op dit moment de grootste performance boost geeft. Neem bijvoorbeeld een virus-scanner die op de 2de core draait en de data die core 1 wil inlezen (gebufferd natuurlijk) scant op virussen.

Zoals Alarmnummer aangaf: de meeste serverside software is er reeds voor geoptimaliseerd. Een multi-core browser of word processor lijken me klinkklare onzin.

Bovendien is het voor de meeste programma's niet eens de moeite. Het extra werk dat steekt in debuggen (race-condities, SMP problemen e.d.) haalt het meestal niet bij het voordeel. Zelfs op single-core kun je al behoorlijk irritante race-condities hebben.

[Confusion]

Zolang ik geen tekort aan processorcapaciteit heb of voorzie, zie ik geen reden expliciet het werk over meerdere cores te gaan verdelen. Zeker aan de client kant is het alleen maar prettig dat de gebruiker andere dingen kan blijven doen, terwijl onze applicatie 1 core flink belast.

[Grijze Vos]

MBV schreef op dinsdag 07 november 2006 @ 09:47:
Ik zat dan ook op de beste HBO informatica (Technische Informatica, TH Rijswijk), en zit nu op beste TU

offtopic:
Volgens mij hebben wij het over PGP op Ubuntu gehad laatst bij IS.

[flowerp]

H!GHGuY schreef op dinsdag 07 november 2006 @ 19:15:
Multi-core developen is voor 90% van de applicaties overkill. Eenvoudige programma's hebben het niet nodig.

Dit vind ik een behoorlijk domme, of op z'n minst naieve opmerking. Het past precies in het rijtje dat 640kb genoeg zou zijn of dat de meeste applicatie's niet meer dan 100Mhz nodig zouden hebben.

Heb je er wel eens bij stil gestaan zoals de TS stelt dat een enkele core binnen afzienbare tijd NIET meer significant sneller wordt. Een enkele core zoals we die nu kennen zit toch echt wel op de grenzen wat haalbaar is. Als wij niet voor multi-core gaan developen kunnen Intel & Co net zo goed stoppen met het uitbrengen van nieuwe CPU's.

Voor multi-tasking is dual core nog een goede oplossing. Je draait dan al je background zut op de ene core en hebt de andere vrij voor je foreground app.

Op het moment dat we op 80 cores zitten (google maar eens op 80 cores idf) dan kun je gewoon niet meer met deze stelling wegkomen. Gebruikers gaan zeker niet 80 taken op full-load tegelijk uitvoeren.

De stelling is simpel; des te meer cores er komen, des te meer performance je laat liggen.

Een multi-core browser of word processor lijken me klinkklare onzin

Precies wat men vroeger zei; een word processor op een 100Mhz CPU moeten draaien is klinkklare onzin. De grootste overeenkomst is de beperkte visie die mensen zoals jij hebben. Toen keek men naar het huidige aanbod en zag dat word processors op 33Mhz machines redelijk draaiden. Mensen met weinig inbeeldings vermogen konden slechts lijntjes doortrekken en in hun belevings wereld was een word processor op een 100Mhz CPU dus ook inderdaad onzin.

Maar kijk eens naar vandaag de dag. De laatste generatie word processors doet en kan steeds meer. Complexe vector graphics, real-time spell checking, en weet ik wat nog meer voor dingen. Feit is dat de laatste versies van bijvoorbeeld Writer or Word verre van 100% soepel draaien op zelfs mijn 3800+ X2. Het draait niet slecht, maar zeker in de wat grotere documenten gaan dingen als her-formateringen zeker niet instant. Zolang dat niet gebeurd is er zeker nog ruimte voor verbeteringen.

[ Voor 30% gewijzigd door flowerp op 07-11-2006 23:04 ]

[RobIII]

flowerp schreef op dinsdag 07 november 2006 @ 22:42:
Op het moment dat we op 80 cores zitten (google maar eens op 80 cores idf) dan kun je gewoon niet meer met deze stelling wegkomen. Gebruikers gaan zeker niet 80 taken op full-load tegelijk uitvoeren.

De stelling is simpel; des te meer cores er komen, des te meer performance je laat liggen.

Vet! Notepad op 80 cores!
Het is natuurlijk ook nogal afhankelijk van wat je applicatie doet; zoals reeds aangegeven staan een flink aantal (kantoor)applicaties doorgaans 99% van de tijd met hun vinger in de neus te wachten op input van de gebruiker. Applicaties die meerdere threads kunnen gebruiken omdat het nut heeft (zoals bijvoorbeeld in meerdere threads renderen, in de achtergrond "spellingscontrole" doen, server-apps etc.) zullen hooguit over nog méér cores gespreid worden (="winst") maar vind ik het me nogal bot om te stellen dat het dezelfde vergelijking is als de roemruchte "640Kb ought to be enough for everybody".

Euh, wat ik dus probeer te zeggen is dat het lang niet altijd nuttig is (en soms zelfs onwenselijk) om je app over meerdere cores te smeren (en dan heb ik het nog niet eens over de extra ontwikkeltijd die er in gaat zitten die ook betaald moet worden en waar het gebruikers worst zal wezen of de app op 1 of 37 cores draait als het toch in een "flits" klaar is). Euh... het is dus niet zo "zwart/wit" als jij het stelt Er zijn gradaties.

flowerp schreef op dinsdag 07 november 2006 @ 22:42:
Maar kijk eens naar vandaag de dag. De laatste generatie word processors doet en kan steeds meer. Complexe vector graphics, real-time spell checking, en weet ik wat nog meer voor dingen. Feit is dat de laatste versies van bijvoorbeeld Writer or Word verre van 100% soepel draaien op zelfs mijn 3800+ X2. Het draait niet slecht, maar zeker in de wat grotere documenten gaan dingen als her-formateringen zeker niet instant. Zolang dat niet gebeurd is er zeker nog ruimte voor verbeteringen.

Nogmaals; het moet ook te doen zijn in meerdere threads; je kunt wel een stuk of 80 threads hebben lopen, maar als die allemaal op die ene staan te wachten voordat zelf verder kunnen is het natuurlijk nonsense om uberhaupt die treads te starten. Met dat her-formatteren sla je de spijker op z'n kop; Ik zie niet in hoe ik dat over meerdere threads zou kunnen verdelen.

Meer threads is niet altijd beter.

[ Voor 40% gewijzigd door RobIII op 07-11-2006 23:10 ]

[flowerp]

RobIII schreef op dinsdag 07 november 2006 @ 23:03:
Het is natuurlijk ook nogal afhankelijk van wat je applicatie doet; zoals reeds aangegeven staan een flink aantal (kantoor)applicaties doorgaans 99% van de tijd met hun vinger in de neus te wachten op input van de gebruiker.

Mischien zelfs wel 99.9%. Er is dan ook niet een tekort aan continue CPU power, maar aan burst cpu power. Op het moment DAT de gebruiker wat doet is er wel zeker nut voor meer CPU power.

Euh, wat ik dus probeer te zeggen is dat het lang niet altijd nuttig is (en soms zelfs onwenselijk) om je app over meerdere cores te smeren (en dan heb ik het nog niet eens over de extra ontwikkeltijd die er in gaat zitten die ook betaald moet worden en waar het gebruikers worst zal wezen of de app op 1 of 37 cores draait als het toch in een "flits" klaar is).

Het punt is dat lang niet elke applicatie met alles in een flits klaar is. Als ik nu even snel kijk naar de programma's in mij dock; Mail, Safari, iTines, iPhoto, VPC, TextEdit, Eclipse, dan is hier alleen TextEdit min of meer instant in alles. In alle andere apps gaat er van alles gewoon niet in een flits.

Wat ik hier proef is dat men toch wel erg anti multi-core is. Wat stellen jullie dan voor, dat de huidige desktop CPU's als 'final' verklaard worden en dat nieuwe CPU's (met dus meer cores) alleen nog voor servers gemaakt gaan worden?

Het 'leuke' is ook dat men op de FP stelt dat multi-core onzin is omdat er nog te weinig software is die er gebruik van maakt en dat de developers maar eens haast moeten gaan maken met hun software geschikt te maken. Kijk je dan hier dan zie je dat de developers (wij dus) stellen dat multi-core onzin is omdat bijna elke denkbare applicatie al snel genoeg draait.

Ik zie niet in hoe ik dat over meerdere threads zou kunnen verdelen.

Dat is nou het hele punt. JIJ ziet dat niet in, omdat je niet getraind bent in parallel denken.

Natuurlijk, ik stel het even een beetje zwart/wit of bot, en ik weet ook wel dat sommige dingen niet of nauwelijks te paralleliseren zijn, maar dat is ook om een beetje de discussie uit te lokken. Van "kan niet, doen we niet. Punt." wordt ook niemand beter.

Multi-core is de (voorlopige) toekomst en like it or not, op een gegeven moment zul je toch mee moeten doen. Een klassieker op dit gebied is nog steeds het artikel van Herb Sutter van alweer een poosje geleden: http://www.gotw.ca/publications/concurrency-ddj.htm

[ Voor 16% gewijzigd door flowerp op 07-11-2006 23:29 ]

[MBV]

Grijze Vos schreef op dinsdag 07 november 2006 @ 21:34:
[...]

offtopic:
Volgens mij hebben wij het over PGP op Ubuntu gehad laatst bij IS.

offtopic:
key signen?
Wie ben jij dan? Man, uit '82, woonplaats eindhoven, IS gevolgd is nog een groep van +- 30 man

flowerp schreef op dinsdag 07 november 2006 @ 23:19:
[...]


Mischien zelfs wel 99.9%. Er is dan ook niet een tekort aan continue CPU power, maar aan burst cpu power. Op het moment DAT de gebruiker wat doet is er wel zeker nut voor meer CPU power.

Yup. Er is alleen altijd die kosten-afweging: als we alles in assembly schreven, dan was het wél in een flits klaar geweest, maar dat doen we ook niet. Waarom niet? Kost te veel ontwikkeltijd, en is niet te onderhouden. Je ziet op het moment juist een trend naar nog grotere performance-vreters: laten we in plaats van C++ naar Javascript overstappen, makkelijker te onderhouden (Firefox).
En dan kom je direct weer bij een punt waar je er voordeel uit kan halen: hoe meer high-level een programma geschreven is, hoe meer je kan doen met multi-threading.
Stel je eens een binary-search voor, die in Haskell is geschreven. 1 van de 2 branches kan steeds op een andere proc verder draaien, wat best wel eens performance kan schelen. Dat kan de compiler vrij eenvoudig vinden, met een while-loop in C kan dat veel moeilijker.

[...]


Het punt is dat lang niet elke applicatie met alles in een flits klaar is. Als ik nu even snel kijk naar de programma's in mij dock; Mail, Safari, iTines, iPhoto, VPC, TextEdit, Eclipse, dan is hier alleen TextEdit min of meer instant in alles. In alle andere apps gaat er van alles gewoon niet in een flits.

Moet jij eens voor de gein gaan debuggen (we zitten toch in /14?) waar die tijd in gaat zitten. Ik durf te wedden dat de wachttijden (op Windows iig) voor meer dan de helft uit HDD-access bestaat. MacOS X ken ik niet, op Linux zit ik daarentegen wel continue op mijn proc te wachten met Eclipse . Toch eens die java-code naar een executable compileren met GCC

Wat ik hier proef is dat men toch wel erg anti multi-core is. Wat stellen jullie dan voor, dat de huidige desktop CPU's als 'final' verklaard worden en dat nieuwe CPU's (met dus meer cores) alleen nog voor servers gemaakt gaan worden?

Ik stel voor dat we wachten totdat intel de Intel C++ compiler 10 afheeft, die vanzelf alles in threads gooit als dat kan . Tot die tijd laten we de CPU lekker uit z'n neus vreten, behalve voor dingen waar de kostenvergelijking tussen ontwikkel/test-tijd <=> snelheid richting snelheid gaat. Duidelijk gescheiden taken in een aparte thread gooien als dat relatief eenvoudig is (autoformat, spellcheck), taken die echt teveel tijd kosten in threads ophakken mits mogelijk (voor veel taken is te bewijzen dat dat niet zinvol is door de berg data die heen en weer moet enzo), en hopen dat die compilers snel komen .

Het 'leuke' is ook dat men op de FP stelt dat multi-core onzin is omdat er nog te weinig software is die er gebruik van maakt en dat de developers maar eens haast moeten gaan maken met hun software geschikt te maken. Kijk je dan hier dan zie je dat de developers (wij dus) stellen dat multi-core onzin is omdat bijna elke denkbare applicatie al snel genoeg draait.

Moet je eens goed kijken waar die mensen op geilen: games. Heb je het nieuws een beetje gevolgd? valve gaat multicore proggen, zodat de developers van games zich daar niet mee bezig hoeven te houden. Kijk, dat bedoel ik nou ongeveer (alhoewel zo'n engine geen compiler is). Standaard-oplossingen zodat je zelf niet moeilijk hoeft te doen, hergebruik van oplossingen enzo.
Daarnaast weten de meeste developers dat bijna alle applicaties 10x sneller kunnen, simpelweg door efficienter om te gaan met die ene processor. Kost wel veel tijd=geld om dat voor elkaar te krijgen.

Dat is nou het hele punt. JIJ ziet dat niet in, omdat je niet getraind bent in parallel denken.

Ach ja, JIJ gooit alles automatisch in threads? JIJ maakt daarbij nooit fouten? Ga JIJ dan eens lekker aan firefox knutselen om te zorgen dat dat Javascript multithreaded wordt, ik wordt helemaal ziek van die animaties die 100% trekken _{ja, ik heb ook dat firefox-flash bericht gezien, zie vorige punt}

Natuurlijk, ik stel het even een beetje zwart/wit of bot, en ik weet ook wel dat sommige dingen niet of nauwelijks te paralleliseren zijn, maar dat is ook om een beetje de discussie uit te lokken. Van "kan niet, doen we niet. Punt." wordt ook niemand beter.

Moet ik echt een taak verzinnen waarbij te bewijzen is dat multi-tasking zinloos is?

Daarnaast zijn er op het moment nog niet echt de tools voor om goe multithreaded te ontwikkelen. Goede test-suites om race-problemen te zien, dat soort gein heb ik allemaal nog niet gezien.

[Confusion]

flowerp schreef op dinsdag 07 november 2006 @ 23:19:
Dat is nou het hele punt. JIJ ziet dat niet in, omdat je niet getraind bent in parallel denken.

Ach schei uit, "getrained in parallel denken". Sorry hoor, maar zulke rocket science is het schrijven van een multithreaded app in een taal die daar grondige ondersteuning voor heeft nou ook bepaald weer niet. Het vereist niets anders dan bedenken welke taken onafhankelijk van anderen kunnen worden uitgevoerd en op welk moment de informatie weer gebundled kan/moet worden. En dan hebben mensen gelijk: wat ga jij multithreaden aan het operationele gebruik van een wordprocessor?

Ja, natuurlijk stop je de instant spell-check in een aparte thread, maar afgezien daarvan is er verdomd weinig dat je winst op gaat leveren. Juist omdat je burst CPU power nodig hebt, heb je dus ook burst memory bandwidth nodig om de gegevens weer bij elkaar te krijgen en de I/O overhead maakt doet ieder voordeel va multithreaden in dat soort situaties teniet. Als ik er naast zit: leg me dan alsjeblieft uit waarom, in plaats van op te merken dat ik "niet getrained zou zijn om parallel te denken". Ik ben uberhaupt niet getrained om software te schrijven, functioneel noch OO te denken of om 'in design patterns' te denken.

[Grijze Vos]

MBV schreef op woensdag 08 november 2006 @ 00:45:
[...]

offtopic:
key signen?
Wie ben jij dan? Man, uit '82, woonplaats eindhoven, IS gevolgd is nog een groep van +- 30 man

offtopic:
Ik ben degene waar je al twee weken naast zit.

[ Voor 3% gewijzigd door Grijze Vos op 08-11-2006 09:09 ]

[Verwijderd]

Parallel programmeren zal in de toekomst steeds belangrijker worden, daar ben ik van overtuigd. Ik denk dat flowerp dan ook een goed punt heeft dat ontwikkelaars vaker zouden moeten nadenken over de eventuele mogelijkheden om parallelisme toe te passen. Het is inderdaad iets waar programmeurs vaak niet (of nauwelijks) bij stil staan en het zou wel goed zijn als ze dat zouden doen.

Het parallel denken is echter niet eenvoudig en veel programmeurs zijn dat inderdaad niet gewoon. Ik heb echter wel mijn twijfels of het goed zou zijn dat iedereen parallel leert denken en ermee gaat werken. Ik denk dat deze stap een stuk groter is (misschien wel niet vergelijkbaar) dan bijvoorbeeld de overstap van procedureel naar object oriented terwijl deze stap al bergen programmeurs in grote problemen bracht/brengt.

CPU bakkers zijn gewend om parallel te denken (ze doen niet anders) en hier wordt dit al zeer lang gedaan. De technieken die in deze branche ontwikkeld zijn spelen hier ook helemaal op in en bij een chip ontwerp kan het model op verschillende niveaus worden getest en geverifieerd. Voor deze branche is het echter bittere noodzaak om met een goed ontwerp te komen want een fout in het ontwerp kost veel geld en is niet te herstellen bij de reeds gefabriceerde produkten. Dit in tegenstelling tot software waarbij het mogelijk is om deze te updaten zodra er een fout wordt gevonden. Dat is een zwakte van software maar het is meteen ook een sterkte waardoor er zoveel software is tegenwoordig.

Parallelisme is een "nieuwe" dimensie in software die een grote rol gaat spelen. Deze nieuwe dimensie maakt het echter weer een slag moeilijker om software te testen en foutvrij te maken. Dit is volgens mij ook een belangrijke reden voor bijvoorbeeld Valve een engine maakt die deze dimensie voor je wegneemt. Het is voor veel developers nu al moeilijk om bug-vrije software te schrijven en de introductie van een nieuwe dimensie zou vele van hen geen goed doen.

Ik verwacht dan ook dat het in de toekomst niet belangrijk wordt voor een programmeur om parallel te kunnen denken (al is het goed dat hij dat zo nu en dan wel doet ) maar dat deze problemen worden opgevangen door een bepaalde abstractielaag (o.i.d.). Enerzijds kan een programmeur daardoor blijven denken zoals hij nu al doet en anderszijds blijft de software beter onderhoudbaar.

[Alarmnummer]

Confusion schreef op woensdag 08 november 2006 @ 08:32:
[...]Juist omdat je burst CPU power nodig hebt, heb je dus ook burst memory bandwidth nodig om de gegevens weer bij elkaar te krijgen en de I/O overhead maakt doet ieder voordeel va multithreaden in dat soort situaties teniet.

Oeh oeh.. ik ook. Een nadeel van multithreaden over meerdere cores met gescheiden caches is dat je vaak 'synchronisatie' nodig bent (gebeurt mbv memory barriers) wat de snelheids winst van een cache gedeeltelijk teniet doet. In theorie zou een proces met 2 threads en 2 cores door cache invalidatie langzamer kunnen lopen dan een systeem met 2 threads over 1 enkele core (met dezelfde snelheid) doordat het vaker met main memory (of een langzamere cache) zal moeten communiceren.

ps:
daarom is het ook zo belangrijk dat snelle cpu's (die een groot aantal threads gaan draaien) ook zo'n grote hoeveelheid cache hebben. Je wilt namelijk niet dat het draaien van een bepaalde thread de cache entries voor een andere thread eruit gaat knikkeren. Als dit namelijk wel gebeurd dan kan iedere thread iedere keer na het inschedulen weer data uit main memory (of een langzamere cache) halen. Een cache word meestal met een groter geheugen blok gevuld: in de cache wordt namelijk niet alleen de data opgehaald die nodig is, maar ook de data die waarschijnlijk nodig is. Door deze eigenschap loopt je cache dus nog sneller vol.

[ Voor 30% gewijzigd door Alarmnummer op 08-11-2006 10:32 ]

[MBV]

Grijze Vos schreef op woensdag 08 november 2006 @ 09:09:
[...]

offtopic:
Ik ben degene waar je al twee weken naast zit.

offtopic:
Die 2 keren dat ik zo laat was dat ik naast een willekeurig iemand ging zitten omdat er weinig plek meer was dus, en jij hebt waarschijnlijk op mijn laptop gezien dat ik MBV was? Zomaar een gokje 'k voel me weer eens echt een nerd, ik ken amper mensen die niet bij mij in het schakeltraject zaten...

Verwijderd schreef op woensdag 08 november 2006 @ 09:24:
Ik verwacht dan ook dat het in de toekomst niet belangrijk wordt voor een programmeur om parallel te kunnen denken (al is het goed dat hij dat zo nu en dan wel doet ) maar dat deze problemen worden opgevangen door een bepaalde abstractielaag (o.i.d.). Enerzijds kan een programmeur daardoor blijven denken zoals hij nu al doet en anderszijds blijft de software beter onderhoudbaar.

Vergeet niet dat ook als de problemen op dat niveau worden weggenomen, debuggen alsnog een stuk lastiger wordt dan het nu is. Ook compilers maken soms fouten, en fouten hierin (verondersteld onafhankelijke dingen parallel zetten, terwijl ze niet onafhankelijk zijn) zal erg lastig debuggen worden.

[barfieldmv]

Multi threaded applicaties worden pas belangrijk als er veel rekenwerk gedaan moet worden dat niet in een flits af is. Bij de meeste task-switches van applicaties word er vooral veel gewacht op I/O subsystemen, niet zozeer op de cpu.

Ik denk dat er veel te winnen is door kleinere worksets te gebruiken in applicaties en goed op onnodige loopjes te letten.

Voordat je begint met het schrijven van een applicatie maak je een technisch plaatje van de functionaliteit. Zitten daar veel parralelle processen tussen of zware reken stukken dan is mulithreading de oplossing (8 cores, 8 wav2mp3 threadjes) zit je echter met een linaire rekensom (mp3 vbr) dan moet je wat veranderen aan: of je algoritme, of gewoon verzinnen dat je tientallen andere zaken op de achtergrond kan uitvoeren.

Maw er komen idd steeds meer cores bij en voor optimaal gebruik van je PC is het gebruik van meerdere threads dan ook noodzakelijk . Als ik nu zelf een applicatie ontwikkel gebruik ik meerdere threads en dat is puur voor het updaten van wat grafisch werk.

[Verwijderd]

MBV schreef op woensdag 08 november 2006 @ 10:27:
Vergeet niet dat ook als de problemen op dat niveau worden weggenomen, debuggen alsnog een stuk lastiger wordt dan het nu is. Ook compilers maken soms fouten, en fouten hierin (verondersteld onafhankelijke dingen parallel zetten, terwijl ze niet onafhankelijk zijn) zal erg lastig debuggen worden.

Je hebt gelijk dat debuggen niet makkelijker wordt en ik ben dan ook benieuwd hoe dit in de toekomst gerealiseerd gaat worden.

Het is ook mogelijk dat een compiler fouten maakt (het blijft software ) maar het zal voor een programmeur een verademing zijn dat hij/zij daar niet zelf voor verantwoordelijk is.


Wat ik me overigens ook afvraag is hoe je rekening houdt met parallelisme. Zoals hier al wordt aangegeven zijn er op dit moment situaties waar het geen voordeel is om multi-threading te gebruiken omdat de overhead te groot is terwijl er andere systemen zijn waar dit wel het geval is. Hoe ontwerp je een applicatie die bijvoorbeeld op zowel een single core processor als een 80 core processor goed moet draaien? Dat lijkt me een hele uitdaging waarbij een dergelijke abstractielaag een goede rol kan spelen (al is dat natuurlijk ook weer overhead ).

[.oisyn]

Alarmnummer schreef op woensdag 08 november 2006 @ 10:24:
[...]

Oeh oeh.. ik ook. Een nadeel van multithreaden over meerdere cores met gescheiden caches is dat je vaak 'synchronisatie' nodig bent (gebeurt mbv memory barriers) wat de snelheids winst van een cache gedeeltelijk teniet doet. In theorie zou een proces met 2 threads en 2 cores door cache invalidatie langzamer kunnen lopen dan een systeem met 2 threads over 1 enkele core (met dezelfde snelheid) doordat het vaker met main memory (of een langzamere cache) zal moeten communiceren.

Beetje kort door de bocht. Ten eerste hangt het heel erg af van de architectuur. AMD heeft met z'n hyperthreading namelijk een veel betere communicatie tussen de verschillende processoren dan intel ooit had met z'n multicpu solutions (en dan heb ik het over het P3 tijdperk, geen idee hoe het met de nieuwe chips is). Ten tweede zorgen alle threads op 1 CPU ervoor dat je cache sowieso veel minder effectief is omdat er veel meer contexts zijn waarin code wordt uitgevoerd (dus meer memory die wordt getouched, dus cache loopt sneller vol)

Bottom line is dat je er gewoon weinig over kunt zeggen; er zijn gewoon simpelweg teveel factoren.

[MBV]

als je het zelf hebt gedaan is het wat makkelijker te verhelpen dan wanneer intel het heeft gedaan.
Voor de compiler is het heel eenvoudig om rekening te houden met 80 of 1 core: een vlag voor welke processor je aan het bouwen bent Voor jezelf is dat veel lastiger. En zelfs met 80 cores is het nog maar de vraag of een operatie de overhead waard is van extra I/O.

edit:
iosyn: hyperthreading is van intel, dat wannabe-2core gebeuren, weet je nog?

[ Voor 11% gewijzigd door MBV op 08-11-2006 11:25 ]

[.oisyn]

MBV, doel je hier nou op dat nieuwsbericht van intel van laatst? Dat was geen compiler oplossing, maar simpelweg een library.

[Exirion]

Software efficient paralleliseren is 1 ding, maar dat is niet eens waar ik me het meest zorgen over maak. Wat een groter probleem is, is de steeds groter wordende kloof tussen processor performance en memory performance. Een groot deel van de tijd staat de CPU te wachten op data. Als algoritmen niet cache-efficient zijn dan gaat een groot deel van je CPU performance verloren, en dan hebben we het vaak over een factor X en niet slechts een paar procent.

Bij multi-processor en multi-core systemen wordt het verhaal nog was lastiger als je kijkt naar het delen van geheugen en het delen van caches. En bij de Opteron heb je bijvoorbeeld nog te maken met NUMA waarbij een stuk geheugen bij 1 core hoort. Andere cores kunnen ook bij dat geheugen komen, maar via de memory controller van de core waar het geheugen bij hoort. Dat kost 'hops' zoals in een netwerk, en leidt het tot latency en netto minder bandbreedte.

Natuurlijk zijn voor al dit soort dingen optimaliserende compilers te maken, maar met een volledig transparante oplossing haal je in de praktijk niet het maximaal haalbare. Nadenken over het optimaliseren van processing maar ook zeker memory access zijn wmb essentieel.

[Alarmnummer]

.oisyn schreef op woensdag 08 november 2006 @ 11:21:
[...]
Beetje kort door de bocht.
...

Bottom line is dat je er gewoon weinig over kunt zeggen; er zijn gewoon simpelweg teveel factoren.

Daarom staat er ook 'in theorie'.

Het punt dat ik wil maken is: het is niet zo vanzelfsprekend dat er veel snelheids winst geboekt gaat worden.

[ Voor 39% gewijzigd door Alarmnummer op 08-11-2006 11:37 ]

[.oisyn]

Okee dan zijn we het eens

[Icelus]

MBV schreef op dinsdag 07 november 2006 @ 00:26:
Ik hoop dat over een poosje de Intel-compiler zo slim omgaat met branching dat alles vanzelf gaat. Dat hoop ik voor alle mensen met legacy-software, en mensen die niet zo slim zijn om alles in threads uit te denken .

Volgens mij doet de Intel compiler dit (tot op zekere hoogte) al:

The Intel C++ Compiler 7.1 includes an Auto-parallelization feature for automatic threading of loops. This feature provides developers with an easy way to take advantage of parallelism to improve application performance on multiprocessor systems. This option detects parallel loops capable of being executed safely in parallel and automatically generates multithreaded code for these loops.

Automatic parallelization relieves you from having to deal with the low-level details of iteration partitioning, data sharing, thread scheduling and synchronizations.

It also provides the benefit of the performance available from multiprocessor systems, and systems that support Hyper-Threading technology.

Bron: Intel: Threading Methodology: Principles and Practices

[MBV]

Is maar tot op zekere hoogte, en erg beperkt. Ik heb ergens gelezen dat de nieuwe compiler (8 of 9) meer dingen zou ondersteunen, geen zin om dat nieuwsbericht op te zoeken..

[whoami]

Deze hoort idd eerder in SE&A thuis

-> SE&A

[MTWZZ]

Ik heb het idee dat hier vooral over C/C++ gepraat wordt. Weet er toevallig iemand hoe dit zit met "managed" talen als Java/C#. Zijn die compilers ook in staat dit soort trucs te ontdekken en daar ook wat nuttigs mee te doen?

[.oisyn]

MTWZZ schreef op woensdag 08 november 2006 @ 13:44:
Ik heb het idee dat hier vooral over C/C++ gepraat wordt.

Dat ligt denk ik puur aan jou

[MBV]

MTWZZ schreef op woensdag 08 november 2006 @ 13:44:
Ik heb het idee dat hier vooral over C/C++ gepraat wordt. Weet er toevallig iemand hoe dit zit met "managed" talen als Java/C#. Zijn die compilers ook in staat dit soort trucs te ontdekken en daar ook wat nuttigs mee te doen?

Mag jij raden in wat voor taal de JVM is geschreven, en wat er gebeurt als je die met de (nog niet bestaande) ideale multithreading-compiler wordt gecompileerd .
Java kan hetzelfde doen, aangezien Java ook een compiler. Maar, NOFI, C++ wordt toch vaker gebruikt als hoge performance-eisen gesteld worden. Java heeft (op linux) gewoon niet de responsiveness die C++ heeft. Kan zijn omdat de JVM voor linux zuigt, maar toch. C# weet ik niet. Ook daarvoor geldt dat het een compiler is, die een gewone applicatie multithreading kan maken.

_{Sorry trouwens dat ik de Intel C++ compiler erbij heb gehaald als voorbeeld. Ik ben denk ik de hoofdschuldige van jouw indruk}

[ Voor 7% gewijzigd door MBV op 08-11-2006 14:20 ]

[.oisyn]

MBV schreef op woensdag 08 november 2006 @ 14:19:
[...]

Mag jij raden in wat voor taal de JVM is geschreven, en wat er gebeurt als je die met de (nog niet bestaande) ideale multithreading-compiler wordt gecompileerd .

Nou boeiend, dan is de JVM zelf parallelliseerbaar. Dat wil nog niet zeggen dat de code die de JVM uitvoert ook meteen geparallelliseerd wordt, dat soort features zullen weldegelijk direct in de JVM ingebouwd moeten worden

[Verwijderd]

.oisyn schreef op woensdag 08 november 2006 @ 14:29:
[...]

Nou boeiend, dan is de JVM zelf parallelliseerbaar. Dat wil nog niet zeggen dat de code die de JVM uitvoert ook meteen geparallelliseerd wordt, dat soort features zullen weldegelijk direct in de JVM ingebouwd moeten worden

JVM die parallelliseerbare code on the fly maakt... dat zou wel een interessante optie zijn. Daar zit misschien nog wel toekomst in.

[Verwijderd]

Confusion schreef op woensdag 08 november 2006 @ 08:32:
[...]

Ach schei uit, "getrained in parallel denken". Sorry hoor, maar zulke rocket science is het schrijven van een multithreaded app in een taal die daar grondige ondersteuning voor heeft nou ook bepaald weer niet.

Nu denk je er toch echt te makkelijk over. Flowerp heeft hier wel degelijk een heel goed punt en het siert je niet dat jij daar zo totaal overheen kijkt. Object Orientatie is ook nou niet bepaald rocket science, maar waarom hadden de structureel getrainde programmeurs begin jaren '90 er dan zo'n moeite mee?

En vergis je niet, ik heb die mensen zelf gezien. Bij het bedrijf waar ik als jonkie werkte zaten ook een aantal senior mensen. Deze waren opgegroeid met talen als cobal en C. Op een gegeven moment bleek het noodzakelijk om met OO te beginnen. Het hergebruik van bestaande stukken software was minimaal destijds en de organisatie ervan liet sterk te wensen over. Enkele van de jongere mensen had een pilot opgezet met een OO techniek, en dat beviel na evaluatie zo goed dat er besloten werd over te stappen (voor nieuwe projecten).

Alleen...

Een groot aantal van de structurele mensen 'zag' het gewoon niet. Ze liepen te vloeken dat objects onzin waren, dat een dergelijke maten van code ordening maar voor minder dan 10% van de applicaties nodig was en waarom wij in hemelsnaam de noodzaak zagen om voor een voorraad beheer systeem objecten te gaan gebruiken. Het is bijna eng om nu dezelfde argumenten weer te horen.

Het aangehaalde artikel van Herb Sutter is zeker een aanrader voor iedereen om te lezen. Een mooie quote hieruit:

Just as it is a leap for a structured programmer to learn OO (what’s an object? what’s a virtual function? how should I use inheritance? and beyond the “whats” and “hows,” why are the correct design practices actually correct?), it’s a leap of about the same magnitude for a sequential programmer to learn concurrency (what’s a race? what’s a deadlock? how can it come up, and how do I avoid it? what constructs actually serialize the program that I thought was parallel? how is the message queue my friend? and beyond the “whats” and “hows,” why are the correct design practices actually correct?).

Of samengevat:

The vast majority of programmers today don’t grok concurrency, just as the vast majority of programmers 15 years ago didn’t yet grok objects

Ook andere dingen die hier door sommigen beweert worden (dat de meeste software snel genoeg is) wordt weerlegt in dat artikel.

Confusion schreef op woensdag 08 november 2006 @ 08:32:
[...]
Ik ben uberhaupt niet getrained om software te schrijven, functioneel noch OO te denken of om 'in design patterns' te denken.

[ Voor 4% gewijzigd door Verwijderd op 08-11-2006 21:29 ]

[Confusion]

Verwijderd schreef op woensdag 08 november 2006 @ 21:28:
Nu denk je er toch echt te makkelijk over.

Ik kan net zo goed zeggen: nu denk je er toch echt te moeilijk over.

maar waarom hadden de structureel getrainde programmeurs begin jaren '90 er dan zo'n moeite mee?

Geen idee; maar wat hebben wij daar mee te maken? Dat jij het daarmee vergelijkt betekent niet dat het vergelijkbaar is. Er zijn voortdurend mensen die een stand van zaken met iets rampzaligs uit het verleden vergelijken. Gelukkig luisteren we daar meestal niet naar.

Een groot aantal van de structurele mensen 'zag' het gewoon niet. Ze liepen te vloeken dat objects onzin waren,

Een andere situatie dan nu dus. Er worden hier argumenten gegeven die verklaren waarom multithreaded programming niet altijd zinvol of mogelijk is. Dat is heel iets anders dan de situatie die jij beschrijft: de situatie waarin mensen de voordelen niet begrijpen. Dan waren er dus geen argumenten tegen. Een andere mogelijkheid is nog dat de winnaar de geschiedenis schrijft. Misschien hadden die mensen wel gelijk en was de tijd er nog helemaal niet rijp voor of heeft OO programmeren eigenlijk helemaal niet zoveel voordelen. Dat iets nu het overheersende paradigma is betekent nog niet dat het daadwerkelijk het beste is. Misschien waren zij wel net zo goed in functioneel programmeren als jullie zijn in OO programmeren.

Het is bijna eng om nu dezelfde argumenten weer te horen.

Mensen hebben de neiging te horen wat ze denken te horen. Misschien lijkt het er op, maar het is voorzover ik kan zien niet hetzelfde als wat jij beschrijft.

Begrijp je het punt dat ik daar mee maak? Je hoeft ergens niet in getrained te zijn om ergens de sterke en zwakke kanten van te kunnen begrijpen, de makkelijk en moeilijke punten te zien, over de gemelde valkuilen na te denken en om je de methodes eigen te maken. Natuurlijk, ik ken de fijne kantjes van concurrency niet, zoals Alarmnummer er recent een paar in topics aankaartte, maar als ik kan lezen en begrijpen wat pakweg een semaphore en een memory barrier doen, daar wat mee experimenten en er vervolgens gebruik van maken in een commerciele applicatie, dan kan je toch moeilijk volhouden dat ik er te makkelijk over denk, dat het moeilijk is of dat er sprake is van een noodsituatie. Het is niet alsof er bij de overgang waar jullie telkens naar verwijzen doden zijn gevallen en de economie naar de knoppe is gegaan.

En als mensen niet kunnen begrijpen wat een deadlock is en hoe een memory barrier werkt, dan is het een verloren zaak. Maar ik denk dat je anderen gewoon enorm onderschat.

[ Voor 24% gewijzigd door Confusion op 08-11-2006 23:07 ]

[Verwijderd]

Confusion schreef op woensdag 08 november 2006 @ 22:53:

Geen idee; maar wat hebben wij daar mee te maken? Dat jij het daarmee vergelijkt betekent niet dat het vergelijkbaar is.

Toch denk ik dat ik als ervaringsdeskundige (ik was erbij destijds) als wel als professional op dit gebied hier een zeker geïnformeerd oordeel over kan vellen. (waarmee ik niet bedoel dat ik super slim of al wetend ben, maar gewoon dat ik opgeleid ben hierin en dat deze materie mijn werk is) Als ik dan tevens merk dat diverse andere mensen die hun sporen ruim verdiend hebben in de IT tot nagenoeg dezelfde conclusie komen, dan moet er toch wel een zekere kern van waarheid in zitten?

Voor als je hem niet kent, Herb Sutter is een vooraanstaand lid van het C++ standaard committee, heeft vele hoogwaardige artikelen geschreven en was de drijvende kracht achter het microsoft C++/cli project.

Dus wat hebben wij anno 2006 te maken met de OO revolutie van toen? Mischien moet je maar eens gewoon het hele artikel van Herb lezen

[RobIII]

Verwijderd schreef op donderdag 09 november 2006 @ 00:00:
Toch denk ik dat ik als ervaringsdeskundige (ik was erbij destijds) als wel als professional op dit gebied hier een zeker geïnformeerd oordeel over kan vellen. (waarmee ik niet bedoel dat ik super slim of al wetend ben, maar gewoon dat ik opgeleid ben hierin en dat deze materie mijn werk is)

Ik heb 3 jaar Frans geleerd op school, maar veel verder dan "Bonjour", "Voulez vous coucher avec moi" en "Un vin, un pain et du Boursin" kom ik niet.

Dat je er in "opgeleid" bent wil nog niet zeggen dat je het kent IMHO. Ik ken zat lui die na allerlei heel dure studies heel mooi kunnen lullen maar als puntje bij paaltje komt blijkt dat alleen maar theoretische kennis te zijn en hebben ze moeite om zonder "wizard" een hello-world in elkaar te draaien.

Wat ik bedoel te zeggen is dat het "kwartje" ook gewoon moet vallen; veel devvers indertijd zagen het nut er niet zo van in maar dat kan ook hebben gelegen aan degene die het ze uitlegde / opdrong / whatever. Anderen lezen een artikeltje en pikken het hele concept zo (autodidact) op.

Multi-threading is ook zo complex niet (meer) en compilers zullen in de toekomst vast nog her en der een steentje kunnen bijdragen; maar ik zie niet hoe dat te maken heeft met de "OO revolutie" indertijd.

Feit blijft dat het de gebruiker worst zal zijn of zijn app linksom of rechtsom gecompileerd wordt en op hoeveel cores het ding draait. Het gaat de gebruiker om het resultaat (en/of functionaliteit) en dat is lang niet altijd te bereiken met meerdere threads; het is dan ook écht niet de "holy grail" die jij er van (neigt) te maken. Soms is het gewoon een kwestie van iets heel anders (of opnieuw, etc...) aanpakken of uitbreiden met handige(re) functionaliteit om je app goed te doen verkopen.

[ Voor 5% gewijzigd door RobIII op 09-11-2006 00:14 ]

[Verwijderd]

RobIII schreef op donderdag 09 november 2006 @ 00:11:
[...]
Dat je er in "opgeleid" bent wil nog niet zeggen dat je het kent IMHO. Ik ken zat lui die na allerlei heel dure studies heel mooi kunnen lullen maar als puntje bij paaltje komt blijkt dat alleen maar theoretische kennis te zijn en hebben ze moeite om zonder "wizard" een hello-world in elkaar te draaien.

*kuch* op 6de begonnen met programmeren, op +-12de assembly hacker en dag en nacht met de neus in boeken die voor de universiteit bestemd waren, op 16de werkzaam als programmeur en even later daarnaast WO Informatica studie, les gegeven in C++, daarna full-time developer en even later project-lead (en nog steeds developer) met percentage belang in de toko, etc etc...

Geloof me... die helo world gaat me wel lukken

Anderen lezen een artikeltje en pikken het hele concept zo op.

Klopt, maar het frappante was dat de structureel -> OO overgang toch wel iets meer was dan dat sommige hardleerse figuren het niet wilde of konden oppikken. Er waren toch wel heel erg veel mensen die hier moeite mee hadden.

1 van mijn punten is niet alleen dat mensen er niet het voordeel van in zien, maar ook dat het een andere manier van denken vereist waarvoor een omschakeling nodig is die mensen klaarblijkelijk niet altijd kunnen maken.

Juist deze andere manier van denken is waar de schoen knelt. Ik heb structurele programmeurs gezien die dan toch maar OO gingen programmeren, en wat denk je dat het resultaat was? Een class definitie met alleen static methodes erin en dan gewoon op dezelfde manier programmeren als ze altijd al deden.

Daarbij was men wel degelijk zeer overtuigend met tegenargumenten. Functies waren volgens hun helemaal niet zinvol op te delen in Objecten. Objecten voegde allemaal complexiteit toe en veel te veel overhead die nergens goed voor was. Nu klopt het inderdaad dat sommige dingen niet logisch in objecten uit te drukken zijn. Een sorteer algoritme (of maar eens wat te noemen, neem bijvoorbeeld quicksort) druk je niet in objecten uit.

Ook dit punt is weer gelijk met nu. Ook nu claimt men weer dat iets complexiteit en overhead toe voegt. Misschien is dat wel zo, maar dat betekent niet dat we daarom concurency op een dergelijke manier moeten afwijzen zoals mensen hier dat doen.

Feit blijft dat het de gebruiker worst zal zijn of zijn app linksom of rechtsom gecompileerd wordt en op hoeveel cores het ding draait.

Dat is niet waar. Half technische gebruikers (publiek op FP) klaagt steen en been dat software niet al hun cores gebruikt.

het is dan ook écht niet de "holy grail" die jij er van (neigt) te maken.

Wordt eens wakker joh. ALLE CPU architecturen van de komende tijd gaan massaal inzetten op meerdere cores. Dat 80 core verhaal is niet zomaar een grapje van iemand, dat staat serieus op de roadmap van intel (als aangekondigd op het intel developers forum). Op de zeer korte termijn zullen dual en quad cores volledig mainstream worden. Gebruikers zullen eisen dat jij die van werk voorziet. Niks "holy grail", gewoon gebruik maken van de resources die je hebt. De komende jaren zullen dat voornamelijk meer cores zijn. Wellicht dat er daarna weer wat anders komt, maar voorlopig zul je wel mee moeten.

En wil jij die cores niet van werk voorzien? Rahid, Akira, en Wei Xang staan te trappelen om je werk over te nemen...

[MBV]

Er zit alleen wel een verschilletje. OOd is voor veel dingen handig, om dingen inzichtelijk te maken enzo. Onderhouds- en ontwikkelkosten gaan hierdoor omlaag, mits goed toegepast. Multithreading brengt die kosten in weinig gevallen (voorbeeld van een uitzondering: hard-realtime systemen) omlaag. Het zal dus altijd meer kosten om een goed multithreaded systeem te maken, in tegenstelling tot OOd.

Verder heb je wel een beetje gelijk dat we misschien de kop in het zand steken. Ik zal zodra ik tijd heb weer eens in een serieuze taal gaan programmeren, en lekker veel threads spawnen . Dat PHP begint me aardig de strot uit te komen 't levert alleen op het moment op een makkelijke manier geld op, en da's ook wat waard.

Maar ook als we meer getraind worden op multicore-proggen, wil ik een JVM en C++ compiler die vanzelf multi-threaded wordt. Is ook in 1 klap al die legacy-troep sneller

[LauPro]

Het argument van aparte thread voor GUI hoor ik vaak. Persoonlijk ben ik van mening dat dit eigenlijk een taak is van de toolkit die wordt gebruikt. QT heeft bijvoorbeeld imo veel potentie voor een mooie intergratie van threads in de GUI. Bij een aantal onderdelen zorgen componenten zelf voor aparte threads tegen het 'hangen' van de applicatie (o.a. datasets controls). Maar eigenlijk zou er een centraal object moeten komen waar je nieuwe jobs tegen aan kan gooien. Dit valt vast wel te scripten in een eigen lib (of die zijn er al). Maar gevaar daarbij is dat je weer een extra depency hebt. Dus zou een mooie feature voor QT zijn als je oftb workers tegen een core aan kan gooien. En dat je dan ook direct gecentraliseerd data beschikbaar hebt (bijv. de applicatie zelf ), met een QTread en QThreadStorage kom je een heel eind, maar vereist toch vaak wat gehack imo.

Daarnaast, zoals eerder aangegeven, kunnen de meeste applicaties die MT's nodig hebben echt wel overweg met meerdere cores. Het is een kwestie van vraag en aanbod. Met name in de Open Source wereld zijn er vaak een aantal visionairs die dit initiëren wat vervolgens door de rest in het project wordt opgepakt. Maarja, vaak erfenissen uit het verleden (Firebird, Interbase *kuche*) hebben nog nooit gehoord van threads, mja of er staat een 0.1 ergens in een repository te roesten.

Kijk bijv. ook naar de populaire OpenOffice en Mozilla (SpiderMonkey JS-engine). Ook hier spelen problemen dat het code is waar veel tijd in gaat zitten om dit MT te maken. OpenOffice is welliswaar Open Source, maar vrijwel niemand kan het opbrengen om het als hobby te debuggen. Al is het alleen maar dat het nauwelijks te compilen valt en je toch behoorlijk wat tijd nodig hebt om een goede debugomgeving op te zetten. Daarnaast is volgens mij C-code gedoemd om te mislukken in een MT-omgeving bij grote applicaties (vergelijkbaar met OOo).

Ik zie de Gecko-engine overigens niet zo heel snel lekker goed om gaan met MT. En zeker met Mozilla en aanverwanten is het af en toe wel huilen met de pet op als je na gaat hoeveel keuzes er worden gemaakt tussen ontwikkeltijd en reponsetijd. Een GUI opgebouwd op basis van XML aangestuurd via JavaScript is misschien zijn tijd ver vooruit maar geeft imo meer nadelen dan voordelen.

Een laatste opmerking: volgens mij valt een deel van de problemen ook op te lossen door betere terugkoppeling met de gebruiker. Als een applicatie op het punt staat om een file van 20MB aan te spreken dan is het naar mijn idee naïef om te denken dat dit geen terugkoppeling vereist. Als in dit soort situaties de gebruiker een simpele statusmelding krijgt ipv een hangende applicatie dan scheelt het al veel ergenis imo.

De stelregels voor desktopapplicaties naar mijn idee:
- Afhankelijk van de gewenste performance, gebruik C++, Java of .NET (voor tools zijn Perl, Ruby, Python e.d. te overwegen).
- Zorg voor terugkoppeling als een actie meer dan 100ms kan duren.

[Confusion]

Verwijderd schreef op donderdag 09 november 2006 @ 00:00:
Als ik dan tevens merk dat diverse andere mensen die hun sporen ruim verdiend hebben in de IT tot nagenoeg dezelfde conclusie komen, dan moet er toch wel een zekere kern van waarheid in zitten?

Natuurlijk zit er een kern van waarheid in. De meeste mensen hier hoor je toch ook niet zeggen dat je totale onzin uitslaat? Ze zwakken alleen het belang af dat jij er aan hecht.

Verwijderd schreef op donderdag 09 november 2006 @ 01:05:
*kuch* op 6de begonnen met programmeren [..]

Rob III trok jouw expertise niet in twijfel. Al was je Bjarne Stroustrup, Bill Joy, Kernighan and Ritchie, Guido van Rossum, the Gang of Four en Herb Sutter in 1, dan nog zijn jouw verwachtingen en angsten ten aanzien van een culturele ontwikkeling niet beter onderbouwd dan die van anderen in dit topic. Over de technische ontwikkeling zijn we het eens.

Er waren toch wel heel erg veel mensen die hier moeite mee hadden.

Tjah, maar dat kan ook iets met de cultuur die onder die mensen heerste te maken hebben gehad. Overheerste toen bijvoorbeeld niet veel meer de 'er zijn niet zoveel mensen die kunnen programmeren, ik kan het en ik weet het zelf wel' mentaliteit? De hele cultuur is volgens mij wel introspectiever geworden: doordat er veel meer om te weten is, zijn mensen zich meer bewust van de gebreken in hun kennis. Maar het is ook veel makkelijker geworden om informatie te vinden om gebreken aan te vullen.

maar ook dat het een andere manier van denken vereist

Ik zie dat niet. Programmeren vereist sowieso dat je een goede scheiding in functionaliteit en verantwoordelijkheden aanbrengt in je programma. Voor iemand die het parallel programmeren goed beheerst zou het niet moeilijk moeten zijn een goed geschreven programma te parallelliseren, omdat onafhankelijke taken zich makkelijk laten identificeren. En nou denk jij "een goed parallel programma moet vooraf parallel ontworpen zijn" en dan zeg ik: als OS en compiler/VM die taak deels op zich nemen en client programmas van nature grotendeels synchroon zijn (en dat zijn ze, omdat ze op gebruikersinput staan te wachten of gelimiteerd zijn door pakweg de CD brander), dan valt er bijna niets te winnen door je programma expliciet parallel te ontwerpen.

Bovendien wordt het verschil tussen benodigde processorcapaciteit en de beschikbare capaciteit steeds groter. Als ik eens een voorspelling mag doen, dan gaan er op termijn van een paar jaar bij Intel en AMD grote klappen vallen, omdat niemand meer snellere processoren koopt, omdat iedereen het wel best vind en ziet dat er geen winst meer te behalen is voor hun Internet Explorer, hun Microsoft Word en hun Nero.

Ook dit punt is weer gelijk met nu. Ook nu claimt men weer dat iets complexiteit en overhead toe voegt. Misschien is dat wel zo, maar dat betekent niet dat we daarom concurency op een dergelijke manier moeten afwijzen zoals mensen hier dat doen.

Ik zie niemand concurrency afwijzen. Je draaft door.

Wordt eens wakker joh. [..]

Nou draai je weer de standaard ratel af, die we inmiddels echt wel begrepen hebben, terwijl RobIII op geen enkele manier aangeeft het niet met je eens te zijn dat multicore de toekomst is.

En wil jij die cores niet van werk voorzien? Rahid, Akira, en Wei Xang staan te trappelen om je werk over te nemen...

Ja, en als de lonen niet omlaag gaan is dat ook zo. Daar worden we al jaren mee bang gemaakt; ik neem het niet serieus meer.

Het is me onduidelijk waar je je nou zorgen over maakt, want als jij hier wel goed in bent en andere mensen zijn dat niet, betekent dat alleen maar dat jouw marktwaarde hoger wordt. Wat maakt het jou nou uit dat andere mensen iets niet kunnen? Zolang je maar zorgt dat jouw collega's het leren, dan is jouw bedrijf straks het enige dat goede software levert. Where's the problem?

[ Voor 5% gewijzigd door Confusion op 09-11-2006 08:49 ]

[MBV]

Confusion schreef op donderdag 09 november 2006 @ 08:47:
[knip]
Ik zie dat niet. Programmeren vereist sowieso dat je een goede scheiding in functionaliteit en verantwoordelijkheden aanbrengt in je programma. Voor iemand die het parallel programmeren goed beheerst zou het niet moeilijk moeten zijn een goed geschreven programma te parallelliseren, omdat onafhankelijke taken zich makkelijk laten identificeren. En nou denk jij "een goed parallel programma moet vooraf parallel ontworpen zijn" en dan zeg ik: als OS en compiler/VM die taak deels op zich nemen en client programmas van nature grotendeels synchroon zijn (en dat zijn ze, omdat ze op gebruikersinput staan te wachten of gelimiteerd zijn door pakweg de CD brander), dan valt er bijna niets te winnen door je programma expliciet parallel te ontwerpen.

De rekenintensieve taken opdelen over meerdere cores (dus per taak meerdere cores) werkt toch echt wel een beetje anders. Maar verder ben ik het wel met je eens. Alleen zou ik de cd-brander vervangen door de harde schijf, dat kost bij desktop-applicaties de meeste tijd.

Bovendien wordt het verschil tussen benodigde processorcapaciteit en de beschikbare capaciteit steeds groter. Als ik eens een voorspelling mag doen, dan gaan er op termijn van een paar jaar bij Intel en AMD grote klappen vallen, omdat niemand meer snellere processoren koopt, omdat iedereen het wel best vind en ziet dat er geen winst meer te behalen is voor hun Internet Explorer, hun Microsoft Word en hun Nero.

Die klappen vallen nu al.

[knip]
Het is me onduidelijk waar je je nou zorgen over maakt, want als jij hier wel goed in bent en andere mensen zijn dat niet, betekent dat alleen maar dat jouw marktwaarde hoger wordt. Wat maakt het jou nou uit dat andere mensen iets niet kunnen? Zolang je maar zorgt dat jouw collega's het leren, dan is jouw bedrijf straks het enige dat goede software levert. Where's the problem?

En dat zegt een mod uit W&L?

[joepP]

Het potentiele nut van concurrency voor een losse applicatie is over het algemeen zeer beperkt. Hét grote voordeel van multicores zie ik op het gebied van multitasking. Een filmpje kijken, mp3-tjes encoden, cd-tje branden en browsen tegelijk, zonder vervelende slowdowns. Ik heb al bijna 10 jaar pc's met meerdere processors of meerdere cores onder mijn bureau staan, juist om deze reden. Ook voor applicatieservers is het ideaal.

Het nut van concurrency voor ontwikkelaars is in mijn optiek bijzonder minimaal. Ik onderscheid ruwweg drie mogelijkheden van concurrency.

1) Het is onmogelijk toe te passen of heeft geen nut. Veel (verreweg de meeste!) applicaties zijn niet te versnellen met gebruik van meerdere processors. Kantoorapplicaties, waar veruit de meeste ontwikkelaars aan werken, zijn een goed voorbeeld.

2) Het is mogelijk en eenvoudig toe te passen. Bijvoorbeeld een batch mp3-tjes encoden. In dit geval is het triviaal om gebruik te maken van meerdere cores: je spawnt gewoon een extra thread.

3) Het is toe te passen maar behoorlijk ingewikkeld. Denk hierbij aan games, databases als MSSQL/Oracle/whatever, sommige zware berekeningen en applicaties die door zeer veel mensen gebruikt worden (officepakketten). Hier werkt misschien een procent van de ontwikkelaars aan. Voor veel andere applicaties zal er wel wat winst te behalen zijn, maar moet daar nogal wat werk voor verzet worden. Over het algemeen zal dit niet lonen, de ontwikkeltijd zal dermate toenemen dat het geen voordeel zal blijken.

Hét grote probleem van parallel programmeren is dat er niet zoveel buiten deze groepen valt. Het is of triviaal, of ingewikkeld, of onmogelijk. Voor verreweg de meeste ontwikkelaars is het dus niet van toepassing. Voor de eindgebruikers echter -wel-, die zullen merken dat veelgebruikte software ietsjes sneller loopt, en vooral dat ze meerdere dingen tegelijk kunnen doen zonder hickups.

[MTWZZ]

MBV schreef op woensdag 08 november 2006 @ 14:19:
..verhaal..
_{Sorry trouwens dat ik de Intel C++ compiler erbij heb gehaald als voorbeeld. Ik ben denk ik de hoofdschuldige van jouw indruk}

^^ si

Overigens snap ik best dat C# gewoon gecompiled wordt etc. Het is alleen dat ik weinig terug zag op Google etc dus ik was gewoon even nieuwsgierig of er hier iemand zat die er wel wat vanaf wist.

[Confusion]

MBV schreef op donderdag 09 november 2006 @ 09:01:
De rekenintensieve taken opdelen over meerdere cores (dus per taak meerdere cores) werkt toch echt wel een beetje anders.

Ik heb weleens een simulatie geschreven die gebruik maakte van MPI, dus ik weet wat je bedoelt, maar hoeveel programma's hebben rekenintensieve taken die niet gemakkelijk in volledig onafhankelijke threads te scheiden zijn? De complexe problemen treden alleen op als informatie tussen threads uitgewisseld moet worden. En vaak zijn dat soort dingen toch al aan libraries uitbesteed en dan moeten die dus multiproc worden, wat buiten het bestek van de programmeur ligt die die libraries gebruikt.

[rrrandy]

joepP schreef op donderdag 09 november 2006 @ 10:05:

1) Het is onmogelijk toe te passen of heeft geen nut. Veel (verreweg de meeste!) applicaties zijn niet te versnellen met gebruik van meerdere processors. Kantoorapplicaties, waar veruit de meeste ontwikkelaars aan werken, zijn een goed voorbeeld.

3) Het is toe te passen maar behoorlijk ingewikkeld. Denk hierbij aan games, databases als MSSQL/Oracle/whatever, sommige zware berekeningen en applicaties die door zeer veel mensen gebruikt worden (officepakketten). Hier werkt misschien een procent van de ontwikkelaars aan. Voor veel andere applicaties zal er wel wat winst te behalen zijn, maar moet daar nogal wat werk voor verzet worden. Over het algemeen zal dit niet lonen, de ontwikkeltijd zal dermate toenemen dat het geen voordeel zal blijken.

Wat is het verschil

[Exirion]

Het had een interessant topic kunnen worden, maar door al dit ge-eikel en gezeik over OO blijft er weinig interessants over. Kan dat niet ergens anders uitgevochten worden? Ik heb het liever over processing en memory bottlenecks dan over het wel of niet moeilijk zijn van OO.

[.oisyn]

Met Exirion, ik zie niets anders dan oeverloos horn-tooting. Big deal.

[Verwijderd]

Confusion schreef op donderdag 09 november 2006 @ 08:47:
[...]
Natuurlijk zit er een kern van waarheid in. De meeste mensen hier hoor je toch ook niet zeggen dat je totale onzin uitslaat? Ze zwakken alleen het belang af dat jij er aan hecht.

Goed, dan verschillen we daarin van mening. Ik denk dat +- 78/80ste van beschikbare resources laten leggen wel degelijk zonde is, en dat het daarom zeer zeker wel een heel belangrijk issue is.

Zijsprong in de topic:

[quote]
[...over omschakelen van patronen...]
Ik zie dat niet.
[/quote]

Nu komen we misschien wat meer op jouw gebied, maar ik zie dat wel. Dit verschijnsel komt niet alleen bij programmeurs voor maar overal. Mensen van de 'mondelinge' generatie konden niet met knoppen omgaan. Mensen van de knoppen generatie kunnen niet met (elektronische) menu's omgaan. Het vergt telkens een ander gedachten patroon dan wat mensen gewend zijn.

Wat is er zo moeilijk aan het indrukken van een knop? Mensen van de mondelinge generatie lukte dit niet. Ik kan me nog goed herinneren dat mijn oma een video band wilde afspelen. Er hoefde alleen maar op "play" gedrukt te worden. Dit lukte haar niet. Een mondeling commando kon ze echter wel geven, "zeg henk, wil jij de band afspelen?". Dit vertaald zich bijna 1:1 naar de knop actie, want ik steek mijn hand uit en druk op "afspelen".

1 generatie daarna. Mijn moeder is van de knoppen generatie. Een knop indrukken is geen probleem voor haar. De CD speler, video recorder, etc. Geen probleem. Elke functie heeft een vaste knop en mijn moeder kan daar mee omgaan. Enter the HDD-recorder en computer. Geen vaste knoppen. De knoppen die er zijn hebben een context gevoelige functie: ok, cancel, "contect menu'. Dat wil zeggen, je selecteert iets en de functie hangt af van je selectie. Je raad het al, mijn moeder pikt dit niet op. Zit ik een half uur uit te leggen hoe je door menu's navigeert en vraagt ze meteen daarna: "maar welke knop moet ik nu indrukken om op te nemen"?

De moraal van het verhaal: mensen hebben een mentaal model voor bepaalde taken in hun hoofd. Op een gegeven moment (grofweg vanaf een bepaalde leeftijd) kan het gros van de mensen hier niet meer van afwijken. Mijn oma's mentale model was mondelinge commando's geven, mijn moeders mentale model is vaste knoppen indrukken.


Gaan we terug naar het programmeren, dan zie je heel duidelijk dat een structurele programmeur ook in een OO taal structureel zal proberen te blijven werken. Een imperatieve programmeur zal in een functionele programmeur taal dikwijls toch imperatief proberen te blijven werken.

Ik blijf bij mijn punt dat programmeurs over pak hem beet een jaar of 5, die vanaf het begin getraind worden in parallel denken, veel minder moeite hebben om cores van werk te voorzien en ook veel meer het voordeel ervan in zien om dat te gaan doen.

Ook al zeg jij nu dat je de toekomst wel inziet in concurency, diep van binnen blijf je het denk ik toch iets raars vinden, iets wat alleen 'speciale' programma's nodig hebben. Voor mensen die opgroeien in de parallelle wereld zal het gewoon een tool zijn in hun toolset, die ze toepassen waar nodig. Dat wil niet zeggen dat ze het overal gaan toepassen of dat het makkelijk is. Als ik naar het heden kijk dan maak ik ook nu niet overal een object van, en soms blijft het een lastige opgave om het geheel van functionaliteit zo goed mogelijk over een groep van objecten te verdelen.

Als ik eens een voorspelling mag doen, dan gaan er op termijn van een paar jaar bij Intel en AMD grote klappen vallen, omdat niemand meer snellere processoren koopt, omdat iedereen het wel best vind en ziet dat er geen winst meer te behalen is voor hun Internet Explorer, hun Microsoft Word en hun Nero.

Het is waar dat we aan de ene kant nog steeds op zoek zijn naar de "killer application"; de applicatie die enorm veel resources vraagt en die iedereen wil gebruiken.

Aan de andere kant heb je ook het fenomeen "Andy giveth, and Bill taketh away"

There’s an interesting phenomenon that’s known as “Andy giveth, and Bill taketh away.” No matter how fast processors get, software consistently finds new ways to eat up the extra speed. Make a CPU ten times as fast, and software will usually find ten times as much to do (or, in some cases, will feel at liberty to do it ten times less efficiently).

Dat laatste klinkt negatief, maar is het niet altijd. Ik zou mijn huidige code misschien 10x efficiënter kunnen schrijven. Als ik kijk naar hoe ik vroeger in assembly voor de C64 programmeerde dan zie ik een heel groot verschil. Dat was de tijd dat ik cycles aan het tellen was omdat we met een cycle quota werkte. We zette data op gekke plekken neer, zodat we die zelfde data konden hergebruiken als opcodes (jump between opcodes). Dan zat je soms 2 middagen te puzzelen om op deze manier misschien wel 10 bytes aan geheugen te besparen.

Efficiëntie qua machine resource gebruik was toen top, maar de menselijke resources werden wel heel kwistig verspild.

Vandaag de dag zie ik wat dat betreft een betere balans. Een deel van de resources eten we op zodat we sneller kunnen developen en zodat code beter onderhoudbaar is. Als ik nu ergens een stukje code voor de leesbaarheid wil opsplitsen in meerdere functies dan doe ik dat gewoon. In het begin van mijn professionele carrière was zoiets echter not-done, omdat elke functie call overhead was en je eigenlijk alleen functies gebruikte als dat echt functioneel noodzakelijk was.

Zolang je maar zorgt dat jouw collega's het leren, dan is jouw bedrijf straks het enige dat goede software levert. Where's the problem?

Tsja, maar ik schrijf natuurlijk niet alles van scratch, en als we personeel aannemen dan zien we toch graag dat die gewoon al wat dingen kunnen. Als ik primair mensen wil opleiden had ik beter mijn eigen opleidings centrum kunnen beginnen, niet waar?

[ Voor 3% gewijzigd door Verwijderd op 09-11-2006 11:56 ]

[Verwijderd]

.oisyn schreef op donderdag 09 november 2006 @ 11:52:
Met Exirion, ik zie niets anders dan oeverloos horn-tooting. Big deal.

Heb je eigenlijk wel gelijk in, en dat terwijl ik net nog een grote post deed die hier nog even verder op in ging.

1 van de concrete dingen die ik zie waarmee je in een enterprise application zeer makkelijk concurency kunt uitbuiten is een deel van je logica als het high-level concept "job" te implementeren. In mijn geval werk ik in een Java EE omgeving en maak gebruik van een job scheduler die Quartz heet. In onze applicatie voor online data analyse kunnen users zich inschrijven. Nadat een inschrijving aangevraagt wordt gebeuren er veel dingen. Zo wordt er online contact opgenomen met andere systemen om dingen te controleren, worden er diverse entries in een DB aangemaakt, worden er wat accounts aangemaakt op andere systemen en gaan er nog wat emails de deur uit.

In een oudere versie van ons systeem stond dit allemaal in 1 sequentieel stuk code. Nu hebben we het re-factored naar een paar jobs. Zodra elke van deze jobs klaar is wordt er alleen een kleine status flag in een shared structure gezet die weer wordt gebruik om de user via een progress bar op de hoogte te houden. Een aantal triviale jobs (zoals het versturen van de emails) fungeren dan als fire & forget en geven geen feedback terug.

Via deze manier hebben we de tijd dat een user moet wachten totdat z'n aanmelding gereed is behoorlijke weten te verkorten op onze 8 core server.

Over het algemeen zien we dat ook bij serverside applicaties het de moeite loont om per request concurency uit te buiten. Ondanks dat we toch wel redelijk veel requesten afhandelen, zien we dat in de praktijk enkele users toch lang moeten wachten. De simpele requesten worden weliswaar netjes over alle 8 cores verdeeld, maar het komt niet zelden voor dat 1 user iets zwaars doet en 1 core op 100% staat, terwijl de andere cores slechts voor enkele percentages belast zijn.

[joepP]

Verwijderd schreef op donderdag 09 november 2006 @ 12:21:
[...]
Heb je eigenlijk wel gelijk in, en dat terwijl ik net nog een grote post deed die hier nog even verder op in ging.

1 van de concrete dingen die ik zie waarmee je in een enterprise application zeer makkelijk concurency kunt uitbuiten is een deel van je logica als het high-level concept "job" te implementeren.

... verhaal over uitvoering...

Het door jouw beschreven scenario valt in mijn categorie triviaal, no pun intended. Wat je hier doet is het werk verdelen in jobs, en deze door een aantal "worker threads" te laten afhandelen. Ontwerptechnisch is dit een mooie oplossing, maar eigenlijk is het niet heel veel geavanceerder dan een applicatie 8x opstarten. Natuurlijk is dit ontwerp wel beter, maar voor dit soort werk hoef je echt geen specifieke opleiding genoten te hebben. Een gezond verstand is genoeg.

Probeer eens een situatie te bedenken waarin je als programmeur terecht kan komen, die met concurrency veel snellere software oplevert, maar niet zo "simpel" is... Ik ben heel benieuwd.

[Exirion]

joepP schreef op donderdag 09 november 2006 @ 12:38:
Probeer eens een situatie te bedenken waarin je als programmeur terecht kan komen, die met concurrency veel snellere software oplevert, maar niet zo "simpel" is... Ik ben heel benieuwd.

Een voorbeeldje uit de praktijk: medical imaging. Allerlei algoritmen die bewerkingen uitvoeren op 3D data sets van soms gigabytes groot. Er wordt gestreefd naar zo snel mogelijke verwerking (op den duur liefst real-time) en je probeert daarbij voortdurend het maximale uit een systeem te halen. Dat geldt voor calculatie op zich, alswel de toegang tot de data om die berekeningen uit te voeren.

Dit stelt hele hoge eisen aan de opbouw van je algorithmen, de datastructuren, en de parallelisatie van het geheel. Sommige algoritmen laten zich prima paralleliseren omdat er weinig/geen dependencies zijn, maar vaak zijn verschillende threads weldegelijk van elkaar afhankelijk en moet je alles zo uitdokteren dat een thread nooit te lang stil staat om te wachten op een andere. Verder heb je te maken met zo effcient mogelijk cache-gebruik, en ordening van je data zodat geheugenaccess zo snel mogelijk gaat.

En het is nog lastiger als de performance van een algoritme state-dependent is, oftewel: afhankelijk van de data waar het mee werkt. Dan zul je soms tussentijds herordening van je data moeten doen om de performance op peil te houden. Enfin, genoeg enorme uitdagingen die echt niet zo triviaal zijn.

[Verwijderd]

joepP schreef op donderdag 09 november 2006 @ 12:38:
[...]
Het door jouw beschreven scenario valt in mijn categorie triviaal, no pun intended.

Als je beter gelezen had dan was dat ook juist de bedoeling van dit voorbeeld:

1 van de concrete dingen die ik zie waarmee je in een enterprise application zeer makkelijk concurency kunt uitbuiten is een deel van je logica als het high-level concept "job" te implementeren

Het ging dus juist om een bijna triviaal voorbeeld Toch laten veel mensen dergelijke high-level concurency nog liggen, terwijl hier zeer eenvoudig winst te halen is.

100% triviaal is het initieel trouwens niet. De standaard practice is toch dat men dit soort berekeningen doet in de context van een request. Browser doet request -> app gaat iets doen -> app geeft response terug.

In de opzet die ik boven beschreef komt de response ogenblikkelijk terug en rendert slechts een progress bar component op de pagina. Deze progress bar neemt via periodieke AJAX calls contact op met de server. Daar is 1 centraal aanspreek punt, de user job manager. Deze heeft ook toegang tot de shared structure waar de afzonderlijke jobs toegang tot hebben, en beantwoord dan elke AJAX request met de juiste voortgang data.

Zo'n shared structure bevind zich dikwijls in application scope. Je moet daarbij goed rekening houden dat deze expliciet opgeruimd wordt als de job klaar is. Vanwege het asynchrone karakter van de communicatie tussen de client, view en jobs kun je deze namelijk niet gewoon in request / page scope hebben, en de garbage collector zal je dus ook hier niet helpen.

Ontwerptechnisch is dit een mooie oplossing, maar eigenlijk is het niet heel veel geavanceerder dan een applicatie 8x opstarten.

Nee, zo simpel is het nou ook weer niet. Dat zou het alleen zijn als ALLE jobs van de genoemde aanmelding fire & forget waren

Probeer eens een situatie te bedenken waarin je als programmeur terecht kan komen, die met concurrency veel snellere software oplevert, maar niet zo "simpel" is... Ik ben heel benieuwd.

Waar in ons geval de meeste winst te behalen zou zijn is de feitelijke data analyse zoveel mogelijk parallel af te handelen. In een sub-ruimte van het probleem is het noodzakelijk om een sterk vertakte dataset te doorlopen. Dit is in essentie een recursief probleem en leent zich dus zeer goed voor threading. De moeilijkheid zit hem in de coördinatie. Beslissingen om een vertakking in de data lokaal door een thread te laten nemen klinkt aanvankelijk aantrekkelijk, maar als je dat doet dan explodeert het aantal threads wat je creëert. Het is een beetje een parallelle variatie op de bekende breadth-first of depth-first zoek algoritmes in een tree.

Onze voorlopige aanpak is om in de root met een lokale thread-pool manager te werken; deze beheert het maximaal aantal threads per probleem instantie. Vanwege de breadth/depth eigenschappen, moet je er ook voor zorgen dat er een prioriteit komt op de requesten, afhankelijk van van hoe diep de request komt. Een probleem is namelijk dat het doorlopen van de set nogal chaotisch gaat. 1 thread kan 100 nodes de diepte in schieten, terwijl andere nodes heel sterk vertakt zijn en op niveau 1 al 100 threads proberen te requesten. De uitdaging is om hier een beetje balans in te krijgen. Met 8 cores bezet hebben we momenteel een speed-up van een +- factor 3 bereikt, maar het gaat echt om een proto-type die waarschijnlijk nog een stuk beter kan.

[Confusion]

Exirion schreef op donderdag 09 november 2006 @ 11:06:
Het had een interessant topic kunnen worden, maar door al dit ge-eikel en gezeik over OO blijft er weinig interessants over. Kan dat niet ergens anders uitgevochten worden? Ik heb het liever over processing en memory bottlenecks dan over het wel of niet moeilijk zijn van OO.

Dan start je toch lekker een topic dat wel bedoelt is om over de technische details van concurrency the gaan, in plaats van moord en brand te schreeuwen dat het topic wel gaat over het onderwerp dat de topicstarter aankaartte? Niet ieder topic hoeft te gaan over iets dat jij interessant vind, ook niet als het raakt aan een van je liefste onderwerpen.

[joepP]

Verwijderd schreef op donderdag 09 november 2006 @ 13:17:
Waar in ons geval de meeste winst te behalen zou zijn is de feitelijke data analyse zoveel mogelijk parallel af te handelen. In een sub-ruimte van het probleem is het noodzakelijk om een sterk vertakte dataset te doorlopen. Dit is in essentie een recursief probleem en leent zich dus zeer goed voor threading. De moeilijkheid zit hem in de coördinatie. Beslissingen om een vertakking in de data lokaal door een thread te laten nemen klinkt aanvankelijk aantrekkelijk, maar als je dat doet dan explodeert het aantal threads wat je creëert. Het is een beetje een parallelle variatie op de bekende breadth-first of depth-first zoek algoritmes in een tree.

Dit is een fatsoenlijk voorbeeld van het mogelijke nut van concurrency. Echter, de applicatie waar jij aan werkt is waarschijnlijk belangrijk (=duur) genoeg om dit soort optimalisaties door te voeren. Voor veruit de meeste applicaties geldt dit echter niet.

Jij loopt nu tegen concurrency voordelen aan, en denkt direct dat het nu het allerbelangrijkst is dat we ons allemaal grondig hierin gaan verdiepen. Dat is niet zo vreemd: iemand die een bepaald soort mieren bestudeert vindt dat vast ook van groot belang. Maar dat is het niet voor de meeste mensen. Hetzelfde geld voor concurrency.

Exirion schreef op donderdag 09 november 2006 @ 13:14:
Een voorbeeldje uit de praktijk: medical imaging. Allerlei algoritmen die bewerkingen uitvoeren op 3D data sets van soms gigabytes groot. Er wordt gestreefd naar zo snel mogelijke verwerking (op den duur liefst real-time) en je probeert daarbij voortdurend het maximale uit een systeem te halen. Dat geldt voor calculatie op zich, alswel de toegang tot de data om die berekeningen uit te voeren.

...

Uitstekend.

Dat is precies wat ik bedoel met een verre van triviale toepassing van concurrency. Maar dit soort werk wordt vooral gedaan aan universiteiten, en heeft daarom voor 99% van de programmeurs geen relevantie. Dat is ook waarom ik om een voorbeeld vroeg: bijna niemand heeft in de praktijk te maken met dit soort problemen.

En dat brengt me bij het centrale punt: voor de meeste programmeurs is concurrency totaal onbelangrijk. Of het is triviaal, of het is niet de moeite. De hele stelling van de topicstarter dat "concurrency enorm belangrijk gaat worden" slaat dan ook nergens op.

[Exirion]

joepP schreef op donderdag 09 november 2006 @ 13:56:
Dat is precies wat ik bedoel met een verre van triviale toepassing van concurrency. Maar dit soort werk wordt vooral gedaan aan universiteiten, en heeft daarom voor 99% van de programmeurs geen relevantie. Dat is ook waarom ik om een voorbeeld vroeg: bijna niemand heeft in de praktijk te maken met dit soort problemen.

Ik denk dat je hier toch een foute inschatting maakt. Dit is slechts 1 voorbeeld waar concurrency absoluut zinvol is, en dat werk wordt echt niet alleen maar aan universiteiten gedaan. Alleen al bij de 2e grootste speler op de medical imaging markt zijn er honderden of duizenden mensen die ermee te maken hebben. Niet de hele wereld bestaat uit tekstverwerkers/databases/servers, dus er zijn nog heel veel toepassingen te bedenken waar concurrency een grote impact heeft, en waar heel veel mensen bij bedrijven mee te maken hebben.

En dat brengt me bij het centrale punt: voor de meeste programmeurs is concurrency totaal onbelangrijk. Of het is triviaal, of het is niet de moeite. De hele stelling van de topicstarter dat "concurrency enorm belangrijk gaat worden" slaat dan ook nergens op.

Ben ik niet met je eens. Hoe groffer de granulariteit van je software, hoe moeilijker zoiets optimaal zal draaien op een multi-core en/of multi-CPU systeem. Je zult op z'n minst moeten kijken naar hoe software parallel te maken is, en zodanig in brokken opsplitsen dat het OS er iets van kan maken dat goed performt. En aangezien het OS geen inzicht heeft in allerlei algorithme-specifieke aspecten, zal dat nooit zo goed performen als wanneer de developer de karakteristieken van de algoritmen meeneemt in de implementatie, zodanig dat de CPU cores allemaal nooit uit hun neus staan te eten. Daarbij ook nog rekening houdend met efficient L1/L2-cachegebruik. In het geval van NUMA-systemen, ook met de verdeling van de data en de code over de verschillende CPU's.

[Creepy]

Het feit dat iets triviaal lijkt maakt het natuurlijk niet minder belangrijk. Het feit is dat er helaas maar weinig mensen zijn die echt weten hoe ze een probleem kunnen opdelen in meerdere stukken dat kunnen toekennen aan een aantal worker threads.

Vandaag de dag zijn er nog genoeg applicaties met blocking GUI's of applicaties die alles met 1 thread afhandelen maar tussendoor de GUI wel updaten.

Concurrency gaat wat mij betreft wel steeds belangrijker worden. Waar het eerst (voornamelijk) het domein was van de OS bouwers om zo multitasking e.d. goed te kunnen krijgen wordt het naar mijn idee ook steeds meer het domein van de applicatie ontwikkelaars. De hoeveelheden data wordt steeds groter en de gebruikers eisen steeds meer qua verwerkingssnelheid van hun systeem. De rek qua CPU snelheid wordt steeds minder waardoor je parallel moet gaan werken.

Daarnaast zie je web app's steeds meer opkomen. Die hebben als nadeel dat de interface minder direct reageert. Door slim verschillende functionaliteit op te delen en in losse stukjes binnen te laden kan de indruk worden gewekt dat de interface supersnel reageert. Ook hier zul je dus de zaken moeten opsplitsen om zoveel mogelijke kleine zaken parallel te laten lopen.

[LauPro]

@Creepy, toch blijf ik van mening dat die optimalisaties voor een groot deel vanuit het OS/de toolkits moeten komen. Inmiddels zullen een aantal mensen zelf een dergelijk platform hebben ontwikkeld, maar dat is een beetje hetzelfde als met AJAX. Vroeger zag je wel custom implementaties, nu zijn er standaard libraries beschikbaar waarbij je geen woord JavaScript meer hoeft te schrijven.

[Exirion]

LauPro schreef op donderdag 09 november 2006 @ 14:28:
@Creepy, toch blijf ik van mening dat die optimalisaties voor een groot deel vanuit het OS/de toolkits moeten komen. Inmiddels zullen een aantal mensen zelf een dergelijk platform hebben ontwikkeld, maar dat is een beetje hetzelfde als met AJAX. Vroeger zag je wel custom implementaties, nu zijn er standaard libraries beschikbaar waarbij je geen woord JavaScript meer hoeft te schrijven.

IMHO moet je een heel duidelijk onderscheid maken tussen de native gecompileerde talen, de virtual machine talen, en de scripttalen. Ik kan jouw mening begrijpen als je gefocust bent op scripttalen, maar dat komt ook door de achtergrond van die talen: hoge mate van transparantie en platformonafhankelijkheid. Bij Java en C# zie je dat ook duidelijk, en veel mensen die daarin hebben leren programmeren zijn gewoon niet gewend om te denken aan systeemaspecten. Ga je kijken naar C en C++, en het domein waarin die talen nog heer en meester zijn (embedded software en performance-kritische toepassingen zoals grafische bewerking en rendering) dan is het niet reeel om te stellen dat alles maar onder water opgelost zou moeten worden. Die talen zijn dermate low-level dat je te maken hebt met de concrete opbouw van datastructuren, direct geheugentoegang, etc. De compiler kan alleen tamelijk elementaire optimalisaties doorvoeren in de assemblycode die het uitspuugt.

[Verwijderd]

Exirion schreef op donderdag 09 november 2006 @ 14:40:
Ga je kijken naar C en C++, en het domein waarin die talen nog heer en meester zijn (embedded software en performance-kritische toepassingen zoals grafische bewerking en rendering) dan is het niet reeel om te stellen dat alles maar onder water opgelost zou moeten worden. Die talen zijn dermate low-level dat je te maken hebt met de concrete opbouw van datastructuren, direct geheugentoegang, etc. De compiler kan alleen tamelijk elementaire optimalisaties doorvoeren in de assemblycode die het uitspuugt.

Maar ook bij deze talen zie je dat een compiler meer en meer optimalisaties door kan voeren omdat deze steeds slimmer worden. Hiermee wil ik niet zeggen dat hetgeen je zegt helemaal onzin is want ik ben het in grote lijnen wel met je eens. Ik denk echter dat op dat gebied er ook steeds meer gedaan kan worden door bijvoorbeeld een compiler.

[ Voor 19% gewijzigd door Verwijderd op 09-11-2006 14:59 ]

[LauPro]

Exirion schreef op donderdag 09 november 2006 @ 14:40:
[...]
IMHO moet je een heel duidelijk onderscheid maken tussen de native gecompileerde talen, de virtual machine talen, en de scripttalen. Ik kan jouw mening begrijpen als je gefocust bent op scripttalen, maar dat komt ook door de achtergrond van die talen: hoge mate van transparantie en platformonafhankelijkheid. Bij Java en C# zie je dat ook duidelijk, en veel mensen die daarin hebben leren programmeren zijn gewoon niet gewend om te denken aan systeemaspecten. Ga je kijken naar C en C++, en het domein waarin die talen nog heer en meester zijn (embedded software en performance-kritische toepassingen zoals grafische bewerking en rendering) dan is het niet reeel om te stellen dat alles maar onder water opgelost zou moeten worden. Die talen zijn dermate low-level dat je te maken hebt met de concrete opbouw van datastructuren, direct geheugentoegang, etc. De compiler kan alleen tamelijk elementaire optimalisaties doorvoeren in de assemblycode die het uitspuugt.

Op dit moment ben ik meer bezig met C++/Java dan met scripttalen juist om tunnelvisie te voorkomen. En ik denk, dat op het moment dat je bijvoorbeeld bezig bent in een taal als Java dat het juist wel de taak is van het onderliggende platform om hele banale optimalisaties te doen. Neem bijvoorbeeld wxWindows waar je zelf (als programmeur) de events die van het scrollwieltje af komen moet implementeren zodat een listview 'scrollt'. Dit vind ik geen taak voor de programmeur. Evenals het opzetten van een platform die jobs af wikkelt, dit zou eigenlijk vanuit het platform moeten komen.

Dat is ook de reden van de stelregels uit mijn eerdere betoog. Als je serieus van mening bent dat iets in C moet worden geprogrammeerd vanwege de performance (PIC-programming daargelaten) dan hoef je inderdaad niet veel optimalisaties te verwachten. Maar als je bijvoorbeeld een applicatie schrijft in QT dan is het toch zeer opmerkelijk dat je nog zelf de job-scheduler moet implementeren, die zou in QT moeten zitten mijns inziens.

En als het echt gaat om software die goed moet worden geoptimaliseerd (verder dan noodzakelijk in een reguliere commerciële applicatie) dan kom je sowieso al op een expert gebied welke waarschijnlijk alleen bij wetenschappenlijke onderzoeken zullen worden toegepast (of je hebt het over iets heel low-level als een kernel), of als oefening/vermaak van de programmeur. Dit laatste vind ik niet realistisch voor de praktijk in het dagelijks leven.

[ Voor 1% gewijzigd door LauPro op 03-12-2006 15:46 . Reden: typfoutje ]

[Verwijderd]

joepP schreef op donderdag 09 november 2006 @ 13:56:
[...]
Dit is een fatsoenlijk voorbeeld van het mogelijke nut van concurrency. Echter, de applicatie waar jij aan werkt is waarschijnlijk belangrijk (=duur) genoeg om dit soort optimalisaties door te voeren. Voor veruit de meeste applicaties geldt dit echter niet.

Nee, maar ik voelde het al aankomen dat jij op deze manier zou gaan reageren. Daarom was mijn eerste voorbeeld ook de meer triviale case. Online data analyse is geen common case, zeker niet in ons geval (betreft wetenschappelijke data, hoewel wij wel een commerciële partij zijn).

Mijn grootste concurency winst heb ik op een nog mindere common case gehaald. Samen met een wetenschapper (ben ik eigenlijk zelf ook kwa opleiding, maar dat terzijde), heb ik een opdracht gedaan voor een grote winkelier in Nederland. Het ging erom om de invulling van de rekken in de winkels zo optimaal mogelijk te bepalen. Na simulaties op een kleine (maar representatieve) set kwamen we op een genetisch algoritme. Enige nadeel was, dit draaide veel te langzaam. We hebben toen een parallelle versie geschreven. In het kort kwam het erop neer dat we random het oplossingen landschap met individuele populaties bevolkten, waarbij om de zoveel generaties individuals met een bepaalde kans konden migreren naar andere populaties. De schoonheid in deze oplossing zat hem erin dat er 0 data dependencies waren en dat de communicatie overhead minimaal was. Een individu kon gecodeerd worden in een zeer klein pakketje en de uitwisselingen waren niet frequent. We hebben dit uiteindelijk met een extreem hoge performance op een cluster kunnen laten werken.

Deze case is trouwens niet het soort concurency waarop ik doelde toen ik deze topic begon, maar aangezien er vraag was naar 'niet simpele' cases wilde ik deze toch even noemen.

Jij loopt nu tegen concurrency voordelen aan, en denkt direct dat het nu het allerbelangrijkst is dat we ons allemaal grondig hierin gaan verdiepen.

Fout! Ik ben al wat langer met concurency bezig en heb daar nooit iemand mee 'lastig gevallen', omdat het inderdaad om uitzonderlijke gevallen ging. In 1997 had bijna niemand thuis een dual en al helemaal geen cluster. De kloksnelheden gingen nog bijna dagelijks omhoog, dus er was geen noodzaak.

Vandaag de dag is dat anders. In 2007 zullen duals en quads helemaal mainstream worden, en alle roadmaps van nagenoeg alle cpu bakkers wijzen alleen maar in de richting van meer cores.

DAAROM begin ik er NU over. De voordelen van concurency zag ik zelf al meer dan 10 jaar geleden.

[MBV]

Verwijderd schreef op donderdag 09 november 2006 @ 12:21:
[...]


Heb je eigenlijk wel gelijk in, en dat terwijl ik net nog een grote post deed die hier nog even verder op in ging.

1 van de concrete dingen die ik zie waarmee je in een enterprise application zeer makkelijk concurency kunt uitbuiten is een deel van je logica als het high-level concept "job" te implementeren. [knip]

Dit doet me heel sterk denken aan QT met zijn signal-slot systeem, waar je ook heel simpel fire-and-forget functies van kan maken. QT heeft nou eenmaal een goed doordacht framework staan. Enige nadeel is dat de implementatie 10 jaar geleden is gedaan, toen stdlib nog niet echt standaard was

joepP schreef op donderdag 09 november 2006 @ 13:56:
[...]

Dit is een fatsoenlijk voorbeeld van het mogelijke nut van concurrency. Echter, de applicatie waar jij aan werkt is waarschijnlijk belangrijk (=duur) genoeg om dit soort optimalisaties door te voeren. Voor veruit de meeste applicaties geldt dit echter niet.

Ok, dan gaan we naar hét soft-realtime probleem van vandaag de dag: HD-TV weergeven op generieke PC-hardware. Is daar genoeg interesse voor?
Mag ik een paar taken noemen die je kan opdelen in threads, maar waarbij je eigenlijk een echt real-time OS nodig hebt qua scheduler:
- demux (opdelen in audio-video)
- audio uitpakken
- audio weergeven
- video waren 10 stappen voor, die weet ik niet allemaal meer. allemaal langsgekomen tijden Real Time Architecture op de tu/e, 'k zal eens kijken of ik de slides kan vinden.

De enige oplossing bleek om de beeldverwerking zwaar parallel te doen: op je videokaart. Zelfs een Core2Single topmodel kan nog niet real-time de video verwerken.

LauPro schreef op donderdag 09 november 2006 @ 15:11:
[...]
Neem bijvoorbeeld wxWindows waar je zelf (als programmeur) de events die van het scrollwieltje af komen moet implementeren zodat een listviews 'scrollt'.

Dat meen je niet In QT moet je hier en daar wat koppelingen maken, maar zelf code voor schrijven? Voor een scroll-wieltje in een standaard-element? Verplicht?

Dat is ook de reden van de stelregels uit mijn eerdere betoog. Als je serieus van mening bent dat iets in C moet worden geprogrammeerd vanwege de performance (PIC-programming daargelaten) dan hoef je inderdaad niet veel optimalisaties te verwachten. Maar als je bijvoorbeeld een applicatie schrijft in QT dan is het toch zeer opmerkelijk dat je nog zelf de job-scheduler moet implementeren, die zou in QT moeten zitten mijns indiens.

't is opensource, dus ga je gang . Bedoel ik nog vrij serieus ook: als je een goed nieuw component hebt voor QT, dan zou je ze daar waarschijnlijk erg blij mee maken. Voordeel voor jouw: geen onderhoud meer daaraan, als het fout gaat gaat het in het framework fout
Maar wat bedoel je precies met job-scheduler? Een paar jobs fire&forget afschieten kan toch prima met signal/slot?

[H!GHGuY]

flowerp schreef op dinsdag 07 november 2006 @ 22:42:
Precies wat men vroeger zei; een word processor op een 100Mhz CPU moeten draaien is klinkklare onzin. De grootste overeenkomst is de beperkte visie die mensen zoals jij hebben. Toen keek men naar het huidige aanbod en zag dat word processors op 33Mhz machines redelijk draaiden. Mensen met weinig inbeeldings vermogen konden slechts lijntjes doortrekken en in hun belevings wereld was een word processor op een 100Mhz CPU dus ook inderdaad onzin.

Dit is helemaal iets anders. De meeste programma's hebben er wel baat bij dat een processor van 33 naar 100Mhz gaat. Dat is omdat als een taak maar op 1 processor kan lopen, je ook effectief 3 maal sneller gaat (enkel processor kracht). Een systeem is veel meer dan enkel processor kracht.

Als jij moet wachten op een word processor dan is dit waarschijnlijk omdat het ding op je harde schijf aan het lezen is. Veel taken lenen zich niet gemakkelijk tot parallellisering.
Kijk nou bvb naar spellingcontrole. Elke letter die jij intypt triggert de spellingscontrole op de zin die je typt. Merk je daar iets van, behalve het icoontje onderaan? Helemaal niets omdat de word processor geoptimaliseerd is om lokaal te gaan werken.
Dat is 1000maal simpeler en logischer dan telkens opnieuw een thread te starten per paragraaf.

Ik werk nu aan embedded software. 5 computers(meer dan 5-proc's alleen) in een 2-U rack
met op elk bord een thread of 50. race-problemen, data access problemen e.d. zijn dus dagelijkse kost. Het kost meestal waarschijnlijk zelfs meer processor kracht om telkens gegevens tussen thread te kopieren (messaging en dergelijke) dan om de data te verwerken. De meeste threads zijn er dan ook omdat ze een logische werkeenheid vormen.

Los daarvan werk ik in mijn vrije tijd aan de volgende versie van mijn programma. Waarin ook een tiental threads samenwerken. De enige reden waarom ik dat doe is om blocking sockets te kunnen gebruiken zonder me om iets zorgen te maken. Het ding is bedoeld om op servers te draaien en mag dus zowat geen CPU nemen.

Ik weet dus heus wat MT werken is. Ik vraag me gewoon luidop af of 90% van de taken die Jan "Kantoor" uitvoert geschikt zijn. Zeker weten dat databases, webservers, games, bepaalde vormen van encoding/decoding en andere CPU intensieve applicaties ervan kunnen profiteren. Maar of de meeste taken geparallelliseerd kunnen worden betwijfel ik.

Ik kan me wel inbeelden dat een browser het renderen in een tweede thread doet of dat bepaalde I/O in een andere thread kan gestopt worden, maar wordt dit nu ook al niet gedeeltelijk gedaan?

Ik vraag me ook af wat we van compilers mogen verwachten. We weten hopelijk allemaal dat weten of een programma ooit eindigt zonder het uit te voeren een NP-compleet probleem is. Je kan je dus even goed afvragen in hoeverre een compiler zonder uitvoeren van een programma ook effectief threading in kan voeren in iets wat sequentieel is geschreven.

Neem bvb een eenvoudig voorbeeld in pseudo C++

C++:

class A
{
   void eenMethod(B* b) 
   {
      /*doe iets met b*/
      // o.a. het volgende
      b->myProperty--;
   }
}

class B
{
   void eenMethod()
   {
       A a;
       a.eenMethod(this);
       // doe hier nog veel andere dingen
       // bvb dit:
       myProperty++;
   }
   int myProperty;
}

wil je je compiler dit laten MT maken, dan moet je de vereiste hebben dat in de code na a.eenMethod(this) geen data aangeraakt wordt die eenMethod van de B klasse aanraakt.
Je kan wel sync-points instellen, bvb de myProperty-- moet voor myPropert++ uitgevoerd worden (threads joinen) maar hoeveel code leent zich effectief tot dit soort dingen?

Als ik dagelijks code lees waarbij de aflijning tussen objecten veel te los is dan merk ik duidelijk dat MT door de compiler waarschijnlijk slechts een doekje voor het bloeden is. Inter-dependencies zoals bovenstaande maken het behoorlijk moeilijk (zelfs wanneer een mooie klassenstructuur rond die code verzint).

Dan ben ik nog niet eens begonnen over het debugging aspect. Je code wordt zoveel moeilijker te debuggen. De winst weegt in voor de meeste applicaties niet op tegen het verlies.

Ik denk dat er nog een en ander moet veranderen tegen dat MT ook bij de gemiddelde programmeur als serieus hulpmiddel aanzien wordt. OO heeft ook nieuwe tools, libraries en andere voortgebracht zelfs al had OO een directe positieve invloed op stijl, foutkans e.a. MT doet dit niet dus heeft het meer nodig om mainstream te worden.

[Verwijderd]

H!GHGuY schreef op donderdag 09 november 2006 @ 21:10:
[...]
Dit is helemaal iets anders. De meeste programma's hebben er wel baat bij dat een processor van 33 naar 100Mhz gaat.

Dat was niet helemaal het punt denk ik. Het ging erom dat er ooit mensen waren die dachten dat 33Mhz 'voor altijd' genoeg zou zijn, omdat die programma's op de 33Mhz CPU's voor hun snel genoeg waren.

Maar of de meeste taken geparallelliseerd kunnen worden betwijfel ik.

Goed, stel even dat jij helemaal gelijk hebt. Waarom komen intel, amd, ibm en alle anderen dan zo massaal met multi-core CPU's voor de desktop?

Ik vraag me ook af wat we van compilers mogen verwachten.

Wat veel mensen vergeten is dat de huidige compilers en CPU's al heel veel parallellisme uit de sequentiële instuction stream halen, het zogenaamde ILP (Instruction Level Parallelism). Als je naar een architectuur als Itanium kijkt dan doet de compiler het overgrote deel van dit werk, en bij de x86's doet de CPU dit wat meer.

Maar daar zitten grenzen aan. Op een gegeven moment moet de programmeur dingen echt zelf gaan indelen.

[LauPro]

Verwijderd schreef op donderdag 09 november 2006 @ 21:31:
Goed, stel even dat jij helemaal gelijk hebt. Waarom komen intel, amd, ibm en alle anderen dan zo massaal met multi-core CPU's voor de desktop?

Dit is heel simpel: Een gemiddelde desktop heeft al snel zo'n 40 services op de achtergrond draaien. Als ik alleen al kijk wat ik op mijn Linux workstation allemaal heb draaien dan zijn dat nu 193 processen. Heb nu welliswaar zo'n AMD X2 en loopt allemaal lekker. Maar het zou prettig zijn als ik bijvoorbeeld core 0..20 kan reserveren voor achtergrond services en de overige 60 voor desktopapplicaties. Ik heb bijvoorbeeld een FTP-daemon draaien. Het heeft voor mij totaal geen nut dat deze volledig van mijn processer kan benutten, sterker nog hij staat al geniced op -19.

Onder Windows zijn er meestal wat minder processen, maar ook daar blijft dat bijv. de Messenger Service best wel wat minder prio mag krijgen wmb. En als je even Services open trekt dan zie je ook meteen de potentie wat er allemaal parallel kan gaan starten met zo'n 80-core processor.

Voor een groot deel worden imo desktopapplicaties sterk vertraagd voor (systeem)services. Natuurlijk moet je je afvragen of het wenselijk is dat op een kantoorpc lokaal bestanden of printers worden gedeeld, dit zou immers beter via een server kunnen. Maar het is toch vaak de praktijk en zeker nu met gigabit kan je een PC toch tamelijk irritant vertragen als je er bestanden af gaat trekken. De meeste kantoorapplicaties die ik ken die zijn overigens gewoon domme databeesten. Waarbij hooguit bij het genereren van een report (wat vaak al 90% server side based is) extra power nodig zou kunnen hebben.

Als het gaat om speciale planningssoftware en/of andere wiskundige modellen omgezet naar een implementatie dan kan het inderdaad interessant zijn om dit MT te maken, neemt niet weg dat dit misschien 2% van alle applicaties betreft.

Dus misschien handig dat je wat concrete voorbeelden noemt van software waar dit aangepast moet worden. Wat ik al zei is dat naar mijn idee OOo en Mozilla (en Firefox) wel e.e.a. extra aan threading kunnen krijgen. Maar ik zal waarschijnlijk de laatste zijn die in die codebase gaat vroeten.

Om misschien maar even een mooi voorbeeld te geven. Op een blog las ik pas ergens dat een lead developer van GRASS het lumineuze idee had dat hun applicatie eigenlijk maar eens een QT-GUI zou moeten krijgen met verschillende onderdelen MT. Nou ik kwam niet meer bij ...

MBV schreef op donderdag 09 november 2006 @ 19:50:
't is opensource, dus ga je gang . Bedoel ik nog vrij serieus ook: als je een goed nieuw component hebt voor QT, dan zou je ze daar waarschijnlijk erg blij mee maken. Voordeel voor jouw: geen onderhoud meer daaraan, als het fout gaat gaat het in het framework fout
Maar wat bedoel je precies met job-scheduler? Een paar jobs fire&forget afschieten kan toch prima met signal/slot?

Daar heb je gelijk in, neemt echter niet weg dat het dus geen taak van de applicatieontwikkelaar is maar van de platformontwikkelaar. Wat ik job-scheduler bedoel is dat je een centraal object hebt waar je jobs in kan stoppen die dan elk direct toegang hebben tot een centraal object (de applicatie). En vervolgens dat je de status ook op een uniforme mannier weer terug kan koppelen.

[ Voor 14% gewijzigd door LauPro op 09-11-2006 23:04 . Reden: reactie MBV toegevoegd ]

[MBV]

offtopic:
@Laupro: zo'n job-scheduler is toch simpelweg een signal naar een class JobScheduler sturen, die op basis daarvan een thread spawnt voor de afhandeling? Doe je dan ook aan priorisering? Vervolgens moet een signal terug gegeven worden dat het klaar is. Het lijkt mij erg makkelijk te maken (ik onderschat dat soort dingen altijd), en als dat zo is dan wil je dat niet in een framework.
IEdereen wil namelijk zijn eigen priorisering doorvoeren, voor verschillende dingen heb je verschillende terugkoppelingen nodig enzo. Schedulen is een ongelofelijk moeilijk probleem, had niet voor niets een 4 voor Real-Time Architecture (== niet geleerd ) De ene keer moet job A op job B wachten, de andere keer juist niet, probeer daar maar eens een écht generieke oplossing voor te verzinnen.

[Verwijderd]

LauPro schreef op donderdag 09 november 2006 @ 22:57:
[...]
Dit is heel simpel: Een gemiddelde desktop heeft al snel zo'n 40 services op de achtergrond draaien. Als ik alleen al kijk wat ik op mijn Linux workstation allemaal heb draaien dan zijn dat nu 193 processen. Heb nu welliswaar zo'n AMD X2 en loopt allemaal lekker.

Op mijn Linux workstation heb ik ook een AMD X2, maar no way dat al die achtergrond processen ook maar 1 van de cores naar de 100% trekt. Als ik met top kijk zit alles eigenlijk telkens op de 0%, met af en toe iets wat op de 1% komt. Het is inderdaad mooi dat al die achtergrond dingen op een extra core kunnen draaien en het is vandaag de dag inderdaad iets wat een dual core z'n meerwaarde geeft (het systeem als geheel reageert duidelijk soepelder).

Ik denk echt echter serieus dat de multiple-core designs hier niet voor bedoeld zijn, daarvoor is de belasting die ze op het systeem leggen echt te laag.

Dit is trouwens een leuke thread die ik net pas zag hier op got. Men is daar een stuk enthousiaster over meerdere cores: Mijn voorlopige bevindingen over multicore-processing

[LauPro]

MBV schreef op donderdag 09 november 2006 @ 23:36:

offtopic:
@Laupro: zo'n job-scheduler is toch simpelweg een signal naar een class JobScheduler sturen, die op basis daarvan een thread spawnt voor de afhandeling? Doe je dan ook aan priorisering? Vervolgens moet een signal terug gegeven worden dat het klaar is. Het lijkt mij erg makkelijk te maken (ik onderschat dat soort dingen altijd), en als dat zo is dan wil je dat niet in een framework.
IEdereen wil namelijk zijn eigen priorisering doorvoeren, voor verschillende dingen heb je verschillende terugkoppelingen nodig enzo. Schedulen is een ongelofelijk moeilijk probleem, had niet voor niets een 4 voor Real-Time Architecture (== niet geleerd ) De ene keer moet job A op job B wachten, de andere keer juist niet, probeer daar maar eens een écht generieke oplossing voor te verzinnen.

offtopic:
Signals stuur je niet, die connect en emit je. Waar het mij om gaat is eigenlijk wat jij beschrijft. Natuurlijk is er voor elk programma misschien een andere implementatie mogelijk. Maar netzoals bij AJAX is het naar mijn idee onzinnig om elke keer het wiel opnieuw uit te vinden. Het zou makkelijker zijn dat er 1 (abstracte) QJobScheduler is welke je kan gebruiken, heb je meer nodig dat extend je die implementatie. Ik zal eens kijken of ik een voorbeeldje kan maken van een dergelijke QJob en QJobScheduler. En terugkoppeling is dan juist ook iets wat naar mijn idee veel gestandaardiseerder kan. Je zou een QJobState terug kunnen geven aan de QJobScheduler, welke ervoor zorgt dat de state bij de juiste parent terecht komt (op een slot). In die state kan je dan properties zetten.

Verwijderd schreef op donderdag 09 november 2006 @ 23:39:
[...]
Op mijn Linux workstation heb ik ook een AMD X2, maar no way dat al die achtergrond processen ook maar 1 van de cores naar de 100% trekt. Als ik met top kijk zit alles eigenlijk telkens op de 0%, met af en toe iets wat op de 1% komt. Het is inderdaad mooi dat al die achtergrond dingen op een extra core kunnen draaien en het is vandaag de dag inderdaad iets wat een dual core z'n meerwaarde geeft (het systeem als geheel reageert duidelijk soepelder).

Kan maar zo zijn dat je een JS-engine tegen komt die denkt 100% load te kunnen trekken. Ik heb regelmatig dat ik merk dat het systeem wat slomer is en dan blijkt al 10 minuten een dergelijk proces aan het stampen te zijn. Heb nu sinds kort de Runaway Process Catcher maarmee dit iets beter te detecteren is. Maar dit is niet echt iets voor de doorsnee gebruiker en soms hinderlijk.

Ik denk echt echter serieus dat de multiple-core designs hier niet voor bedoeld zijn, daarvoor is de belasting die ze op het systeem leggen echt te laag.

Persoonlijk zie ik het deels als een marketing truc, natuurlijk zijn er voordelen (aantal heb ik inmiddels genoemd). Systemen kunnen sneller opstarten. Maar ik denk niet dat het Intel's plan tot doel had om alle programma's tot in den treuren te laten MT'en. We zijn het namelijk ook al overeens dat MT ook overhead heeft. In de meeste gevallen minimaal 20%. Dus de implementatie met threads moet in ieder geval die 20% eruit weten te halen. Ik denk dat dit heel lastig gaat worden als het op botte berekeningen neer komt, je moet dan echt al bezig zijn met complexe algoritmes.

Ik zie het al gebeuren dat er over een paar jaar een tool komt waarmee je programma's kan 'single threaden' omdat ze teveel thread spawnen (bijv. elke menubutton die een image moet laden een eigen thread). Zie ook bijvoorbeeld Perl6 waar vanuit de taal al standaard ge-MT'ed gaat worden on the fly (het is nog niet geïmplementeerd maar de architectuur is er). Ze kijkt naar bepaalde keywords (pure o.a.) waarop bepaald wordt dat functies kunnen worden gethread of dat deze in de main-thread moeten blijven.

Dit is trouwens een leuke thread die ik net pas zag hier op got. Men is daar een stuk enthousiaster over meerdere cores: Mijn voorlopige bevindingen over multicore-processing

Er zijn zeer veel voordelen, maar deze liggen volgens mij meer bij de gebruikerskant qua performance (snel veel services starten) dan dat programmeurs nu applicaties moeten ontwerpen die met 40 cores (threads) tegelijk kunnen werken. Stel dat applicaties straks gemiddeld 20 threads starten, als je dan 20 applicaties open hebt staan heb je 400 threads, dan zijn die 80 cores weer veel te weinig want je bent de helft van je CPU-tijd kwijt aan syncen.

Daarnaast is het mij ook niet geheel duidelijk of die 80 cores bij wijze van spreke qua capaciteit hetzelfde zijn als (nu) 80 maal een AMD 64 3800+ of dat het 1 hele vette AMD 64 20000+ is die gedeeld wordt over 80 cores. (idee komt van Intel weet ik, gaat even om het concept).

[Verwijderd]

LauPro schreef op vrijdag 10 november 2006 @ 00:18:
met 40 cores (threads) tegelijk kunnen werken. Stel dat applicaties straks gemiddeld 20 threads starten, als je dan 20 applicaties open hebt staan heb je 400 threads, dan zijn die 80 cores weer veel te weinig want je bent de helft van je CPU-tijd kwijt aan syncen.

Scherp

Het is inderdaad een probleem waar wij nu ook tegen aan kijken. Wij hebben zowel meerdere requests als enkele requests die meer dan 1 core zouden kunnen gebruiken. Op het moment dat het relatief rustig is op het systeem, dan loont het zeer de moeite om die ene zware request over meerdere cores te verdelen. Is het echter druk, dan werkt het elkaar inderdaad tegen. Alle andere cores zijn dan al tamelijk bezet, en meer threads spawnen levert in die situatie niet een hogere total system utilisation, maar je betaalt wel de extra threading overhead.

M.a.w., in die situatie daalt mogelijk je totale throughput!

Dit is een vrij specifiek probleem voor serverside processing. Het probleem is al wel wat langer bekend. Typische systemen die hier rekening mee houden zijn Oracle en SQL server die zelfstandig of met de hulp van de user queries parallel kunnen uitvoeren. Als de load al redelijk verdeeld is over de cores dan wordt een query niet of minder parallel uitgevoerd.

In onze proto-type code kijken we dan ook naar het huidige aantal uitstaande requests. Dit is geen exacte benadering voor de totale verdeling van load over de cores, maar het hangt wel samen. Als dit boven een grens waarde komt dan geeft onze thread pool manager geen toestemming voor een nieuwe thread en mag de opvragende thread de branch in de dataset zelf gaan uitvoeren (d.w.z. op z'n stack zetten, en als uiteindelijk dat element van de stack verwijderd word, wordt er nog eenmaal een request voor een nieuwe thread gedaan als de stack nog niet leeg is, als dat weer false opleverd gaat ie hem zelf uitvoeren).

[LauPro]

Verwijderd schreef op vrijdag 10 november 2006 @ 01:16:
Dit is een vrij specifiek probleem voor serverside processing. Het probleem is al wel wat langer bekend. Typische systemen die hier rekening mee houden zijn Oracle en SQL server die zelfstandig of met de hulp van de user queries parallel kunnen uitvoeren. Als de load al redelijk verdeeld is over de cores dan wordt een query niet of minder parallel uitgevoerd.

In onze proto-type code kijken we dan ook naar het huidige aantal uitstaande requests. Dit is geen exacte benadering voor de totale verdeling van load over de cores, maar het hangt wel samen. Als dit boven een grens waarde komt dan geeft onze thread pool manager geen toestemming voor een nieuwe thread en mag de opvragende thread de branch in de dataset zelf gaan uitvoeren (d.w.z. op z'n stack zetten, en als uiteindelijk dat element van de stack verwijderd word, wordt er nog eenmaal een request voor een nieuwe thread gedaan als de stack nog niet leeg is, als dat weer false opleverd gaat ie hem zelf uitvoeren).

Ik denk niet alleen serverside. Kijk; zoals ik al aan gaf is het mijns inziens juist de taak van het platform/toolkit om hetgene dat je hier beschrijft te regelen. Je kan dan bijvoorbeeld via een aantal krachtige system-wide parameters QT medelen dat een applicatie bijv. terughoudend moet zijn met het maken van nieuwe threads. Of als er 1024-cores zijn, dat hij zeker wel wat threads mag laten spawnen. Eventueel kan de kernel op hoger niveau zelfs gaan bepalen of het verstandig is om nog threads toe te staan zodat alleen high priority jobs nog een eigen thread krijgen en dat andere jobs (bijv. die van het laden van de plaatjes voor een menubalk) worden samengevoegd in 1 thread.

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.

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 is goed om er over na te denken, maar zoals jij het topic bracht lijkt het bijna op een evangelie. En zoals bij alle evangelies, die zijn eng . En daarnaast blijf ik bij mijn standpunt dat het specifiek optimaliseren van programma's op threads slechts voor enkele wetenschappelijke of wiskundige-programam's geldt. Voor de doorsnee applicatie is het veel beter om dit een niveau hoger in het gebruikte platform te regelen.

[ Voor 12% gewijzigd door LauPro op 10-11-2006 02:23 . Reden: stukje history Apache toegevoegd ]

[H!GHGuY]

Verwijderd schreef op donderdag 09 november 2006 @ 21:31:
Goed, stel even dat jij helemaal gelijk hebt. Waarom komen intel, amd, ibm en alle anderen dan zo massaal met multi-core CPU's voor de desktop?

Net omdat het een responsiever systeem geeft. Net omdat het goedkoper is dan de CPU nog 2 maal zo hard te laten lopen. Het zijn tenslotte bedrijven die winst moeten maken. De kloksnelheden zijn nu al enkel jaren behoorlijk stabiel (2-3GHz). Dat is een duidelijk teken dat er andere technologieen gezocht moesten worden.

Wat veel mensen vergeten is dat de huidige compilers en CPU's al heel veel parallellisme uit de sequentiële instuction stream halen, het zogenaamde ILP (Instruction Level Parallelism). Als je naar een architectuur als Itanium kijkt dan doet de compiler het overgrote deel van dit werk, en bij de x86's doet de CPU dit wat meer.

Maar daar zitten grenzen aan. Op een gegeven moment moet de programmeur dingen echt zelf gaan indelen.

Je geeft net je eigen tegenargument. Als een CPU het op micro-niveau al zo moeilijk heeft. Hoe moeilijk is het dan niet om op macro-niveau parallellisme te introduceren? Op micro-niveau deed de gemiddelde processor dacht ik zo'n 1.2 operaties per clock-cycle. Hoe ga je dan de kost voor thread-switching, creatie, synchronisatie, dispatching en beeindiging gaan terugwinnen op macro-niveau.

Je kan gerust veel code parallelliseren:
bvb volgende c++ psuedo-code

C++:

unsigned int eenFunctie(std::vector& getalletjes)
{
   unsigned int som = 0;
   for(int i = 0; i < getalletjes.size(); i++)
      som += getalletjes[i];
   return som;
}

// WORDT

unsigned int eenFunctie(std::vector& getalletjes)
{
   unsigned int som1 = 0, som2 = 0;
   current_thread thread = start_mt(2);
   if (thread == 0)
      for (int i = 0; i < getalletjes.size() /2; i++)
         som1 += getalletjes[i];
   else
      for (int i = getalletjes.size()/2; i < getalletjes.size(); i++)
         som2 += getalletjes[i];
   thread_join(thread);
   return som1 + som2;
}

Probeer eens alle randvoorwaarden op te schrijven. Ik kan je er al 1 van geven:
als je elke getal bij het volgende moet optellen (getalletjes[i] += getalletjes[i-1]) was het al om zeep.

De randvoorwaarden die nodig zijn om de compiler of jezelf de mogelijkheid te geven om code te parallelliseren zijn behoorlijk strikt en veelvuldig aanwezig.
De compiler zou bovendien moeten uitrekenen vanaf welk grootte van de vector het spawnen/dispatchen van een thread ook effectief nut heeft.

1 ding lijkt mij duidelijk. Een compiler zal niet zomaar even perfecte MT code poepen die voor elke code van Henk Programmeur beter en sneller draait. Denk maar even aan een evenwichtige binaire boom implementatie. Als je een in-order walk zou moeten doen kun je dit perfect MT maken. Of je compiler dit zomaar even voor jou zal kunnen opsniffen is nog maar de vraag. Die moet namelijk jou data-structuur gaan analyzeren, zien dat het parallelliseerbaar is, geen O(n) threads dispatchen/spawnen door een idiote fout, beslissen wanneer dan wel extra threads mogen gebruikt worden etc etc.

Het lijkt me dus enorm onwaarschijnlijk dat dergelijke compiler optimalisaties extreme performance winsten gaan boeken en dat de programmeur kan doen alsof zijn neus bloedt. Jazeker compilers zullen nog slimmer worden. Zullen hier en daar een werkje kunnen aftakken. Maar adhv statische analyse op code is dit heel moeilijk. Verplaats je de beslissing dan weer naar runtime dan krijg je in het slechtste geval net weer minder performance.

Ik blijf er dus bij dat sommige taken niet hoeven ge-thread te worden en dat de kost (= minder winst) zeker op dit moment daarvoor meestal te hoog ligt. Laat game-developers en mensen die wel winst kunnen boeken uit MT hun ding doen en verder typ ik mijn e-mails nog wel verder in op 1 CPU. Ik kijk op dit moment de kat uit de boom en gebruik het ding enkel als ik vind dat het mij winst geeft, nodig is voor de GUI, of als het mij goed uitkomt.

[flowerp]

H!GHGuY schreef op vrijdag 10 november 2006 @ 18:27:
[...]
Net omdat het een responsiever systeem geeft.

Daar zijn de huidige duals voor, maar tenzij jij iets weet wat ik niet wat dan denk ik niet dat de responsiveness nog veel meer toeneemt als je voorbij een quad gaat, tenzij de cores dus echt expliciet gebruikt gaan worden.

Je geeft net je eigen tegenargument. Als een CPU het op micro-niveau al zo moeilijk heeft. Hoe moeilijk is het dan niet om op macro-niveau parallellisme te introduceren?

Voor een compiler: extreem moeilijk / onmogelijk
Voor een mens: veel minder moeilijk, zeker voor creatieve geesten

Omdat een mens de context van een probleem snapt, kan deze een gegeven probleem juist op een radicaal andere manier aanpakken, in plaats van alleen de huidige aanpak meer efficient te laten lopen.

Een heel mooi voorbeeld is sorten in een logische programmeertaal. Je declareerd dan het probleem, maar geeft geen concrete stappen om het op te lossen.

Bv, voor sorten zeg je ongeveer iets als:

Ik wil deze lijst van getallen zo hebben dat voor elk paar X en Y uit de lijst geld: als de positie van X lager is als de positie van Y dan is de waarde van X ook lager als Y.

De logische interpreter zal hier daadwerkelijk een gesorteerde lijst opleveren, maar de interpreter probeerd alleen aan voorwaarden te voldoen. Het -inzicht- in wat ie nou eigenlijk aan het doen is mist ie. Een mens kan daarentegen met een veel slimmere oplossing komen, zoals bijvoorbeeld het quicksort algoritme.

Zo is het ook met parallelisme. Een compiler en/of runtime kunnen wel het inherente parellelisme uit de door de mens bedachte oplossing proberen te filteren (en ze zijn hier ook tegenwoordig meestal beter in dan een mens), maar ze gaan niet een hele andere oplossing bedenken die het zelfde of gelijkwaardig resultaat heeft.

Als we even het voorbeeld van dat genetische algoritme van hierboven nemen. Stel dat er alleen het standaard sequentiele algoritme was geweest. Als je dit opzich zou gaan paralleliseren, dan kun je mischien tot de ontdekking komen dat de evaluatie functie van individuals (kandidaat oplossingen) onafhankelijk is. Bij een grote populatie en/of een zware evaluatie kun je dan de ene helft door de ene core laten evalueren en de andere helft door de andere.

Een compiler zou dit mischien nog net kunnen, mits de populatie zich in een parallel-itereerbare datastructuur bevind (in dit geval bij voorkeur een native array). Zeer waarschijnlijk moet de mens de compiler al in deze oplossings richting duwen door een array ipv een list te kiezen, maar goed, theoretisch zou een automatisch systeem deze paralleliteit kunnen vinden.

Neem nou echter de aanpak die henk koos: het zelfde algortime tig keer parallel opstarten met (naar ik aanneem) verschillende random begin parameters, en dan periodiek individuals uitwisselen.

Ik zeg liever nooit nooit, maar ik denk dat een automatisch systeem zoals we die nu kennen deze aanpak NOOIT zelf zou bedenken! Het vereist namelijk inzicht in wat er nu eigenlijk bereikt moet worden en hoe genetische algoritmen functioneren. Zomaar een willekeurig stukje code gaan opstarten met random parameters MAG een automatisch systeem natuurlijk niet eens doen, laat staan dat het er ook maar enig benul van zou kunnen hebben dat het in dit geval nuttig is.

[Confusion]

flowerp schreef op vrijdag 10 november 2006 @ 23:46:
Voor een compiler: extreem moeilijk / onmogelijk
Voor een mens: veel minder moeilijk, zeker voor creatieve geesten

Omdat een mens de context van een probleem snapt [..]

Multithreaded coden zou wat dat betreft weleens verdacht veel op Go kunnen lijken: context.

[MBV]

Ik denk dat je, in andere talen, veel meer optimalisaties voor multi-cores kan doorvoeren dan met de gebruikelijke imperatieve talen. Als je een functioneel programma hebt, kan de compiler veel makkelijker rekening houden met multi-threading. Als je een logisch programma hebt kan dat misschien wel nog makkelijker. Simpelweg omdat je niks zegt over de manier waarop het opgelost moet worden, maar de oplossing beschrijft die je wilt hebben.
Bij een functioneel programma heeft dat een belangrijke oorzaak: je kan veel beter analyseren wat de inputs en outputs zijn van een functie, en in welke gevallen die veranderen. Bij een while-loop is dat als compiler bijna niet te zien, hooguit of iets gedurende een loop zou kunnen veranderen. Als een functie zichzelf 2x aanroept, zal je dat vrij eenvoudig in 2 threads kunnen stoppen. Dat soort gein.

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.

[flowerp]

MBV schreef op zaterdag 11 november 2006 @ 14:29:
Bij een functioneel programma heeft dat een belangrijke oorzaak: je kan veel beter analyseren wat de inputs en outputs zijn van een functie, en in welke gevallen die veranderen.

Sterker nog, in een functionele taal kun je garanderen dat een functie geen side effects heeft. Een enkele functie is dan per definitie door een aparte thread uit te voeren.

Dit is ook wel een beetje waar ik op doelde met een andere aanpak eerder. Als je nu naar bestaande (imperatieve) code kijkt, en die wilt gaat opdelen in threads dan denk je dikwijls dat het niet kan, niet zinvol is, en te moeilijk.

Maar dan speel je soms voor de C programmeur die opeens zelf objecten inclusief eigen vtables en inheritance etc wil gaan maken (en je zou je het bijna niet geloven, maar er zijn mensen die dat echt doen). Een andere aanpak zou inderdaad, zoals jij zei, een andere paradigma kwa programmeertaal kunnen zijn. Dingen die nu moeilijk zijn kunnen dan opeens veel minder een probleem zijn.

Als extreem voorbeeld (en dit is niet directbaar toepasbaar op cores zoals we die nu kennen, maar even voor het idee), het programmeer model van onze eigen hersenen is massive parallel. Een probleem als "herken de stoel in het plaatje", wordt op een radikaal andere manier 'berekend' dan je dat iteratief zou doen. In deze 'programmeertaal' kun je makkelijk miljoenen en miljoenen rekeneenheden tegelijk benutten.

Het zou dus zeer goed kunnen dat er willicht in de nabije toekomst nog eens een ander paradigma komt, waarbij de cores zoals die gaan komen makkelijker benut kunnen worden, en waarbij er makkelijker over het geheel geredeneerd kan worden.

en al deze wijsheid om 1:50 in niet al te heldere toestand meer

[MBV]

flowerp schreef op zondag 12 november 2006 @ 01:47:
[...]

Maar dan speel je soms voor de C programmeur die opeens zelf objecten inclusief eigen vtables en inheritance etc wil gaan maken (en je zou je het bijna niet geloven, maar er zijn mensen die dat echt doen). Een andere aanpak zou inderdaad, zoals jij zei, een andere paradigma kwa programmeertaal kunnen zijn. Dingen die nu moeilijk zijn kunnen dan opeens veel minder een probleem zijn.

Ja ik weet het. Ik heb wel gehoord van een project wat in C geschreven is, maar met een OO ontwerp. Ik wil die code echt niet zien

Oftewel: allemaal functioneel programmeren, dan komen we er wel

[H!GHGuY]

MBV schreef op zondag 12 november 2006 @ 13:20:
[...]

Ja ik weet het. Ik heb wel gehoord van een project wat in C geschreven is, maar met een OO ontwerp. Ik wil die code echt niet zien

Oftewel: allemaal functioneel programmeren, dan komen we er wel

C++:

class X
{
  public:
   X(int a, int b) : m_iA(a), m_iB(b);
   int Som() { return m_iA + m_iB; }
   int Factor() { return m_iA * m_iB; }
  private:
   int m_iA, m_iB;
}

C:

typedef struct
{
   int m_iA, m_iB;
} X;

int Som(X* in) { return in->m_iA + in->m_iB; }
int Factor(X* in) { return in->m_iA * in->m_iB; }

niet zo vreemd toch ??

C:

typedef struct
{
   X x;
   int m_iC;
} Y;

X* CastToX(Y* y) { return &(y->x); }

voor simple inheritance.

Je gaat gewoon de compiler emuleren dus

[flowerp]

H!GHGuY schreef op zondag 12 november 2006 @ 13:41:
[...]

C:

typedef struct
{
   int m_iA, m_iB;
} X;

int Som(X* in) { return in->m_iA + in->m_iB; }
int Factor(X* in) { return in->m_iA * in->m_iB; }

niet zo vreemd toch ??

Hahaha

Als je een voorbeeld geeft moet je het toch wat beter doen hoor De echte "objects-in-C" freak defineerd natuurlijk ook methods -in- de struct zelf. Hint, denk aan functie pointers. Helaas zie ik nog niet waar je vtable staat, hoe je abstracte base classes en interfaces maakt, hoe je polymorphsime denkt te bereiken, hoe je access controll (protected, private, package, etc) denk te gaan implementeren. Etc etc...

Trust me... it ain't pretty this way...

Je gaat gewoon de compiler emuleren dus

Precies. Das de hele clou van het verhaal

Tuurlijk, het -kan-. Maar je gaat zelf werk doen en onderhouden wat al door een complete industrie is gedaan. Als je het heel goed hebt gedaan, programmeer je met je eigen systeem feitelijk in Objective C of C++, maar je kunt voor jezelf lekker blijven denken dat het C is. Beetje naief standpunt als je het mij vraagt, maar goed mischien is er wel een hele goede reden voor die ik niet zomaar kan bedenken.

[MBV]

Zoals een embedded systeem waar geen C++ compiler voor is? Zomaar een vage int.

Oke, zullen we het weer over multi-threaded/multi-proc hebben?

[flowerp]

[offtopic]

MBV schreef op zondag 12 november 2006 @ 14:59:
Zoals een embedded systeem waar geen C++ compiler voor is? Zomaar een vage int.

De comeau c++ to c compiler is your friend.

Oke, zullen we het weer over multi-threaded/multi-proc hebben?

idd, hoewel er niet bijster veel mensen op de poll gestemd hebben (ik denk dat zo'n poll in /14 meer response had gehad), valt toch wel op dat de stemmers wat positiever zijn over meerdere cores dan de posters. 65% geeft via de poll aan in meer of mindere mate cores te willen gebruiken. 35% geeft om uiteenlopende redenen aan dat multi core onzin is om voor te programmeren.

Jammer btw dat er in de poll geen "ja, andere reden" en "nee, andere reden" antwoorden staan.

Ook opvallend is dat niemand meer geloofd dat intel binnenkort weer gewoon de clock omhoog gaat gooien. In een topic hier van een jaar geleden dacht bijna iedereen nog dat dual core een tijdelijke noodoplossing was en dat de 4Ghz op het punt stond om uitgebracht te worden.

[roy-t]

Ik denk dat er bij multi-core programmeren altijd eerst moet gerekend worden of er wel winst is te halen uit multi-cores 100% van de (test)programmatjes die ik schrijf niet,

Maar ik denk dat vooral voor dingen die juist NIET real-time berekend hoeven worden multi-core een redelijk makkelijke uitkomst is, maar de synchronisatie in spelletjes met meedere cores voor AI en Graphics en Fysics is hoewel erg moeilijk wel degelijk goed mogelijk (AEGA het wel kan!, net als Nvidia icm AMD icm Soundblaster for example, en dit zijn 4 compleet verschillende apparaten die wel met elkaar gesyncd kunnen worden, dit doen de compilers vaak voor ons, dus ik denk dat er snel een compiler komt die 4 Exact dezelfde apparaten met elkaar kan syncen)

Eigenlijk lijkt me programmeren met 3 Cores Makkelijker dan met 2 of 4!!

Core1

code:

Dim ILinkerhelft
ILinkerhelft = calc(model, nurb 1 to 500)
While Door <> True
Wait
end while
'calc maar weer iets nieuws

Core 2

code:

Dim IRechterhelft
IRechterhelft = calc(model, nurb 501 to 1000
While Door <> True
Wait
end while
'calc maar weer iets nieuws

Core 3

code:

Dim Door as boolean
While (cores zijn niet klaar)
WAIT
EndWhile
Merge(IRechterhelft, ILinkerhelft)
Door = true

Edit @ Flowerp, hmmz ok, misschien is het niet het werk van de compiler om geluid en grapichs bv. met elkaar te syncen.

2. Oh met test programmatjes bedoel ik gewoon wat probeersels enzo, niet analyseren van data

[ Voor 8% gewijzigd door roy-t op 12-11-2006 16:35 ]

[flowerp]

therat10430 schreef op zondag 12 november 2006 @ 15:19:
Ik denk dat er bij multi-core programmeren altijd eerst moet gerekend worden of er wel winst is te halen uit multi-cores 100% van de (test)programmatjes die ik schrijf niet,

Juist een test applicatie is dikwijls goed parallel te maken, omdat testen vaak onafhankelijk zijn. In principe zou JUnit 100% parallelliseerbaar moeten zijn. In een IDE kan dat voor grote voordelen zorgen, omdat met genoeg cores je JUnit testen continue op de achtergrond zouden kunnen draaien. Breek je ergens iets dan krijg je binnen een korte tijd meteen feedback.

net als Nvidia icm AMD icm Soundblaster for example, en dit zijn 4 compleet verschillende apparaten die wel met elkaar gesyncd kunnen worden, dit doen de compilers vaak voor ons

Volgens mij is het niet de taak van een compiler om hardware devices met elkaar te syncen.

, dus ik denk dat er snel een compiler komt die 4 Exact dezelfde apparaten met elkaar kan syncen)

Dan nog moet jij die 4 'apparaten' van een logsiche eenheid werk voorzien in je code. Zoals al eerder besproken hier, de bulk van het high-level parallelisme is iets wat de programmeur/desgner moet bedenken.

Ik las vanmiddag nog een interesante post op de FP, met daarin deze quote:

Volgens AMD zal het 4x4-platform later probleemloos kunnen worden voorzien van quadcoreprocessors, waarvan de codenaam 'Agena' is. Deze processors worden halverwege 2007 verwacht

Dit betekent dat we over +- een half jaar al 8 cores in een consumenten machine hebben. Ik weet niet hoe snel iedereen hier z'n design kan omgooien, maar het lijkt me toch niet onverstandig om hier wellicht NU al mee te beginnen.

[MBV]

gelukkig werken de cores stuk voor stuk nog even snel als de huidige generatie, dus er is geen acuut probleem voor de 80% van de applicaties die toch geen processorkracht gebruikt.

Wat pas leuk wordt, is wanneer ze de generieke processor gaan afschaffen. Pak-em-beet een GPU als co-processor, het ontwerp van de Playstation 3 enzo.

[flowerp]

MBV schreef op zondag 12 november 2006 @ 16:17:
gelukkig werken de cores stuk voor stuk nog even snel als de huidige generatie, dus er is geen acuut probleem voor de 80% van de applicaties die toch geen processorkracht gebruikt.

Wat pas leuk wordt, is wanneer ze de generieke processor gaan afschaffen. Pak-em-beet een GPU als co-processor, het ontwerp van de Playstation 3 enzo.

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

[MBV]

het ontwerp van de PS3 is daarvoor te ingewikkeld. Daarbij heb je maar 1 generieke proc, die maar een beperkte verwerkingskracht heeft. De rest moet je aan de andere cores toewijzen, en alle argumenten die iedereen heeft genoemd tegen MT-compilers zijn dan ineens heel erg valide

[Verwijderd]

Je kan gerust veel code parallelliseren:
bvb volgende c++ psuedo-code

C++:

unsigned int eenFunctie(std::vector& getalletjes)
{
   unsigned int som = 0;
   for(int i = 0; i < getalletjes.size(); i++)
      som += getalletjes[i];
   return som;
}

// WORDT

unsigned int eenFunctie(std::vector& getalletjes)
{
   unsigned int som1 = 0, som2 = 0;
   current_thread thread = start_mt(2);
   if (thread == 0)
      for (int i = 0; i < getalletjes.size() /2; i++)
         som1 += getalletjes[i];
   else
      for (int i = getalletjes.size()/2; i < getalletjes.size(); i++)
         som2 += getalletjes[i];
   thread_join(thread);
   return som1 + som2;
}

Toevallig is dit precies een situatie die je met OpenMP makkelijk kunt paralleliseren, ongeveer zoals jouw pseudocode al aangeeft (zelfs nog wat mooier, gewoon een #pragma boven de betreffende for-loop).
Dat is ongeveer wat ik gedaan heb in mijn eigen code: Mijn voorlopige bevindingen over multicore-processing

OpenMP deelt een for-loop op in meerdere threads (wat eventueel dynamisch gedaan, dan varieert hij het aantal iteraties dat hij per thread doet).
Maar het is inderdaad erg beperkt, en het zal niet gaan als je iteraties afhankelijk van elkaar zijn op een niet-triviale manier. Dan zul je het om moeten schrijven, indien mogelijk.
En natuurlijk moet je rekening houden met thread-safety, dat kan de compiler niet voor je doen. Er zijn wel wat directives in OpenMP om atomaire operaties op data te doen met locking.

Maar verder zie ik compilers ook voorlopig nog niet echt goede code voor multithreading maken. OpenMP is een aardig hulpmiddeltje, dat je een middagje werkt scheelt om zelf dergelijke thread-spawn-routines te schrijven, maar veel meer ook niet. Ik denk dus zeker dat we voorlopig programmeurs zelf op moeten leiden om code te leren paralleliseren. Sowieso lijkt het me altijd goed om te zorgen dat programmeurs een beetje weten wat er onder de motorkap gebeurt, ook al hoeven ze hier niet dagelijks mee te werken. Het kan ze extra inzicht geven bij het debuggen en optimaliseren van code.

[Verwijderd]

MBV schreef op zondag 12 november 2006 @ 13:20:
[...]

Ja ik weet het. Ik heb wel gehoord van een project wat in C geschreven is, maar met een OO ontwerp. Ik wil die code echt niet zien

Wat dacht je van de Windows API?
Daar werk je veel met structs en handles etc.
In feite is dat OO-zonder-OO.
De struct of de handle staat voor de object-referentie. En die geef je mee aan iedere functie die er bewerkingen op doet.
Bij OO werkt het eigenlijk niet anders... De this-pointer wordt als eerste argument van de functie meegegeven. Het is alleen aan het oog van de programmeur onttrokken.
C++ is ook ontstaan uit C. Ervaren C-programmeurs als Bjarne Stroustrup gebruikten al veel langer het idee van classes en vtables etc. Ze schreven hiervoor een handige preprocessor (cfront, genereerde C-code), en dat is later uitgegroeid tot C++.
Niet zo vreemd dus. Ik heb het zelf ook wel gedaan, vroeger. Daarom snap ik niet zo dat mensen de overgang naar OOP zo lastig zouden vinden. Als je inziet hoe C++ vertaalt naar C, zou je juist moeten zien dat het eigenlijk hetzelfde is, en dat je je code leesbaarder kunt maken en tijd kunt besparen. Met functiepointers rommelen, en data groeperen in structs en meegeven aan allerlei functies behorende bij die struct, dat deed je toch al heel vaak, als het goed is.

[MBV]

Hoeveel mensen maakten daar toen gebruik van? Heel veel apps werden geschreven in 'gewoon' C, zonder dat soort grappen, door mensen die zichzelf hadden geleerd een beetje te programmeren. Je weet wel, mensen die tegenwoordig PHP gebruiken.

En de windows-api ben ik altijd met een grote boog omheen gelopen. Onleesbare codesoep geeft dat. Wel eens wat met DirectX gedaan? Weet je hoeveel code je nodig hebt om een paars vierkantje op een groene achtergrond te zetten? Als je toch al OO werkt, maak het dan echt OO, dat scheelt 500 regels 'start-code', plus 50% van de rest
dat soort cijfers kwam naar voren bij een projectje wat in Gnome en KDE was gedaan, Klotski geloof ik. was oorspronkelijk paar duizend regels GTK code, en in QT minder dan de helft daarvan

[Verwijderd]

Heh, DirectX is m'n specialiteit
Nooit problemen mee gehad, maar idd, het is nogal lowlevel, je kunt van alles instellen.
Als je alleen een paars vierkantje op een groene achtergrond wilt, is DirectX ook overkill.
Dat is dus een kwestie van overengineering, en niet de juiste gereedschappen kiezen voor het probleem dat je wilt oplossen.

Ik schrijf 3d visualisatie-spul, en ik gebruik zo ongeveer alles wat DirectX mij te bieden heeft, ik zou niet zonder kunnen.

[MBV]

Oh jawel. Nooit van OpenGL gehoord? Dan hoef je niet 3 pagina's 'standaard'-code te schrijven voor je begint. Uiteraard zullen er frameworks zijn die dat voor DirectX grotendeels verhelpen, maar doe mij maar een goed ontworpen framework.

[.oisyn]

Sorry hoor maar dat is echt zo'n standaard blaat argument tussen OpenGL en D3D. Ja OpenGL heeft een immediate mode, maar daar maak je geen 3d apps mee omdat dat niet zo heel erg rap werkt. En als je per se een immediate mode voor D3D wilt is een vertex push object zo geschreven, en dat doe je maar 1 keer.

Beide APIs zijn niet bedoeld om 'even een vierkant te tekenen', elke serieuze app heeft een hele lap aan intialisatie code, of die nou d3d gebruikt of ogl.

[Verwijderd]

Eerst mekkeren dat DirectX geen mooie OOP is, en dan OpenGL aanraden, wat helemaal geen OOP is? Tsja, beetje krom.
En ja, ik ken OpenGL, en ik heb het ook (professioneel) gebruikt in het verleden, maar momenteel prefereer ik toch Direct3D.

Ik vind het argument ook wat onzinnig.
Die opstartcode is helemaal niet zo ingewikkeld meer in de nieuwere versies, en verder schrijf je het eenmalig (of je kopieert het uit de tutorials van de DirectX SDK, je hoeft het niet eens zelf te schrijven).
Het staat absoluut niet in verhouding tot de rest van de code in mijn project, dus ik kan niet echt wakker liggen van een paar regels opstart-code meer of minder.

Met OpenGL zou ik juist meer opstartcode nodig hebben, omdat ik van de laatste features gebruikmaak, wat betekent dat ik veel extensies moet importeren en initialiseren (soms ook vendor-specific), wat zeker minder leesbaar is dan mijn huidige Direct3D-code. Bij OpenGL kun je sowieso niet echt van een framework spelen. Het is een samenraapsel van imperatieve functies.

Kortom, schoenmaker, blijf bij je leest, en probeer een ervaren professional niet uit te leggen hoe hij z'n werk moet doen.

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.

[.oisyn]

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.

Ah jij hebt ook al zo'n Jump-to-conclusions mat zie ik?

[Verwijderd]

.oisyn schreef op maandag 13 november 2006 @ 12:47:
[...]

Ah jij hebt ook al zo'n Jump-to-conclusions mat zie ik?

Tsja, noem het ervaringsdeskundige... Het is altijd hetzelfde liedje, kotsmisselijk word ik ervan.
Je weet zelf vast ook wel op voorhand dat ik gelijk heb, je hebt aan je reactie te zien ook al vaker met dit bijltje gehakt

[.oisyn]

Wat ik bedoelde is dat het niet meteen anti-MS getroll is (ik bespeur niets anti-MS in z'n post namelijk), en dat het jou niet siert om het daar dan meteen op te gooien