Microsoft bouwt auto-threading compiler

Microsoft Research heeft een compiler ontwikkeld die het mogelijk zou maken om singlethreaded code die in C# is geschreven deels om te zetten naar multithreaded code. Hierdoor moet de complexe en tijdrovende ontwikkeling van multithreaded code eenvoudiger worden.

Rond 2004 nam het belang van de kloksnelheid als indicator van de processorsnelheid af ten opzichte van andere chip-eigenschappen: fabrikanten gingen zich onder andere meer op parallelle dataverwerking richten. Het logische gevolg was de komst van multicoreprocessors waarbij meerdere rekeneenheden in een chip worden verpakt.

Om de rekenkracht van moderne multicoreprocessors te kunnen benutten, dient software gebruik te maken van multithreaded code. Het schrijven van dergelijke code is echter complex en tijdrovend, mede omdat bepaalde bugs die kunnen optreden lastig zijn te reproduceren. Microsoft Research heeft echter een onderzoek vrijgegeven waarin het een compiler beschrijft die singlethreaded code via een 'auto-threading'-mechanisme deels om kan zetten naar multithreaded code.

De inputcode voor de experimentele compiler is C#. Door gebruik te maken van technieken als polymorphism en mechanismen die ingezet worden bij functional programming, zou de C#-code waar nuttig door de compiler geoptimaliseerd kunnen worden voor meerdere cores. Microsoft zou de compiler al hebben getest op een 'groot project' al is niet duidelijk over welk project het precies gaat. Ook zouden er met behulp van de compiler webservers en mpeg-decoders zijn gebouwd. Onbekend is nog wat de toekomst is voor het project.

Reacties (62)

Ik heb de paper hierover even snel doorgenomen en het is dus niet dat applicaties ineens op automagische wijze mutli-threaded worden, maar dat er keywords zijn toegevoegd om variabelen te kunnen groeperen en te kunnen bepalen welke variabelen thread-safe aangepast kunnen worden, welke variabelen immutable (horen te) zijn, e.d.

Een ander voordeel is dat Microsoft deze uitbreiding op C# nu een tijdje gebruikt en dat ze bugs hebben gevonden in software, omdat deze uitbreiding bijv. heeft gedetecteerd dat een immutable variabele toch aangepast werd in een andere thread. Het kan dus ook helpen bij het vinden/oplossen van bugs in multi-threaded code.

Uiteraard heb ik geen ervaring met deze uitbreiding, maar dit lijkt mij een goed idee. Normaal gesproken zou ik denken dat dit wel ten koste gaat van performance (zelf een goede multi-threaded implementatie schrijven zou wel eens efficienter kunnen zijn, mits bug-free), maar blijkbaar is dat juist niet het geval. Deze uitbreiding is gericht op performance en de team bij Microsoft die nu een tijdje hiervan gebruik heeft gemaakt, heeft ook niks gemerkt van een lagere performance.

Het komt dus grofweg neer op een soort OpenMP implementatie voor C#

http://en.wikipedia.org/wiki/OpenMP

Volgens mij niet. OpenMP is een gewoon een API die multiprocessing aanbiedt. Ik heb geen ervaring met OpenMP verder, maar ik kan zo niet vinden dat OpenMP bepaalde logica toepast om variabelen te groeperen op immutability, readability enz. om zo een stuk code om te zetten in een correcte (!) multi-threaded versie.

Multi-threading kan je ook wel met gewoon C#, maar dit is juist een manier om correcte multi-threaded code te genereren.

</troll>.

OpenMP is een primitieve extensie voor C, een simpele niet-OO taal. Zoals al in de samenvatting staat werkt deze techniek met polymorfisme, OO dus. Microsoft heeft dus zeker wel iets nieuws.

foreach statement is zoiets wat Microsoft heeft bedacht. Maken we allemaal graag gebruik van in willekeurig welke programmeertaal dan ook tegenwoordig.

