VU en UvA leren ontwikkelaars programmeren voor multicores

De twee Amsterdamse universiteiten hebben een summerschool voor parallel programmeren opgezet. De summerschool, met 25 plaatsen, is bedoeld voor bijna afgestudeerde bachelorstudenten, maar anderen kunnen ook deelnemen.

De Universiteit van Amsterdam en de Vrije Universiteit houden van 4 tot 8 juli een summerschool over programmeren voor meer dan één processorcore. Volgens UvA-student Roy Bakker, die de summerschool mede organiseert, benutten nog te weinig programma's de aanwezigheid van verschillende cores.

Zo zou er nog weinig gebruik worden gemaakt van single assignment c, een programmeertaal die speciaal voor meer dan één core is bedoeld en die op een van de dagen van de summerschool wordt behandeld. Ook programmeren voor gpu's met tienduizenden tot honderdduizenden threads met Cuda of opencl wordt behandeld.

De universiteiten willen ook graag mensen uit het bedrijfsleven aantrekken, zegt Bakker. "Veel kennis over parallel programmeren blijft nu binnen de academische wereld hangen, maar wij denken dat ook het bedrijfsleven er baat bij kan hebben." Afgestudeerden betalen overigens wel fors meer dan studenten; terwijl een student voor 25 euro kan deelnemen, moet iemand die is afgestudeerd 700 euro aftikken. Volgens Bakker komt dat doordat de deelname van studenten grotendeels uit subsidie wordt betaald, terwijl dat voor afgestudeerden niet mogelijk is. Er zijn 25 plaatsen beschikbaar, waarbij onder andere wordt geselecteerd op motivatie.

Reacties (73)

[Exirion]

Tja, erg veel nieuws is dit niet. Half jaren '90 werd parallel programmeren op de VU al als theorievak met een uitgebreid practicum gegeven. Je kon je uiteindelijke implementatie na simulatie gaan testen op de DAS cluster om te kijken hoe het schaalde.

http://www.cs.vu.nl/das3/sites-vu.shtml

Overigens had men op de VU ook een eigen taal ontwikkeld (o.a. Henri Bal en Ceriel Jacobs): ORCA. Al met al was parallel programmeren toen al een serieus vak met een practicum waar je veel van kon leren.

[Squee]

Ik zou ook niet willen beweren dat "parallel programmeren" nieuw is; maar het is wel een hedendaags en actueel probleem. Over de jaren heen zijn er zo veel methoden voor parallel programmeren ontwikkeld, iets wat volgens mij in de jaren '80 al begonnen is.

En waar zijn we nu uiteindelijk op uitgekomen als je kijkt naar wat men "in het algemeen" gebruikt? Tsja, MPI, OpenMP en OpenCL voor embarrisingly parallel (vaak wetenschappelijke) rekenproblemen, maar daar ga je het echt niet mee redden om je general-purpose computing voor multicores to programmeren. Dan hebben we natuurlijk nog POSIX threads, maar iedereen die daar ooit wat redelijks mee geprogrammeerd heeft zal ook weten hoe ontzettend moeilijk het is om concurrency bugs te vinden en op te lossen. Het probleem wat je er ook bij hebt is dat pThreads natuurlijk pas later "er bij geplakt" is en de C taal oorspronkelijk niet echt geschikt is voor parallel programmeren.

De vraag is, hoe lossen we dit nu op? ORCA heeft het qua populariteit niet gehaald blijkbaar. Volgens mij was dat ook meer een taal voor distributed systems, was het niet bedoeld om programmas voor Amoeba te schrijven? pThreads zal het ook niet gaan redden, het is te moeilijk (of eigenlijk; te makkelijk om fouten te maken) en het coherent shared memory model wat het vereist zal waarschijnlijk niet schalen naar 1000en cores op een chip.

[Verwijderd]

Volgens mij was dat [Orca] ook meer een taal voor distributed systems, was het niet bedoeld om programmas voor Amoeba te schrijven?

Klopt.
Maar als je er een beetje over na denkt, dan is een multi-core systeem ook gewoon een vorm van een gedistribueerd systeem. Maar ik denk dat Orca meer was voor gedistribueerd systemen in het algemeen. En systemen met dure communicatie in het bijzonder (message passing over een external network interface, zoals als Ethernet. of zelfs WAN links). Het bijzondere van multicore systemen is juist dat de communicatie in principe veel goedkoper is. Dat soort zaken is erg belangrijk als je een nieuwe taal, implementatie of programmeer-model ontwerpt.

