Delen via

De gelijktijdigheidsruntime vergelijken met andere gelijktijdigheidsmodellen

In dit document worden de verschillen beschreven tussen de functies en programmeermodellen van de Gelijktijdigheidsruntime en andere technologieën. Door te begrijpen hoe de voordelen van de Concurrency Runtime zich verhouden tot de voordelen van andere programmeermodellen, kunt u de technologie selecteren die het beste voldoet aan de vereisten van uw toepassingen.

Als u momenteel een ander programmeermodel gebruikt, zoals de Windows-threadgroep of OpenMP, zijn er situaties waarin het geschikt kan zijn om te migreren naar de Gelijktijdigheidsruntime. In het onderwerp Migreren van OpenMP naar de Gelijktijdigheidsruntime wordt bijvoorbeeld beschreven wanneer het geschikt is om te migreren van OpenMP naar de Gelijktijdigheidsruntime. Als u echter tevreden bent over de prestaties van toepassingen en de huidige ondersteuning voor foutopsporing, is migratie niet vereist.

U kunt de functies en productiviteitsvoordelen van de Gelijktijdigheidsruntime gebruiken om uw bestaande toepassing aan te vullen die gebruikmaakt van een ander gelijktijdigheidsmodel. De Gelijktijdigheidsruntime kan geen taakverdeling garanderen wanneer meerdere taakplanners concurreren voor dezelfde rekenresources. Wanneer workloads echter niet overlappen, is dit effect minimaal.

Afdelingen

Het verschil tussen preemptief roosteren en coöperatief roosteren

Het voorlopige model en de coöperatieve planningsmodellen zijn twee veelvoorkomende manieren om meerdere taken in staat te stellen rekenresources te delen, bijvoorbeeld processors of hardwarethreads.

Preventieve en coöperatieve planning

Preemptive scheduling is een op prioriteit gebaseerd round-robin-mechanisme dat elke taak exclusieve toegang geeft tot een rekenresource voor een bepaalde periode en dan overschakelt naar een andere taak. Preemptive scheduling is gebruikelijk in multitasking besturingssystemen zoals Windows. Coöperatieve planning is een mechanisme dat elke taak exclusieve toegang geeft tot een rekenresource totdat de taak is voltooid of totdat de taak de toegang tot de resource krijgt. De Gelijktijdigheidsruntime maakt gebruik van coöperatieve planning samen met de preventieve scheduler van het besturingssysteem om het maximale gebruik van verwerkingsbronnen te bereiken.

Verschillen tussen preëmptieve en coöperatieve planners

Preemptive schedulers willen meerdere threads gelijke toegang geven tot computingresources om ervoor te zorgen dat elke thread voortgang maakt. Op computers met veel rekenresources wordt eerlijke toegang minder problematisch; het efficiënt gebruik van de resources wordt echter problematischer.

Een preemptive kernelmodusplanner vereist dat de toepassingscode afhankelijk is van het besturingssysteem om planningsbeslissingen te nemen. Een medewerkende planner in de gebruikersmodus stelt toepassingscode in staat om eigen planningsbeslissingen te nemen. Omdat met een coöperatieve planning veel planningsbeslissingen kunnen worden genomen door de toepassing, vermindert het veel van de overhead die is gekoppeld aan kernelmodussynchronisatie. Een coöperatief planner stelt doorgaans planningsbeslissingen uit voor de kernel van het besturingssysteem wanneer er geen ander werk te plannen is. Een coöperatieve scheduler verwijst ook naar de besturingssysteemplanner wanneer er een blokkeringsbewerking is die naar de kernel wordt gecommuniceerd, maar die bewerking wordt niet doorgegeven aan de scheduler van de gebruikersmodus.

Coöperatieve planning en efficiëntie

Voor een preemptive scheduler is al het werk met hetzelfde prioriteitsniveau gelijk. Een preemptieve scheduler plant meestal threads volgens de volgorde waarin ze zijn aangemaakt. Bovendien geeft een preëmptieve scheduler elke thread een tijdssegment op een roulerende manier, op basis van de prioriteit van de thread. Hoewel dit mechanisme redelijkheid biedt (elke thread vooruitgaat), komt dit ten koste van de efficiëntie. Veel rekenintensieve algoritmen vereisen bijvoorbeeld geen eerlijkheid. In plaats daarvan is het belangrijk dat gerelateerde taken in de minst algemene tijd worden voltooid. Met coöperatieve planning kan een toepassing efficiënter werk plannen. Denk bijvoorbeeld aan een toepassing met veel threads. Het plannen van threads die geen resources delen om gelijktijdig te worden uitgevoerd, kan de overhead voor synchronisatie verminderen en zo de efficiëntie verhogen. Een andere efficiënte manier om taken te plannen, is het uitvoeren van pijplijnen van taken (waarbij elke taak op de uitvoer van de vorige taak werkt) op dezelfde processor, zodat de invoer van elke pijplijnfase al in de geheugencache wordt geladen.