Het zit al bijna een eeuw in Unix shells. (Bournse Shell, Unix Version 7, 1979). Geen Microsoft idee dus.

Battling Tuberculosis Through Microsoft Technology

Dec. 03, 2012

Microsoft Research develops biometric monitoring system to help patients complete tuberculosis treatment programs.

Microsoft zou de compiler al hebben getest op een 'groot project' al is niet duidelijk over welk project het precies gaat.

Volgens Microsoft-watcher Mary Jo Foley gaat het om Midori, dat geheime besturingssysteem dat vanaf scratch in C# wordt gebouwd.

Een uitstekende ontwikkeling. Helaas is het nog steeds moeilijk om qua performance het onderste uit de kan te halen in een muti threaded omgeving die je nu eenmaal hebt met multi core processoren. Een bijdrage hieraan is zeer waardevol mits het inderdaad goed werkt. De moeilijkheid zit vaak in een bottleneck van een routine waar andere routines op moeten wachten. De vraag is in hoeverre het MS lukt om dit geautomatiseerd te optimaliseren. Handmatig is het soms erg lastig en tijdrovend om echt een stuk tuning te doen. Juist in High Performance Computing speelt dit en dan wil je inderdaad permanent een zware load hebben want anders draai je tenslotte niet optimaal. Natuurlijk hangt e.e.a. ook af van de rest van je systeem.

Jammer dat het artikel trouwens meldt dat multi core CPU's onstaan zijn vanwege multi threaded omgevingen. Multi core CPU's zijn ontstaan omdat het pad van alsmaar oplopende kloksnelheid uiteindelijk doodloopt. Met de schaalverkleining van componenten op de CPU's werd het ook fysiek mogelijk om meerdere high performance kernen te hebben op een 'die'. Mits de software geen problemen zou hebben met multi core CPU's zou de acceptatie daarvan veel sneller verlopen.