Parallel programming is erg lastig. Dat was het 10 of 20 jaar geleden. En dat is het nog steeds. En wat een goede oplossing voor een bepaald probleem is, is vaak geen goede oplossing voor andere problemen. En zelfs als je een algemene aanpak hebt, dan moet je er toch constant over blijven nadenken. Voorlopig zullen de meeste cores in multicore systemen ongebruikt blijven.

[rvannieuwpoort]

Klopt helemaal. Orca is meer voor de echte distributed systems. Tegenwoordig doen we dat op de VU met Java-gebaseerde oplossingen In het Ibis project: http://cs.vu.nl/ibis. Ibis werkt voort clusters, grids, clouds, en zelfs android telefoons.

Threads zijn natuurlijk ook al heel lang gemeengoed voor shared memory systemen.
Maar het programmeren van de zogenaamde many-cores, zoals GPUs is toch echt heel anders. Het voornaamste probleem is de schaal. Je hebt nu opeens honderden tot duizenden cores op een chip, en die cores hebben samen verschrikkelijk veel rekenkracht. Helaas lukt het nog niet om het geheugen mee te schalen. Per core heb je dus eigenlijk maar erg weinig memory bandwidth. En dat is dus de reden dat de memory architecturen van GPUs zo ingewikkeld zijn, en dat GPU programma's eigenlijk meer bezig zijn met het omgaan met het geheugen en het optimaliseren van het aantal en het patroon van de geheugen operaties.

Dit is ook de reden dat er voor GPUs weer nieuwe programmeertalen ontwikkeld zijn, zoals Cuda en OpenCL. De bestaande talen kunnen dit (nog) niet goed uitdrukken.

[disclaimer: ik geef de Cuda/OpenCL dag van deze summerschool]

edit: GPU programmeren is trouwens al een onderdeel van het master programma van de VU, en dit deel wordt ook steeds groter. Dit jaar zijn er in het vak parallel programming 5 colleges over het programmeren van GPUs en een practicum....

[Reactie gewijzigd door rvannieuwpoort op 22 juli 2024 15:20]

[RayNbow]

Zo zou er nog weinig gebruik worden gemaakt van single assignment c,

Het idee van single assignment bestaat bijv. ook in Erlang. Het is feite niets anders dan de variabelen in de wiskunde die niet gewijzigd kunnen worden. Als je beweert dat x=3, dan zal x voor altijd 3 zijn. Iets als x = x+1 is onzin in de wiskunde, maar ook in single assignment talen.

Het grote voordeel van single assignment is dat alles immutable is. Problemen als dat twee delen van je programma gelijktijdig een stuk geheugen willen wijzigen bestaan dus niet.

[Reactie gewijzigd door RayNbow op 22 juli 2024 15:20]

[Verwijderd]

En dit hele idee is weer na te bootsen in vrijwel alle andere talen. De meeste talen hebben hier ook enkele hulpmiddelen voor zoals in Java het keyword 'final' en in C/C++ het keyword 'const'. Natuurlijk ben ik groot voorstander van nieuwe talen die zich beter focussen op multi-core programmering. Een taal waarin variablen naar initialisering altijd fixed zijn kan w.m.b op de huidige generatie processoren echter nog niet in alle gevallen voldoende performance leveren t.o.v talen die wijzigingen van variable wel (gedeeltelijk) toelaten . En ik twijfel of dit in de toekomst gaat veranderen.

[Verwijderd]

offtopic:
Mag dat niet?
Want je ziet best wel vaak ipv 'x++' 'x+1' staan in code?

[Verwijderd]

Het punt is dat een vergelijking als x = x + 1 wiskundig nooit op te lossen is.

Wat jij beschrijft zijn mutable variabelen, dit is lastig bij multi core cpu's omdat je dan rekening moet houden met locking etc. Als alles immutable is hoef je daar niet bang voor te zijn omdat nergens state wordt bewaard en dus al je code zonder side effects werkt.

[terraego]

volgens mij zijn de primitieve datawrappers vrijwel altijd immutable. Als je bijvoorbeeld i++ zegt in java, word er bij elke verhoging een nieuw integer object gebruikt (of hergebruikt). Hetzelfde geld voor strings, floats, etc...

[jvo]

Voor een String geldt dat inderdaad in java. Voor een int of float niet. Met een hoofdletter en het is een pointer naar een object. Kleine letter en het is geen pointer. Een int is dus mutable en i++ hoogt gewoon de waarde op. De wrapper Integer maakt een object van een int. Daarmee wordt hij bijvoorbeeld Hashable en is pass by reference mogelijk.

[elmuerte]

(In Java)
Strings zijn geen primitives maar immutable objecten.
float, integer, ... zijn wel primitives.
i++ is een primitive operation, en als "int i;" dan zijn er geen objecten te pas gekomen. Maar als "Integer i" dan komt i++ overeen met: i = Integer.valueOf(i.intValue() + 1);

