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)
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 zaterdag 4 juni 2011 09:58]
Op andere universiteiten is Parallel Computing al een normaal vak...
Mwa op de VU ook, ben er de afgelopen periode mee bezig geweest. Dit is gewoon een extraatje. 
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 ...
Wel wordt het steeds belangrijker & mainstream dan vroeger en dus zou de focus er inderdaad meer op moeten komen te liggen ...
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
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
typo
[Reactie gewijzigd door Boondock_Saint op zaterdag 4 juni 2011 12:38]
VU heeft zelfs een master opleiding, High Performance Distributed Computing, waar heel veen parallelisering in voorkomt.
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.
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.
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.
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.
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.
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
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
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!
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.Zo zou er nog weinig gebruik worden gemaakt van single assignment c,
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 zaterdag 4 juni 2011 09:57]
offtopic:
Mag dat niet?
Want je ziet best wel vaak ipv 'x++' 'x+1' staan in code?
Mag dat niet?
Want je ziet best wel vaak ipv 'x++' 'x+1' staan in code?
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.
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.
offtopic:
thanks
thanks
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...
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.
(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);
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);
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.Het punt is dat een vergelijking als x = x + 1 wiskundig nooit op te lossen is.
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.
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.
Klopt. Als je dan de waarde x +1 nodig hebt, dan zal je die aan een nieuwe variabele moeten toewijzen.
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.
Als je het slecht doet krijg je "world hello" ofzoiets.
Jammer dat het visuele gebeuren, buiten de GPU, nog altijd in de mainthread dient plaats te vinden, tegenwoordig in WPF via de dispatcher. .NET heeft overigens wel enkele extensionmethod .ToParallel()
[Reactie gewijzigd door ravelaar op zaterdag 4 juni 2011 09:53]
delen van je scherm op verschillende momenten updaten doet pijn aan je ogen.
En overigens moet je wel heel krom programmeren wil je het met 2d gui niet redden om het op de framerate van je scherm te kunnen updaten.
En alle gui toolkits die ik heb gezien hebben gewoon een aparte event-dispatcher thread, wat niet perse je main thread is.
En overigens moet je wel heel krom programmeren wil je het met 2d gui niet redden om het op de framerate van je scherm te kunnen updaten.
En alle gui toolkits die ik heb gezien hebben gewoon een aparte event-dispatcher thread, wat niet perse je main thread is.
Ik heb aan de RuG meerdere "parallel programming" vakken gevolgd tijdens mijn Bachelor, zoals:
- Concurrency, (oud, werd gegeven door professor Wim Hesselink), waarbij je met de programmeertaal SR aan de slag ging,
- APPHPS (oud, werd gegeven door dr. Nicolai Petkov), waarbij je met Fortran aan de slag ging,
- Parallel Computing (nieuw, wordt gegeven door dr. Arnold Meijster), waarbij je met C, MPI, OpenMP en POSIX Threads (a.k.a. pthreads) aan de slag gaat
Het was voor mij niet alleen bijzonder om het te volgen, maar het is was soms ook erg moeilijk.
- Concurrency, (oud, werd gegeven door professor Wim Hesselink), waarbij je met de programmeertaal SR aan de slag ging,
- APPHPS (oud, werd gegeven door dr. Nicolai Petkov), waarbij je met Fortran aan de slag ging,
- Parallel Computing (nieuw, wordt gegeven door dr. Arnold Meijster), waarbij je met C, MPI, OpenMP en POSIX Threads (a.k.a. pthreads) aan de slag gaat
Het was voor mij niet alleen bijzonder om het te volgen, maar het is was soms ook erg moeilijk.
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.
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.
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.
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.
Het is geen wonder dan de meeste fatsoenlijke software van buiten Nederland komt.
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.
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 ?
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 ?
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.
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 gryz op zaterdag 4 juni 2011 22:46]
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.
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.
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 gryz op maandag 6 juni 2011 02:44]
Uhmm, wel eens van outsourcing gehoord?Het is geen wonder dan de meeste fatsoenlijke software van buiten Nederland komt.
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.
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.
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.
Klopt helemaal wat je zegt, alleen nu spreek je jezelf tegen wat betreft de opmerking:
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.
En die opmerking reageerde ik dus op.Het is geen wonder dan de meeste fatsoenlijke software van buiten Nederland komt.
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.
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.
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.
Als je gewoon genoeg threads gebruikt, gebruik je toch standaard alle cores? Of denk ik nu te simpel op deze zonnige zaterdagmorgen?
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
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
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.
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.
. 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.
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.
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.
"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.
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.
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 )
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
)
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.
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.
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.
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.
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.
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
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
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
