Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 62, views: 25.601 •

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)

Reactiefilter:-162058+144+212+30
Fijn dan hoef ik straks niet meer na te denken om multi-threaded te programmeren! 8)7

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]

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.
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.
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.
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.
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.
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.
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.
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.
Dat wordt door de scheduler van je OS geregeld, onafhankelijk of je code nou multithreaded is of niet.
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]

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 :)
Anders geformuleerd: als je wilt dat jouw stukje software de volle kracht kan benutten, moet je het multithreaded geschreven hebben.
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.
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.
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)
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.
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.
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., :)
Mooie techniek !

Hopelijk krijgen we nu ook wat betere ondersteuning in games!
Er zijn helaas te weinig games die dat doen.
Nee, in games zal het hier echt niet beter van worden lijkt me. Multithreading kan best complex zijn om goed te krijgen, dus zo'n automatische oplossing zal geen perfecte oplossing geven. De meeste moderne games hebben toch al wel multithreading, alleen vraag je je soms af of het beter kan. En ik betwijfel dus of dat hiermee lukt. Vaak zal je dat toch handmatig moeten doen.

Of ik moet dit grondig onderschatten, natuurlijk. Ik hoop het. :P
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.
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.
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.
</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.
Multithreading is een tool, net als if..elseif..else en switch tools zijn in de programmeertaal. Ze doen allebei hetzelfde, alleen het ene is wat meer geschikt dan het andere in bepaalde situaties.

Je moet multithreading dus inzetten met een bepaald doel.

Om een doel te hebben moet je van te voren nagedacht hebben over je architectuur. Hoe ga je de threads inzetten, wat zijn de onderlinge afhankelijkheden, waar moet je threads onderling synchroniseren.

En voor elk soort taak zul je dit moeten bepalen. Want geen enkele taak is hetzelfde.

Nou zie ik dat ze het hebben over webservers en mpeg decoders. Typisch applicaties die één specifieke taak heel veel doen. De enige synchronisatie die er mogelijk is, is het regelen van de toegang tot shared resources. Da's niet zo moeiljk en zal een beetje programmeur sowieso al niet verkeerd kunnen doen. Als zeker niet sinds de uitvinding van de 'critical section'.
Beetje kort door de bocht dit.

Een programmeur kan alles compleet verknallen met multithreading, het is juist makkelijker om het vreselijk te doen met grote waarschijnlijkheid op Race-Conditions dan andersom.
Als een compiler dit automatisch goed weet te doen en zelf Race-Conditions van te voren kan aan zien komen is dit een enorme vooruitgang.

Om echt optimaal gebruik te maken van multithreading kan je beter naar een modernere taal overstappen die het vanuit de core ondersteund (zoals Erlang, Go & Haskell) dan gebruik maken van automatische optimalisatie van een compiler.
Je hebt een erg beperkte blik op multithreading... Het gaat in de praktijk om véél meer dan wat jij beschrijft.

Denk bijvoorbeeld een aan een matrix vermenigvuldiging. Als dat een grote matrix betreft, met een beetje ingewikkelde berekening, kan zoiets heel veel tijd kosten. En daar kun je potentieel enorm veel tijdwinst halen door het multithreaded uit te voeren.

Maar daarbij moet je wel kijken in hoeverre de matrix inderdaad op te splitsen is, of dat je alsnog single threaded moet werken. En dan heb je nog een enorme berg micromanagement dat de programmeur moet uitvoeren om dit alles in goede banen te begeleiden.
De analyse, en het programmeren is echter perfect via de compiler te doen!

Dit soort optimalisaties komen momenteel dus ook in talen zaken als Matlab, waar men inviduele mathematische onderdelen multithreaded aan het maken is.

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBTablets

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013