[BadRespawn]

Het punt is dat een vergelijking als x = x + 1 wiskundig nooit op te lossen is.

In programmeertalen is zoiets als x=3 of x=x+1 doorgaans niet een wiskundige vergelijking, maar het is een operatie, een bewerking van x. Dwz aan x wordt een (nieuwe) waarde toegekend.

[Verwijderd]

offtopic:
thanks

[Fealine]

Wat RayNBow bedoelt is dat een wiskundige vergelijking x=x+1 niet mogelijk is, aan gezien er geen waarde voor x te vinden is waarvoor deze vergelijking kan worden opgelost. In een normale c code verhoog je hier natuurlijk gewoon x met 1.

Hoe dit dan in single assignment c werkt weet ik niet precies, maar ik kan mij voorstellen dat je elke variabele maar eenmaal mag assignen en ook dan is x=x+1 niet mogelijk.

[Boondock_Saint]

Klopt. Als je dan de waarde x +1 nodig hebt, dan zal je die aan een nieuwe variabele moeten toewijzen.

[bReChThOu]

Als je gewoon genoeg threads gebruikt, gebruik je toch standaard alle cores? Of denk ik nu te simpel op deze zonnige zaterdagmorgen?

[Trolando]

Het ligt er maar net aan wat je wil. Als je een zware berekening uitvoert, wil je precies zoveel threads hebben als cores. Maar dan ben je er nog niet. Je moet het algoritme ook nog goed ontwerpen.

Maak je gebruik van pthreads voor het locken van geheugen en is je algoritme geheugenintensief? Dan wordt er zo vaak gelockt, dat er weinig meer echt berekend wordt. Je kunt gebruik maken van Compare-And-Swap maar dan moet je heel goed opletten op wat er mis kan gaan.

Als je meerdere cores gebruikt (doordat je meerdere threads hebt) heeft elke core een eigen cache en moet je opletten dat als je een waarde in de ene thread manipuleert, dit niet onmiddellijk overal zichtbaar is. Hierdoor kun je behoorlijke rekenfouten maken.

En dan hebben we het over multithreading in een standaard computer, met 1 multicore x86 processor, en 1 groot stuk geheugen. Waar ze het bij deze summer school onder andere over gaan hebben, is het gebruiken van de duizenden processoren op een grafische kaart, en over een speciale programmeertaal waardoor je minder rekening hoeft te houden met locking issues.

[Mr_Light]

"wil je precies zoveel threads hebben als cores"
dat gaat alleen op als al je data zich al bij de cores bevind.

Zo dra een core moet wachten op data kan een thread beter yielden en een andere thread z'n gang laten gaan. bij even veel thread als cores heeft yielden geen zin omdat er geen thread is omiets te doen.

Ook vergeten jullie nog een aspect dat zich voordoet bij applicaties welke niet perse tot een antwoord komen, zo als regel systemen etc hierbij gaat prioriteit en cooperativiteit etc ook nog een rol spelen.

Wat ik een beetje mis in het programma is de trend in scientific computing om de overcapaciteit van de clouds te gebruiken voor een paar grijpstuivers. Aan de andere kant hebben ze geloof ik hier een mooie master voor.

[Pavla]

Het probleem is dat meerdere threads vaak op één object willen werken. Bijvoorbeeld een queue, waarbij één thread werk aanmaakt (de producer) en meerdere threads werk consumeren (de consumers).
Parallel werken op één object kan, zonder speciale beveiliging, zorgen dat veel werk dubbel wordt gedaan (meerdere threads halen hetzelfde object uit de queue), dat er null pointer exceptions worden gegooid (er worden bewerkingen op niet bestaande objecten gedaan) enz.
Deze problemen zijn wel op te lossen, maar vereisen een zekere vorm van sequentialisatie doormiddel van locks (zodat maar één thread tegelijk een kritiek codegebied kan binnengaan) of algoritmen die enkel gebruik maken van atomaire stappen.

Dus ja, het is iets lastiger dan je denkt

[LauPro]

Iedereen die pthreads een beetje snapt en het voor elkaar krijgt om zijn applicatie op te delen in tasks en die aan te roepen met workers heeft in principe een multi-core enabled programma gemaakt.

[YopY]

Je denkt te simpel, . De uitdaging in multicoreprogrammeren zit hem niet in het aanmaken van meerdere threads, maar het delen van informatie tussen die threads. Als twee threads 1 gedeelde variabele willen uitlezen (zoals bijvoorbeeld een lijst van taken), dan heb je al een probleem.