Het gebruik van Preemptive en Cooperative Scheduling samen

Coöperatieve planning lost niet alle planningsproblemen op. Zo kunnen taken die niet redelijk opleveren voor andere taken alle beschikbare rekenresources verbruiken en voorkomen dat andere taken vooruitgang boeken. De Gelijktijdigheidsruntime maakt gebruik van de efficiëntievoordelen van coöperatieve planning om de eerlijkheidsgaranties van preemptieve planning aan te vullen. De Gelijktijdigheidsruntime biedt standaard een coöperatieve scheduler die gebruikmaakt van een algoritme voor het stelen van werk om werk efficiënt te verdelen over rekenresources. De runtime-scheduler voor gelijktijdigheid is echter ook afhankelijk van de pre-emptieve scheduler van het besturingssysteem om resources eerlijk te verdelen over toepassingen. U kunt ook aangepaste schedulers en schedulerbeleid maken in uw toepassingen om gedetailleerde controle mogelijk te maken over de uitvoering van threads.

[Boven]

De Gelijktijdigheidsruntime vergelijken met de Windows-API

De Microsoft Windows-toepassingsprogrammeerinterface, die doorgaans de Windows-API (en voorheen Win32) wordt genoemd, biedt een programmeermodel waarmee gelijktijdigheid in uw toepassingen mogelijk is. De Gelijktijdigheidsruntime bouwt voort op de Windows-API om extra programmeermodellen te bieden die niet beschikbaar zijn via het onderliggende besturingssysteem.

De Gelijktijdigheidsruntime bouwt voort op het Windows API-threadmodel om parallel werk uit te voeren. Het maakt ook gebruik van het geheugenbeheer van windows-API's en thread-lokale opslagmechanismen. In Windows 7 en Windows Server 2008 R2 wordt windows-API-ondersteuning gebruikt voor door de gebruiker schedulbare threads en computers met meer dan 64 hardwarethreads. De Gelijktijdigheidsruntime breidt het Windows API-model uit door een coöperatieve taakplanner en een werk stelend algoritme te bieden om het gebruik van rekenresources te maximaliseren en door meerdere gelijktijdige scheduler-exemplaren in te schakelen.

Programmeertalen

De Windows-API maakt gebruik van de programmeertaal C om het programmeermodel beschikbaar te maken. Concurrency Runtime biedt een programmeerinterface voor C++ die gebruikmaakt van de nieuwste functies in de C++-taal. Lambda-functies bieden bijvoorbeeld een beknopt, typeveilig mechanisme voor het definiëren van parallelle werkfuncties. Zie Overzicht voor meer informatie over de nieuwste C++-functies die de Gelijktijdigheidsruntime gebruikt.

Threads en thread-pools

Het centrale gelijktijdigheidsmechanisme in de Windows-API is de thread. Doorgaans gebruikt u de functie CreateThread om threads te maken. Hoewel threads relatief eenvoudig te maken en te gebruiken zijn, wijst het besturingssysteem een aanzienlijke hoeveelheid tijd en andere resources toe om ze te beheren. Daarnaast wordt elke thread gegarandeerd dezelfde uitvoeringstijd toegekend als elke andere thread met dezelfde prioriteit, maar de bijbehorende overhead vereist dat u voldoende grote taken maakt. Voor kleinere of meer fijnmazige taken kan de overhead die is gekoppeld aan gelijktijdigheid, opwegen tegen het voordeel van het parallel uitvoeren van de taken.

Threadpools zijn een manier om de kosten van threadbeheer te verlagen. Aangepaste threadpools en de implementatie van de threadpool die wordt geleverd door de Windows-API maken het mogelijk om kleine werkitems efficiënt parallel uit te voeren. De Windows-threadgroep onderhoudt werkitems in een FIFO-wachtrij (first-in, first-out). Elk werkitem wordt gestart in de volgorde waarin het aan de pool is toegevoegd.