Na een aantal jaar multithreaded (zie LabVIEW) geprogrammeerd te hebben kan ik je dit zeggen. Multithreaded maakt software wel efficienter maar niet per definitie beter. Vooral niet als multithreading onder water voor je gebeurt (In het geval van LabVIEW bepaald windows). Dit houd dus in dat windows ook kan besluiten dat alles in dezelfde core uitgevoerd wordt. Het wordt namelijk als afzonderlijke thread gezien en windows thread managment bepaald: waar, wat, wanneer uitgevoerd wordt. Dus het hoeft niet per definitie een winst op te leveren. Nu kunnen we zelf de voorkeur aangeven wat windows doet met threads en cores (http://msdn.microsoft.com...p/ms686760(v=vs.85).aspx). Dat gaat dus verdwijnen

Het geeft je als programmeur wel meer mogelijkheden om bijv. dingen parrallel uit te voeren. Echter je komt al snel tegen een aantal problemen aan te kijken. Welke code heeft welke waarde nu geupdate? Wanneer wordt iets geupdate? Hoe zorg je er voor dat threads synchroon lopen? enz. enz. enz.

Het grootste voordeel (performance) wordt ook het grootste nadeel. Je stapt uiteindelijk over naar minder efficient programmeren omdat je de performance toch wel heb. Vervolgens krijg je als software ontwikkelaar minder tijd om iets uit te voeren zodat je ook niet meer de kans heb om iets efficient te implementeren. Dus aan het einde van het liedje, is het leuk, maar schiet je performance er niet echt mee op.

[Reactie gewijzigd door _wolf_ op 4 december 2012 16:33]

Fijn dan hoef ik straks niet meer na te denken om multi-threaded te programmeren!

Ik denk dat om multi-threaded code te introduceren je architectuur daar wel geschikt voor moet zijn, voor 9 van de 10 toepassingen moet je toch echt kijken naar de performance van je applicatie zelf dan hem maar multi-threaded laten auto compilen. Zie het als 2 extra cilinders en een extra liter brandstof inhoud van je motor, tuurlijk maar je kan hem ook gewoon efficiënter maken met directe injectie en een kleine turbo.

Als je toch al immense power (ja een CPU op 100% laten lopen is immense tegenwoordig) nodig hebt houd je daar van te voren al wel rekening mee.

Mijn idee hier over: het voelt een beetje als een slechte patch voor matig programmeer werk in de eerste plaats.

[Reactie gewijzigd door GewoonWatSpulle op 4 december 2012 15:21]

Het kan werken als je zorgt dat code volgens bepaalde richtlijnen geschreven wordt én als de programmeur heel goed weet wat het effect hiervan is. Het laatste wat je wilt is dat er allerlei rare omwegen worden gebouwt om een compiler z'n trucje te laten doen terwijl dat helemaal niet in de structuur past. Een voorbeeld van zo'n random oplossing is de <asp:AjaxForm> tag, of iets soortgelijks, in de tijd dat mensen nog met webforms werkten. Die tag heeft samen met jQuery en MVC echter wel gezorgt voor AJAX awareness bij developers, misschien is dat ook wel het einddoel van het hele project. Dat je dit ziet als een kunstje wat aanzet tot écht inlezen als je marginaal meer wilt.

Ik denk dat het net zo iets is als allerlei andere optimalisaties die een compiler uitvoert. Het kost je niets om er gebruik van te maken en als je goed programmeert worden veen van de optimalisaties niet gebruikt omdat je daar zelf al voor gezorgd hebt. Alleen die paar keer wanneer jij dat niet gedaan hebt en er toch meer uit te persen is laat de compiler dan de code automatisch multi threaded maaken waarom niet?

Je moet het meer zien als slechte code blijft slechte code ook als je het in meerdere threads laat draaien wordt het er niet beter op.

In veel gevallen is met multi-threading geen eer te behalen ten opzichte van de tijd die je er in moet steken om de code in meerdere treads te laten draaien. Je moet het zo zien als jij in je code 20 processen uitvoert en 3 van die processen zouden ook multi-threaded kunnen draaien waar 1 je een uur executie tijd scheelt en de andere twee je nog geen 3 minuten elk zouden schelen dan zal je natuurlijk de tijd besteden aan die ene tijd vreter de andere twee zijn simpel weg niet interessant. Laat de compiler die dingen nu voor je om kunnen zetten naar multi-threaded executie of in ieder geval delen daar van. Dan is dat toch mooi mee genomen, als je daarna nog ergens tijd moet besparen dan kun je daar altijd nog op terug komen.

Zie het meer als een hulpje dan als iets waar je op moet vertrouwen en op eens is het niets anders dan de switch om SSE instructies te gebruiken waar nuttig, in je code hoef je er geen rekening mee te houden of iets speciaals te doen maar in de executie is het mooi mee genomen.

Optimalisatie is altijd een kwestie van eerst uitvinden waar je het meest kunt winnen voordat je aan de slag gaat. Als een deel van de code door de compiler sneller gemaakt kan worden dan is dat mooi mee genomen en hoef je daar minder snel naar te kijken. Maar zo als ik al zei slechte code is slechte code en dat gaat echt niet heel erg veel beter worden als je compiler het in meerdere threads laat draaien. Misschien dat je net iets minder snel dat deel van de code moet optimaliseren maar dat is dan ook wel echt alles dat het voor je zal doen.

Het zou op zich wel fijn zijn als Mozilla het voor elkaar krijgt Firefox door zo'n algoritme te gooien. Firefox is een fijne browser maar als singlethreaded applicatie loopt het nog steeds enorm achter op de concurrentie.

FireFox is geen C#, maar C++. Niet eens nette, reguliere C++ code, maar met hun eigen "XPCOM" component interface mechanisme. Dat wil zeggen dat zo'n autothreading compiler geen idee heeft of je de XPCOM aanroepen "Functie1(x)" en "Functie2(y)" tegelijk mag uitvoeren, en dan moet je ze veiligheidshalve single-threaded uitvoeren.

De brandstof is er, de cilinders zijn er... waarom dan niet gewoon benutten?
Ik zie weinig single-core processors op de PC-markt meer uitkomen. Zelfs dual loopt al terug.

Ik zit toch te hopen dat een programma als AutoCAD snel op meerdere cores kan draaien ipv. 1 (klein stukje dual is mogelijk, maar zeer beperkt bij parallel tasking).

Nu is mijn Xeon x4 steeds tussen de 23 en 26% belast. Wellicht dat dit voor kleinere programma's niet altijd zinvol is, maar de processor-intensieve taken zal het waarschijnlijk wel aan ten goede komen.

Daarbij komt ook dat AutoCAD een erg log programma met kreupele engine is... dus wat optimalisatie zou ook niet verkeerd zijn. Een combi van die twee zou nog meer welkom zijn dus! De V12 met vier turbo's en directe injectie!

Nu is het zo dat het programma op zich zelf wel genoeg zegt. Zoals Rob hierboven schrijft kan je een slecht programma niet de mooiste van het land maken.

Microsoft laat zien dat je met truukjes misschien wel iets verder kan komen, maar de mens zal altijd de bepalende factor blijven, je kan een compiler niet alles laten doen.

Misschien is de achterliggende gedachte wel hoe de Xbox360 werkt, het schijnt dat deze ook single-thread code draait en zelf "vertaalt" naar multi.

Je hebt duidelijk geen benul van parrallel programmeren.

Er zijn gewoon tal van zaken waarbij je heel goed meerdere cpu's in kan zetten, maar waarbij het micro-management mensen tegenhoud het te doen. Wanneer een compiler dat voor je doet, dan kun je zorgen dat:
* het makkelijk voor de programmeur is
* het correct gebeurd
* het alleen gedaan wordt wanneer het zinvol is.

Het is gewoon logisch om te kijken of je delen via de compiler kan afhandelen.

Zie het eerder als zelf proberen je auto op de weg te houden terwijl er nu toch ook Electronic Stability Control, Traction Control etc is om je auto op de weg te houden. Terwijl je ook gewoon beter kan gaan rijden.
Multi-threaded programmeren is gewoon complexer en daardoor gevoeliger voor problemen.

Vraag me af hoe ze het voor mekaar krijgen. Technisch gezien zou je het nog wel kloppend kunnen krijgen (geen race condities, geen deadlocks), maar daarmee is nog niet bewezen dat het performance wise gezien een voordeel is om berekeningen parallel uit te voeren. Immers er zit een context switch en die is relatief gezien vrij duur. Je moet al een flinke berekning hebben wil dat opwegen tegen die kosten. Of ze moeten iets als PGO gaan inzetten waarmee je eerst je applicatie door een profiler haalt die daarna alleen de interessante gebieden (ipv alle gebeiden) parallelliseert (zo'n soort test wordt ook gebruikt voor loop unrolling).

Overigens met TBB of PPL is parallellisatie in c++ nu al relatief makkelijk te doen.

Om die analogie wat verder door te trekken: ESC en ABS zijn toch echt voor een reden gebouwd. Computers kunnen veel sneller en preciezer reageren dan mensen, en dit soort systemen redden levens. Beter leren rijden is dus niet altijd de beste oplossing.

Mijn idee hier over: het voelt een beetje als een slechte patch voor matig programmeer werk in de eerste plaats.

Je kunt het ook als optimalisatie slag zien. Persoonlijk vergelijk ik het met het uitschrijven van bijvoorbeeld een for loop omdat de onderliggende hardware daardoor meer zaken in parallel kan verwerken. Door paralellisatie in de optimalisatie slag mee te nemen maak je het eenvoudiger om code te schrijven die het goed doet op verschillende hardware platformen.

Om de rekenkracht van moderne multicoreprocessors te kunnen benutten, dient software gebruik te maken van multithreaded code.

Dat geld natuurlijk alleen wanneer je wil dat 1 applicatie je volledige machinekracht gebruikt (of kan gebruiken). Wanneer je, zoals vrijwel iedereen doet, meerdere applicaties tegelijk draait heb je natuurlijk ook voordeel van een multi-core systeem, ondanks dat de applicaties misschien niet multithreaded zijn.

Het probleem zit hem er echter in dat in de toekomst, individuele processoren niet veel sneller zullen worden (is al jaren zo), maar dat er meer aan elkaar gehangen worden om performance te verbeteren. In de toekomst zal dit veel grotere vormen aannemen. Een voorproefje hiervan is bijvoorbeeld Parallella (http://www.kickstarter.co...upercomputer-for-everyone). Dan zit je niet met 4 tot 8 processoren, maar een heel array. Dan zijn dit soort ontwikkelingen heel nuttig.

Waar naar gezocht wordt is een goede manier om om te gaan met deze parallelliteit.
Momenteel zijn multithreaded programma's erg foutgevoelig. De aanpak van MS hier is helemaal abstraheren van de paralleliteit (hoewel er ook tools in .NET zitten om het een en ander handmatig te doen op een handige manier). Dit is fijn voor bestaande code, maar de vraag is in hoeverre de parallelliteit de code zelf moet beinvloeden.
Zonder kennis van de werking is het moeilijk om code te schrijven die baat heeft bij deze optimalisaties. Misschien moeten er gewoon wat nette taalelementen komen voor parallelle afhandeling.

Dat laatste wat je zegt dacht ik ook meteen aan. Een keyword als 'threadsafe' voor een functiedeclaratie of iets dergelijks zal de compiler zeker helpen. Hoewel, je zit dan al weer vrij dicht bij het handmatig zetten van mutexen, wat je eigenlijk probeert te 'verhelpen'.
In een taal als C# is een techniek als deze goed toe te passen, maar ik vraag me af hoe je om zou kunnen gaan met bv. pointers in C(++).
Los hiervan is deze techniek natuurlijk wel mooi voor grote bestaande projecten die singlethreaded zijn, scheelt een rewrite

Wanneer je, zoals vrijwel iedereen doet, meerdere applicaties tegelijk draait heb je natuurlijk ook voordeel van een multi-core systeem, ondanks dat de applicaties misschien niet multithreaded zijn.

Hier ben ik het helemaal mee eens.

Het is natuurlijk vrijwel nooit zo dat je op een quadcore drie of vier even zware processen hebt lopen, dus dat argument gaat niet echt op. Je moet wel heel gestructureerd werken om die situatie in de praktijk te creeeren. Het is misschien eerder zo dat je 1 enkele thread hebt lopen en daarnaast met iets anders bezig gaat. Ik noem maar wat, een render opdracht naast een browser. Als je echt zwaar en langdurig rekenwerk gaat doen, doe je dat toch meestal niet tijdens het actieve gebruik van de PC.

Door de mogelijkheid te hebben om een applicatie multithreaded te laten draaien, alleen de mogelijkheid al, verhoog je in essentie de potentiele prestaties van alle multicore CPUs die er zijn. Al zijn de momenten waarop het benut wordt schaars, alles is winst. Zeker wanneer er meerdere threads naast dit soort applicaties lopen, want ook dan kan de last verdeeld worden. Feitelijk zorgt auto-threading er dan voor dat elk stukje idle time per core benut wordt. Het zal dus ook zorgen voor een langere idle-time tussen opdrachten door (er wordt meer tegelijk gescheduled).

De winst is denk ik niet echt merkbaar in thuisgebruik.

[Reactie gewijzigd door Vayra op 4 december 2012 16:53]

Dat wordt door de scheduler van je OS geregeld, onafhankelijk of je code nou multithreaded is of niet.

Anders geformuleerd: als je wilt dat jouw stukje software de volle kracht kan benutten, moet je het multithreaded geschreven hebben.

Ik zie even niet zo snel hoe polymorfisme bijdraagt aan de paralellisatie van code. Kan iemand dit uitleggen?

Van wat ik uit de paper haal is dat polymorfisme niks met de paralellistatie heeft te maken. Ze hebben wel bewijs gegeven dat ook in gevallen van polymorfisme ze correct variabelen kunnen groeperen in immutable, e.d.

Dank je, ik dacht even dat ik wat gemist had.,

hooguit de truukjes zoals

.AsParallel<TSource> (IEnumerable<TSource>)
http://msdn.microsoft.com/en-us/library/dd413602.aspx

Task<TResult>
http://msdn.microsoft.com/en-us/library/dd321424.aspx

Nou ja, ik vind het wel de plek om op te lossen. Het lijkt me dat je bij voorkeur niet meer bezig bent met het geneuzel op lager niveau.

Maar multithreading is niet 'lager niveau'. Als multithreading een oplossing voor je probleem is, dan is het al onderdeel van je architectuur. Op een veel 'hoger niveau' dan dat kun je niet komen.

Als multithreading GEEN oplossing voor je probleem is, dan hoef je het ook niet op te nemen in je architectuur. Want dan gaat het toch niks helpen.

Multithreading toepassen is een optimalisatie is een oplossing voor een probleem: hoe benut je de CPU zo maximaal mogelijk.

Dit probleem kun je ook op andere manieren oplossen dan multithreading, maar soms is multithreading het meest optimale. Multithreading levert ook overhead op, het kost tijd een thread te starten, een context switch kost tijd, etc.

Als je dit probleem niet hoeft op te lossen, moet je geen multithreading gebruiken.

Ik zou zeggen dat dit een oplossing voor een probleem is dat niet bestaat. Multithreading kan niet fout gaan als je er van te voren genoeg aandacht aan schenkt in je architectuur.

Goed, dat brengt me dan op iets waar dit mogelijk WEL een oplossing voor is: dat architecten vaak onder druk moeten werken en niet genoeg tijd krijgen om hun architectuur goed uit te werken.

Dus is dit dan een oplossing voor management-druk...?

In een perfecte wereld kun je natuurlijk jáááren werken aan een project dat je anders in een maand zou doen, om alles in een prachtige architectuur te gieten en elke regel code aandachtig getest te hebben op functionaliteit en efficiëntie.

Maar in de praktijk heb je geen zin/tijd/geld om elk mierenneukerig detail af te gaan. Als je een programma schrijft dat aan massale number-crunching doet is het misschien verstandig om multi-threading serieus te bekijken en implementeren, maar er zijn genoeg programma's die het zonder multi-threading ook wel doen, en waarbij het meer tijd kost om te implementeren dan het uiteindelijk oplevert. Voor die gevallen is zo'n automatische multi-threader wel handig, onder het motto "iets is beter dan niets"; Heeft het toch mooi redelijke multi-threading. En natuurlijk laat een manager je niet maanden lang perfectioneren, als een project al goed genoeg is en die extra optimalisaties niet noodzakelijk zijn. Een programmeur aan het werk kost geld.

De huidige compiler-optimalisaties zijn toch ook niet nutteloos, of een oplossing voor management-druk, omdat je die low-level optimalisaties zelf ook wel expliciet kan uitschrijven? Ja, performance-kritische code wil je liever in assembly schrijven dan dat je het van je compiler laat afhangen, maar automatische optimalisaties zijn toch verdomd handig in alle andere gevallen.

Ik ben trouwens benieuwd welke haken en ogen er aan dit idee zitten, want automatische multi-threading maken lijkt me niet eenvoudig om in het algemeen toe te passen.

[Reactie gewijzigd door bwerg op 4 december 2012 16:13]

Maar multithreading is niet 'lager niveau'. Als multithreading een oplossing voor je probleem is, dan is het al onderdeel van je architectuur. Op een veel 'hoger niveau' dan dat kun je niet komen.

Als multithreading GEEN oplossing voor je probleem is, dan hoef je het ook niet op te nemen in je architectuur. Want dan gaat het toch niks helpen.

Multithreading toepassen is een optimalisatie is een oplossing voor een probleem: hoe benut je de CPU zo maximaal mogelijk.

Dit probleem kun je ook op andere manieren oplossen dan multithreading, maar soms is multithreading het meest optimale. Multithreading levert ook overhead op, het kost tijd een thread te starten, een context switch kost tijd, etc.

Als je dit probleem niet hoeft op te lossen, moet je geen multithreading gebruiken.

Vergeet ook niet dat er andere problemen in je programmagedrag kunnen zijn die multithreading vereisen. Misschien heb je wel een API die de hele uitvoering blokkeert tot ie van een extern apparaat (of remote machine) antwoord krijgt -- handel je dat niet multithreaded af, dan blokkeert je hele programma tot er een zinnig antwoord komt (of er een fout optreedt).

Juist daarvoor gebruik je vaak threads als je allerlei (soms langzame of onbetrouwbare) communicatie af wil handelen buiten de uitvoering van je eigenlijke programma om, en niet wil wachten tot er wat binnenkomt. Dat valt prima asynchroon, met een vlaggetje, semaphore of callback, af te handelen als er weer wat interessants gebeurt.

Het probleem is alleen dat een compiler zoiets niet kan ruiken, en een blocking I/O call zal dus bijvoorbeeld niet op een magische manier worden omgetoverd naar iets wat asynchronous I/O doet. Voor dat soort problemen biedt deze auto-threading compiler dus geen oplossing.

multithreading kan op alle niveaus toegepast owrden. Het is onnozel te denken dat het perse onderdeel van de architectuur moet zijn.

Juist om laag niveau is zijn er tal van processen die goed multithreaded zouden kunnen worden gemaakt. Maar tegelijk vergt dit ook heel erg veel micro-management van de programmeur. Het zou prettig zijn als je dit soort processen automatisch multi-threaded zou kunnen maken.

In tal van ontwikkel omgevingen gebeurt dit al. In Labview kunnen (wanneer je dat aanvinkt) de loops automatisch geinspecteerd worden, en wanneer aan alle voorwaarden is voldaan, multithreaded worden afgehandeld. En dat kan met de kleinste simpelste for-loop gedaan worden. Zoiets is onbegonnen werk voor een programmeur om handmatig te doen, maar is bij uitstek geschikt voor een compiler. (In het geval van Labview is de analyse relatief simpel door het gebruikte data-flow concept)

Nouja, geneuzel... Enigzins rekening houden met concurrency, mutexen en locks is niet onverstandig. Als een compiler iets 'sneaky' multithreaded maakt en je veranderd in jouw optiek iets kleins waardoor je 50% prestatie verliest (absoluut overdreven), moet je oppassen. Programmeren moet je leren.

Mutexen en locks zijn een high-level synchronisatiemechanisme. De CPU kent die niet, ze worden geimplementeerd door meerdere instructies in een library. Een compiler kan slimmere beslissingen nemen en van geval tot geval de goede low-level primitieve instructies kiezen.

Een voorbeeld is de memory fence. Een mutex bevat standaard een "acquire/release" dubbelzijdige fence, maar een compiler kan per geval beoordelen of een enkelzijdige fence genoeg is.

Task of T (Task<T>) en async/await zijn al heel eenvoudige manieren om multithreaded te programmeren in .NET

Deels, er wordt dan zaken beperkt parallel uitgevoerd en zorg je ervoor dat je een thread niet blokkeerd. Als je met events en await commando's werkt in je UI laag dan blijft je UI thread vrij en daardoor je UI responsive. Het is wat anders om bijvoorbeeld complexe berekeningen te verdelen over meerdere core, dan red je het niet alleen met await.

Als je hiermee alleen even opnieuw hoeft te compileren en je programma is iig deels multithreaded dan kan dit nog wel eens populair worden.

als je echt het onderste uit de kan wil hebben zal je er denk toch wat moeite in moeten steken.