Natuurlijk ligt dat maar net aan hoe je het probeert op te lossen. Moderne talen en -frameworks gebruiken als alternatief voor het klassieke threading model met locking en synchronisatie (dwz dat een gedeelde variabele 'op slot' gezet wordt, dwz dat er maar 1 thread tegelijkertijd bij kan) bijvoorbeeld Actors of Messaging of hoe het maar heet - ipv dat een thread zelf probeert bij data te komen, wordt de taak ernaartoegestuurd. Het resultaat wordt vervolgens ook weer door- of teruggestuurd, om afgehandeld te worden wanneer het maar kan. Een veel eenvoudiger programmeermodel dan proberen gedeelde data op slot te zetten.

[pakka680]

Verbaast me dat dit nog zo actueel is. Het parallel programmeren is toch al tenminste 20 jaar oud. Is er nog geen geautomatiseerde mogelijkheid om "normale" programma talen efficiënt in x-core programmatuur om te zetten?

Als ik naar 25 jaar geleden kijk heb ik nog wel zitten te programmeren in assembler omdat de C-compiler het allemaal niet zo slim deed maar in een aantal jaren waren de C-compilers zo goed (en de processoren zo ingewikkeld/uitgebreid geworden qua instructieset) geprogrammeerd dat er bijna geen eer meer aan te behalen was om het nog significant sneller te krijgen.

Is er niet meer behoefte aan een cursus die inhoudelijk gaat over hoe (betere) multicore compilers te bouwen?

[RayNbow]

Is er nog geen geautomatiseerde mogelijkheid om "normale" programma talen efficiënt in x-core programmatuur om te zetten?

Dit is een droom dat het functionele programmeerkamp voor een lange tijd geprobeerd heeft te bereiken. Omdat in een pure, lazy functionele programmeertaal de evaluatievolgorde niet vastligt, is de compiler vrij om de volgorde zelf te bepalen en bepaalde expressies in parallel te laten evalueren.

Het is echter vrij lastig voor de compiler om te bepalen hoeveel werk het kost om een willekeurige expressie te evalueren. De hoeveelheid werk mag niet te klein zijn, want dan weegt het niet op tegen de overhead om de expressie op een andere core te evalueren. Het mag ook niet te groot zijn, want dan verspil je een kans om het werk verder op te delen.

Voor een compiler is het dus lastig om de juiste granulariteit te bepalen. Er is wel werk op dit gebied verricht. Zo kun je in Haskell expressies annoteren met o.a. de par-combinator. Dit zijn hints naar de compiler en runtime system dat het de moeite waard is om een bepaalde expressie in parallel te evalueren.

(Meer info over par: Beautiful Parallelism - Harnessing Multicores with Haskell (PDF))

[Infant]

Zo zou er nog weinig gebruik worden gemaakt van single assignment c, een programmeertaal die speciaal voor meer dan één core is bedoeld en die op een van de dagen van de summerschool wordt behandeld.

Dit is volgens de SA-C site een taal meer voor FPGA en cicuit development.... en heeft niet echt zozeer iets met core's uit een normale PC te maken. Correct me if I'm wrong.

[Squee]

Het is een beetje verwarrend maar er zijn twee talen genaamd "single assignment c". De taal waar het hier om gaat bij de summerschool is niet SA-C maar SaC: http://www.sac-home.org/

Die taal is meer een functionele taal gebaseerd op C syntax. Je kan makkelijk data-parallele operaties uitdrukken met arrays. Omdat het veel meer gestructureerd is dan C (single assignment, geen side effects) is het veel makkelijker automatisch te paralleliseren door de compiler.

Zie ook;
http://en.wikipedia.org/wiki/SAC_programming_language

[ILUsion]

Een FPGA of digitale schakelingen in het algemeen kan je gewoon zien als een soort massieve parallelle processor. Een CPU-core kan per tijdseenheid één instructie uitvoeren die misschien wel ingewikkeld is en vrij gekozen kan worden. In een digitale schakeling kan je duizenden kleine berekeningen tegelijk laat uitvoeren; maar dat houdt zoals gezegd ook in dat je voor communicatie tussen verschillende berekeningen wel wat meer moet doen dan wanneer je de tijdschaal voor alle delen vastlegt.

Door de technieken uit dat domein ook te gebruiken voor gewone computers, maak je dus eigenlijk optimaal gebruik van de kennis die men daar al opgebouwd heeft.

[H!GHGuY]

Lijkt me een goed initiatief om uiteindelijk te laten uitgroeien tot een normaal vak en nascholingscursus. Er is dan wel veel informatie aanwezig op het internet (bvb drdobbs, of gotw.ca), maar een gestructureerde nascholing is voor veel afgestudeerden de beste manier om bij te scholen.

