BASTA! Tag 3: Parallel Computing: von LINQ nach PLINQ
Marc André Zhou (Logica Deutschland GmbH Co. KG) fängt in dieser Session an mit einer schneller Einführung in die Parallelität. Fast eine Wiederholung der vorigen Session.
PLINQ eignet sich nicht für LINQ to SQL, bzw. nicht für LINQ Provider die Abfragen auf eine externe Datenquelle vornehmen, eignet sich also nur für In-Memory-Daten, bzw. bereits geladene Daten. Das reine LINQ eignet sich dagegen optimal für die Parallelisierung. PLINQ prüft selber, ob es nötig ist eine Abfrage parallel auszuführen oder nicht. Dafür ist ein Query Analysis zuständig. Andersherum ist es unter Umständen auch möglich, PLINQ generell zu zwingen Queries parallel auszuführen.
Interessant wird PLINQ allerdings nur bei LINQ-Abfragen, die mehr tun, bzw. rechenintensiv sind. Es macht keinen Sinn einfache LINQ-Abfragen zu parallelisieren, die Performance wird dann eher abnehmen, da PLINQ selber einiges an Overhead mitbringt. Was man bei PLINQ beachten sollte ist dass, außer bei Queries auf Arrays, die vorhergehende Sortierung verloren geht. Das hängt damit zusammen, das die Verarbeitung des Queries, bzw. die Datensätze auf verschiedene Prozessorkerne verteilt wird und die Datensätze nach der Verarbeitung anders zusammengesetzt werden können. Bei Arrays mit fixen Index-Werten ist das nicht der Fall, da die Datensätze wieder an den ursprünglichen Index zurückgespielt werden können.
Interessant ist der asynchrone Abruf der verarbeiteten Daten. PLINQ kann abfragen (Poll), wo bereits Daten verarbeitet worden sind, diese Einsammeln und weitergeben, obwohl der Query noch nicht komplett verarbeitet worden ist.
