Fortsætte parallel programmering diskussion, vil jeg bare gerne give en kort introduktion til PLINQ. I løbet af de sidste par år har vi ikke set et stort spring i CPU ur hastighed. Det, vi har set er chipproducenter skabe multi-CPU-chips, og der er ikke en nem måde for udviklere at drage fordel af denne. Et af de områder, der ville have fordel af parallel behandlingen er LINQ. LINQ syntaks er meget let at skrive og forstå, men for større spørgsmålstegn ved hentning er for langsom. Heldigvis i. NET 4.0 tilføjer Microsoft udvidelse metoder til LINQ, så vi kan få adgang til flere kerner.
Lad os tage et kig på syntaks og hastighed forskelle mellem en PLINQ og LINQ forespørgsel. Første er vores LINQ forespørgsel:
_sequentialQuery = fra bi _babies
hvor b.Name.Equals (_userQuery.Name, StringComparison.InvariantCultureIgnoreCase) & &
b.State _userQuery.State & &
b.Year> = YEAR_START & & b.Year <= YEAR_END
OrderBy b.Year
vælge b;
og PLINQ forespørgslen:
_parallelQuery = fra b i _babies.AsParallel (). WithDegreeOfParallelism (numProcs)
hvor b.Name.Equals (_userQuery.Name, StringComparison.InvariantCultureIgnoreCase) & &
b.State _userQuery.State & &
b.Year> = YEAR_START & & b.Year <= YEAR_END
OrderBy b.Year
vælge b;
Så den eneste forskel er at udvide metoden AsParallel (). WithDegreeOfParallelism (numProcs), hvor numProcs er lig med antallet af CPU du ønsker at anvende for denne forespørgsel.
Nu, og ikke alt er rosenrødt. Der er nogle forbehold at bruge PLINQ. Der er nogle overhead, når disse forespørgsler løbe, og for mindre recordsæt den PLINQ version kan være langsommere. Nedenfor er 2 eksempler på dette.
Her er screenshot af kører ovennævnte forespørgsel og vender tilbage 3 millioner registreringer:
Vi ser en stor forbedring med PLINQ. Hvis vi kun tilbage 300 poster dog får vi:
Så vi kan se udgifterne til overhead. Som altid, brug af PLINQ (eller enhver ny teknologi) kræver en masse prøver, der skal sikre, at det er den rigtige metode til det nuværende projekt.