[Reactie gewijzigd door H!GHGuY op 22 juli 2024 15:20]

[TGEN]

Op andere universiteiten is Parallel Computing al een normaal vak...

[T020]

Ik zit zelf op de UvA (en ben dus ook uitgenodigd voor de summerschool). Er is al een apart vak "Gedistribueerde Systemen" waarbij een project hoort dat het programmeren van een gedistribueerde server omhelst. Ook wordt in een ander vak gebruik gemaakt van MPI.
Deze summerschool is dus een extra voor degenen die wat meer willen weten en dus ook echt bezig willen zijn met programmeren, i.p.v. alleen de concepten te kennen.

[Lukosje]

Mwa op de VU ook, ben er de afgelopen periode mee bezig geweest. Dit is gewoon een extraatje.

[SKiLLa]

Sterker nog, dat was het 15 jaar geleden op de VU (en vermoedelijk de UvA) ookal hoor
Wel wordt het steeds belangrijker & mainstream dan vroeger en dus zou de focus er inderdaad meer op moeten komen te liggen ...

[Boondock_Saint]

Op de UvA ook, heb voor m'n bachelor daar Parallel Computing & Distributed Systems gedaan en voor m'n master het keuzevak Concurrent Programming. Daarbij wordt de basic theory uitgelegd zoals deadlocks, race conditions, semaphores en mutex etc.

Qua praktijk leer je dan pthreads, OpenMP en MPI. Vond het echter wel een gemis dat zoiets als Erlang helemaal niet behandeld werd, terwijl het toch een opkomende taal is. Misschien in deze summer school wel

edit:
typo

[Reactie gewijzigd door Boondock_Saint op 22 juli 2024 15:20]

[Nijn]

VU heeft zelfs een master opleiding, High Performance Distributed Computing, waar heel veen parallelisering in voorkomt.

[Verwijderd]

Dit hoort gewoon een standaard onderdeel te zijn van elke informatie opleiding HBO of universitair. Als je als ontwikkelaar dit nooit hebt gehad dan mis wel degelijk iets want multi-tasking komt in het dagelijks werk zeer regelmatig naar voren. (Zelfs smartphones zijn tegenwoordig multi-core) GPU's programmeren is meer een specialisatie voor multi-media en wetenschappelijke doeleinden.

[BlackHawkDesign]

Ik ben het niet met je eens. Dit soort dingen, zijn meer praktische zaken en hebben met name met implementatie te maken. In de opleidingen (hbo informatica, msc software engineering) die ik gevolgd heb/ volg, gaat het meer om op een abstractere manier naar software te kijken. Je leert wel programmeren en bepaalde technieken, maar dat zijn niet de belangrijkste leerdoelen. In opleidingen waar het een stuk technischer aan toe gaat, zoals Nijn hierboven aangeeft, spelen dit soort dingen wel een grotere rol en zit het er vaak ook wel in.

Multi tasking en multi core zijn verschillende dingen, volgens jouw verhaal houdt het in dat je geen multi tasking kan uitvoeren op een single core, wat onzin is. Het OS regelt dit soort zaken voor een programmeur, echter bij een groot programma is het efficiënter om het programma zelf ook over meerdere cores te verdelen als deze beschikbaar zijn.

Leuke cursus en als ik niet bezig was met me scriptie zou ik hem misschien gaan volgen. Vind het alleen jammer dat ik dit op tweakers moet lezen en hier niks over hoor van de uva zelf aangezien ik zelf op de uva zit. Dit terwijl ik wel plat gemaild wordt over studentenraden verkiezingen, intree week begeleiding en andere zaken.

[sirdupre]

Ik ben het er eerlijk gezegd totaal niet mee eens dat dit soort dingen meer "praktische zaken" zijn. De theorie van gedistribueerde systemen die moeten samenwerken is bijzonder complex en wiskundig/logisch onderbouwd en misschien wel één van de belangrijkste verworvenheden van de informatica. Het is vanuit een theoretisch oogpunt ook bijzonder complex: waar normale programma's maar één mogelijke executie volgorde hebben (dat wil zeggen, de volgorde waarin de stappen waaruit het programma is opgebouwd wordt uitgevoerd), vervalt deze aanname zodra je met parallelle programma's gaat werken en dat heeft direct consequenties op de manieren waarop je de correctheid van je programma of systemen kunt beargumenteren.