De Concurrency Runtime implementeert een work-stealing-algoritme om het FIFO-schema mechanisme uit te breiden. Het algoritme verplaatst taken die nog niet zijn begonnen naar threads die geen werkitems meer hebben. Hoewel het werkdievenalgoritme werkbelastingen kan verdelen, kan het er ook toe leiden dat werkonderdelen opnieuw worden gerangschikt. Dit herschikkingsproces kan ertoe leiden dat een werkitem in een andere volgorde begint dan het is ingediend. Dit is handig met recursieve algoritmen, waarbij er een betere kans is dat gegevens worden gedeeld tussen nieuwere taken dan tussen oudere. Het eerst uitvoeren van de nieuwe items betekent dat er minder cachemissers en mogelijk minder paginafouten zijn.

Vanuit het perspectief van het besturingssysteem is werk stelen oneerlijk. Wanneer een toepassing echter een algoritme of taak implementeert om parallel uit te voeren, maakt redelijkheid tussen de subtaken niet altijd uit. Wat er ook toe doet, is hoe snel de algehele taak is voltooid. Voor andere algoritmen is FIFO de juiste planningsstrategie.

Gedrag op verschillende besturingssystemen

In Windows XP en Windows Vista gedragen toepassingen die gebruikmaken van de Concurrency Runtime zich op dezelfde manier, behalve dat de heap-prestaties op Windows Vista worden verbeterd.

In Windows 7 en Windows Server 2008 R2 biedt het besturingssysteem verdere ondersteuning voor gelijktijdigheid en schaalbaarheid. Deze besturingssystemen ondersteunen bijvoorbeeld computers met meer dan 64 hardwarethreads. Een bestaande toepassing die gebruikmaakt van de Windows-API moet worden gewijzigd om te kunnen profiteren van deze nieuwe functies. Een toepassing die gebruikmaakt van de Gelijktijdigheidsruntime maakt echter automatisch gebruik van deze functies en vereist geen wijzigingen.

base.user-mode_scheduling

[Boven]

Vergelijking van de Concurrency Runtime met OpenMP

De Gelijktijdigheidsruntime maakt verschillende programmeermodellen mogelijk. Deze modellen kunnen de modellen van andere bibliotheken overlappen of aanvullen. In deze sectie wordt de Gelijktijdigheidsruntime vergeleken met OpenMP.

Het OpenMP-programmeermodel wordt gedefinieerd door een open standaard en heeft goed gedefinieerde bindingen met de programmeertalen Fortran en C/C++. OpenMP-versies 2.0 en 2.5 zijn geschikt voor parallelle algoritmen die iteratief zijn; Dat wil gezegd, ze voeren parallelle iteratie uit op een matrix met gegevens. OpenMP is het meest efficiënt wanneer de mate van parallelle uitvoering vooraf wordt bepaald en overeenkomt met de beschikbare resources in het systeem. Het OpenMP-model is een bijzonder goede overeenkomst voor high-performance computing, waarbij zeer grote rekenproblemen worden verdeeld over de verwerkingsresources van één computer. In dit scenario is de hardwareomgeving bekend en kan de ontwikkelaar redelijkerwijs exclusieve toegang tot computerresources verwachten wanneer het algoritme wordt uitgevoerd.

Andere, minder beperkte computeromgevingen zijn mogelijk niet geschikt voor OpenMP. Recursieve problemen (zoals het quicksort-algoritme of het doorzoeken van een gegevensstructuur) zijn bijvoorbeeld moeilijker te implementeren met behulp van OpenMP. De Gelijktijdigheidsruntime vormt een aanvulling op de mogelijkheden van OpenMP door de PPL ( Parallel Patterns Library ) en de Asynchrone agents-bibliotheek te bieden. In tegenstelling tot OpenMP biedt de Gelijktijdigheidsruntime een dynamische scheduler die zich aanpast aan beschikbare resources en de mate van parallelle uitvoering aanpast wanneer workloads veranderen.

Veel van de functies in de Gelijktijdigheidsruntime kunnen worden uitgebreid. U kunt ook bestaande functies combineren om nieuwe functies op te stellen. Omdat OpenMP afhankelijk is van compilerrichtlijnen, kan het niet eenvoudig worden uitgebreid.

Zie Migreren van OpenMP naar de Gelijktijdigheidsruntime voor meer informatie over hoe de Gelijktijdigheidsruntime wordt vergeleken met OpenMP en hoe u bestaande OpenMP-code migreert om de Gelijktijdigheidsruntime te gebruiken.

[Boven]

Zie ook

Gelijktijdigheidsruntime
Overzicht
Bibliotheek met parallelle patronen (PPL)
Bibliotheek met asynchrone agents
OpenMP

  • Last updated on