Ik beschrijf een belangrijke moeilijkheid van dit soort systemen altijd een beetje als een kruising op de weg waar van alle vier de kanten tegelijkertijd een auto aan komt rijden en er geen stoplichten aanwezig zijn. De voorrangsregels zeggen in dat geval dat iedere auto voorrang moet verlenen aan de auto rechts van hem, waardoor in deze situatie iedereen op elkaar moet wachten. Mensen lossen dit waarschijnlijk op door de wet van de brutaalste toe te passen, maar in het geval van computers die identieke programmatuur aan boord hebben gaat die vlieger niet op - zonder een extra systeem met een seinpaal* zullen de auto's alle vier tegelijk rijden, of alle vier nooit rijden.

Het analyseren van dit soort problemen en het vinden van oplossingen is denk ik juist iets wat wél in een opleiding informatica thuis hoort en ik denk dat je dit soort problemen ook zeker niet af kunt doen als "te praktisch" of "te weinig abstract".

* Het is uiteraard niet ontoevallig dat ik hier seinpaal gebruik in plaats van stoplicht: seinpaal is namelijk het woord dat Dijkstra gebruikte toen hij de semafoor (een abstract concept waarmee je dit soort problemen kunt oplossen) introduceerde in de tekst http://www.cs.utexas.edu/...ptions/EWD00xx/EWD74.html

[TrailBlazer]

700 euro is in het bedrijfsleven een schijntje voor een cursus van 5 dagen. Als je het dubbele zou vragen zouden ook maar weinig bedrijven hier wakker van liggen denk ik.

[Verwijderd]

Het probleem is niet de prijs. Het probleem is dat het een cursus voor programmeurs is. In Nederland worden programmeurs gezien als een soort vuilnisophalers. Een soort uitzendkrachten. Je laat de snelle jongens plannen en strategieen ontwikkelen. Waarna uiteindelijk in de laatste stap een stelletje verlegen nerds ergens in een hoekje stilletjes de code mogen schrijven. Ik denk dat management liever geld investeert in Polen die augurken komen plukken in de zomer, dan in programmeurs.

Het is geen wonder dan de meeste fatsoenlijke software van buiten Nederland komt.

[Theadalus]

Het is geen wonder dan de meeste fatsoenlijke software van buiten Nederland komt.

Uhmm, wel eens van outsourcing gehoord?

Veel programmeerwerk wordt tegenwoordig ge'outsourced naar lage loon landen (India, China, Bangladesh, etc.), de kwaliteit die daar vandaan komt is dikwijls om te huilen (persoonlijke ervaring)! Een beetje Nederlandse programmeur kan beter, maar die is niet meer rendabel t.o.v. lage loon personeel.

[Verwijderd]

Onzin. Outsourcing is imho nog weer een voorbeeld van hoe Nederlands management denkt dat programmeren ongeschoold werk voor mongolen is. Je koopt het gewoon in India, en het maakt niet uit of het goed is.

Terwijl programmeren gewoon een vak is. Goede progammeurs of slechte programmeurs maken een wereld van verschil voor het eindresultaat. Ik ben er van overtuigd dat een (1) hele goede programmeur meer waard is dan 10 of meer mediocre programmeurs. Voor het mediocre team heb je een manager nodig, die meer geld kost en voor verwaring zorgt. Je moet een functioneel analyst hebben. Een senior teamlead. Als de software kut is, moet je testers hebben. En twee testers moeten weer een eigen testing manager hebben. En als je twee managers hebt, dan moet er weer secretaresse komen. En een vertegenwoordiger van het upper management (project lead). Als je dan 20 man hebt op je project (waarvan de helft maar code schrijft), dan moet je ook je eigen marketing man hebben. En zo houdt het nooit op.

Terwijl een goede programmeur gewoon het design doet, de code schrijft, het design aanpast aan het gevorderde inzicht, en dan zelf de bugs er voor een groot deel uit haalt (die er veel minder in zitten). Een zo'n hele goede programmeur preseert net zo veel als een team van 20 mediocre mannetjes. Maar als je zo'n programmeur kent, of gevonden hebt, denk je dan dat management daar voor wil betalen ? Nope. Nooit niet. En als ze al willen, dan komt Personeels Zaken aanzeiken dat dat echt niet kan. Die goede programmeur moet gewoon genoegen nemen met het standaard loon (50k euri), en anders opzouten, en dan zetten ze er een mediocre team op, waarvan de 2 managers ieder al meer dan het dubbele verdienen. Zo gaat dat in Nederland, volgens mij.

[Theadalus]

Klopt helemaal wat je zegt, alleen nu spreek je jezelf tegen wat betreft de opmerking:

Het is geen wonder dan de meeste fatsoenlijke software van buiten Nederland komt.

En die opmerking reageerde ik dus op.

Om dan gelijk 'onzin' te roepen, terwijl je mijn reactie niet eens goed gelezen/begrepen hebt... Ik gebruik alleen wat minder woorden, maar volgens mij zitten we wel redelijk op 1 lijn.

[Verwijderd]

Sorry, dat had ik dan verkeerd begrepen. Omdat je zelf zei dat Nederlandse programmeurs niet meer rendabel zijn ten opzichte van outsourcing, dacht ik dat je van de "nieuwe school" was die programmeren maar VMBO werk vind.

En met "van buiten Nederland" bedoelde ik gewoon dat we (voornamelijk) Amerikaanse software kopen, ipv zelf eens wat nieuws te maken. Ik had helemaal niet aan outsourcing gedacht.

[arendjr]

Ik weet niet of dit is zoals je voelt dat je zelf behandeld wordt op je werk, maar zo ja, dan zou ik adviseren op zoek te gaan om voor een leuke technologie-startup te gaan werken ipv detachering of een ander groot bedrijf wiens core business niet in de technologie zit.

[Verwijderd]

Ik heb al jaren vakantie. Ik heb in de jaren negentig voor een Amerikaans bedrijf gewerkt. Een bedrijf dat besefte dat technologie zijn kernbusiness is. Waar software engineers net zoveel (kunnen) verdienen als managers, en fellows net zo veel verdienen als VPs.

Ik had (en heb) echter het idee dat er in Nederland compleet anders over gedacht wordt door management. Zelfs in technologie-gefocuste bedrijven. Techneuten (mensen die echt weten hoe iets werkt, of echt iets kunnen maken) worden vooral als kostenpost gezien. Lastig. Moet je weghouden van de klant. Moet je vooral geen beslissingen laten nemen. Als ik soms (een keer per half jaar) eens een jobsearch doe, dan wordt ik altijd triest van de lage salarissen die ik zie.

Misschien is het tijd om weer eens te gaan werken. Ik verveel me soms. Maar mijn opties liggen of in het buitenland (en dat wil ik niet meer). Of een lullig baantje hier in de buurt. Technology-startups in Nederland ? Zijn die er dan ? Pointers, urls ?

[Verwijderd]

Dank je wel voor je vriendelijk aanbod. Maar ik denk niet dat ik ga passen in Qurius. Ik heb net even op de webpagina gekeken.

Het lijkt er op dat Qurius een automatiseringsbedrijf is dat met bestaande technologien ERP-oplossingen (e.d.) in elkaar draait voor bedrijfsadministratie. Niet bepaald wat ik een "technology startup" zou noemen. Bovendien heb ik niet de benodige background. Ik ben een Unix/C/networking jongen. Geen Microsoft achtergrond. En geen interesse in automatisering.

Eventjes gekeken naar de paginas waar Qurius zichzelf presenteert. De dagelijkse leiding is in handen van 2 ex-accountants (CEO en CFO). Hebben jullie geen CTO ? Geen fellows of distinguished engineers ? Veel keywords als "oplossingen, duurzaamheid, innovatie, resultaatgericht", etc. Mooie woorden om klanten te trekken. Maar ik zie nergens anders op de website ook maar iets over de technologie of de mensen die daar aan werken. Geen teken dat programmeurs daar anders behandeld gaan worden dan zoals te doen gebruikelijk bij Nederlandse automatiserings bedrijven. PS. En een verschil maken tussen software architect en programmeur, dat is al helemaal niet een bedrijf waar ik voor wil werken. Sorry.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 15:20]

[TheWhizKid]

Ieder zn mening uiteraard! Maar afketsen op het feit dat wij programmeurs en architecten hebben lijkt mij wat vreemd. Nogmaals, ieder zn mening. Ik heb veel plezier en vrijheid in mijn werk, en onze (.NET) programmeurs worden als zeer waardevol beschouwd.

[Verwijderd]

Nee, de reden is het volgende. Wij (arendjr hierboven) hadden het hier over een baan bij "een leuke technologie-startup". Jij komt met een baan bij een integratie-boer voor bedrijfsadministratie. Mijn begrip van het woord "technology-startup" is een bedrijf dat nieuwe technologie maakt. Jou bedrijf gebruikt alleen bestaande technologie. Dat is een wereld van verschil.

De scheiding van verantwoordelijkheden die gesuggereerd wordt door de namen "software architect" en "programmeur" doet mij vermoeden dat het er net zo aan toe gaat als bij andere Nederlandse bedrijven. Een hierarchiesche structuur. Met "code monkeys" onderaan. En "architecten" bovenaan, die zelf geen regel code meer schrijven. Dat is niet wat ik leuk vind.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 15:20]

[Xthemes.us]

Vond het ook al verbazend laag, waarschijnlijk dan ook omdat het vanuit een universiteit gaat en de docent sowieso al uitbetaald moet krijgen? 700 euro ben je bij sommige cursussen al voor een enkele dag kwijt.
Op de site staat dat er ook onderdak voor je geregeld kan worden voor €220,- lang niet gek.

offtopic: Die site is wel uhm 'opvallend' gekleurd zeg.

[Verwijderd]

Deze kennis kun je denk ik in hoge mate ook gebruiken voor distributed computing, in dat geval zitten de cores niet in één machine of één lokatie, maar wereldwijd verspreid.
Interessante training, lijkt mij zeer leerzaam. Maar kun je alleen multi-core programmeren in SA-C? Kan dit niet gewoon in C, Python, Java etc? De programma's die ik in Linux gebruik welke multi-threaded zijn, komen volgens mij ook gewoon uit C en Java, dacht ik (Avidemux bijv.)

[Trolando]

Je noemt nu allerlei verschillende technieken.

Als je een ingewikkelde berekening doet, kun je die vaak opdelen in kleinere berekeningen. Elke berekening hangt weer af van andere berekeningen, die wel los van elkaar uitgevoerd kunnen worden. De verschillende threads moeten dan goed met elkaar communiceren om te bepalen welke berekening "aan de beurt" is. Dat gaat redelijk makkelijk als je op een multicore computer snelle communicatie hebt. De bottleneck zit dan vaak in het geheugen.

Voor een clustersysteem of distributed computing gebruik je een heel ander schema. Je kunt het werk dan verdelen over verschillende systemen, doordat je per berekening bepaalt wie verantwoordelijk is voor de uitvoer ervan. Van een opdracht bereken je bijvoorbeeld een hashwaarde, en wanneer die gelijk is aan "1" geef je 'm aan pc 1, en "2" aan pc 2, enzovoorts. De bottleneck zit dan vaak in het netwerk.

Dit soort dingen kun je natuurlijk prima in C en in Java doen, maar het wordt een stuk makkelijker als je een speciaal daarvoor ontwikkelde taal gebruikt, die het werk uit handen neemt. Allerlei onderzoekers hebben namelijk al slimme technieken ontwikkeld om dit soort dingen efficient en schaalbaar te doen, waar zulke talen gebruik van maken.

[SuperDre]

tja, en dat noemen we frameworks.. daar heeft de taal eigenlijk geen invloed op.

Het zou juist beter zijn als deze opleidingen JUIST mensen leren hoe het dus werkelijk op laag niveau in elkaar steekt in plaats van ze Yet Another Language laten gebruiken/leren die het allemaal weer voor je doet (en 9 van de 10 keer toch niet gebruikt word in de real world).

[Verwijderd]

De mogelijkheid om het op laag niveau te doen is er al decennia maar het probleem is juist dat dit zo complex is dat ontwikkelaars het vaak niet, onjuist of suboptimaal gebruiken. Juist daarom zijn die high-level frameworks zo belangrijk, deze nemen een hoop complexiteit weg waardoor de drempel naar parallel computing voor de ontwikkelaar wordt verlaagd. Dat neemt niet weg dat je alsnog moet weten wat je aan het doen bent. Je kan bijvoorbeeld heel leuk disk-access gaan paralleliseren maar met een harddisk die maar een stukje data tegelijk kan lezen schiet je daar weinig tot niks mee op. Maar met je opmerking over YAL ben ik het roerend eens.

[Titulanix]

In de wereld van de wetenschap wordt vaak gewerkt aan problemen waar zeer veel berekeningen moeten worden gemaakt om één 'complexe som' op te lossen.
In het bedrijfsleven is het meestal omgekeerd: er worden vele klanten tegelijkertijd bediend met relatief simpele berekeningen, die niet aan elkaar gerelateerd zijn. Parallellisme is hier vooral een zaak van: hoe houdt ik mijn processor core nuttig bezig voor klant 2, terwijl het proces voor klant 1 moet wachten op de database.
Ik vraag me daarom af voor hoeveel ontwikkelaars uit het bedrijfsleven deze cursus nuttig zou kunnen zijn (dat is iets anders dan leuk )

[0rbit]

En hoeveel wetenschap denk je dat er bij grote bedrijven gepleegd wordt? Juist. Vrij veel. Alles met een eigen ontwikkelafdeling met betrekking op produktontwikkeling heeft hier direct baat bij.

[Crossive]

Jammer dat ik nog niet aan het afstuderen ben, anders zou ik dit met genoegen hebben gevolgd. Ik neem aan dat er gewoon wat meer kennis vereist is, wil je dit snappen. Hopelijk gaan ze dit soort acties vaker uitvoeren!