Wir wissen, dass TPL (also PLINQ too) nicht alle Kerne konsumiert, wenn er diese Aufgabe für einfach hält und sie auf einem einzelnen Kern ausführt. Aber er macht es sogar für eine komplizierte Aufgabe! Zum Beispiel, hier ist Code aus Artikel über Java-Parallelität:
und Ergebnisse:
%Vor% Sie können sehen, dass die Multithread-Version ~ 19 mal schneller ausgeführt wurde als ein einzelner Thread ( Core i7-4702MQ verwendet). Aber in C # Version
Dieser Code hat die schlechteste Leistung im Vergleich zu allen anderen, was aufgrund des TPL-Overheads ohne Leistungsvorteile durch Multithreading nicht überraschend ist.
Also ist die Frage: Warum Java Standard Multithread-Bibliothek ist so weise ( any operation that takes 100us+ will be boosted, see reference Ссылка ), während C # keine Operation verstärken kann, die 1500ms auf meinem Rechner benötigt.
Ich mag C # und nicht wirklich sehr wie Java, deshalb tut es weh und ich will lernen, warum es ist, was es ist ...
Wenn Sie die Aggregate -Methode wie folgt verwenden, wird PLinq die Aggregation sequentiell und daher in einem einzigen Thread ausführen. Natürlich kann die Multiplikation in beliebiger Reihenfolge ausgeführt werden, aber PLinq kann das nicht erraten. Wenn die Operation beispielsweise eine Division war, würde das Ändern der Ausführungsreihenfolge das Endergebnis ändern.
Eine Möglichkeit, PLinq mitzuteilen, dass die Abfrage parallelisiert werden kann, ist die Verwendung einer anderen Aggregat-Überladung, die angibt, wie Ergebnisse aus mehreren Threads zusammengeführt werden können:
%Vor%Bei dieser Version mit n = 100000 dauert es für die sequentielle Version etwa 9000 ms und für die parallele Version 4400 ms. Das ist fast doppelt so schnell, was mit meiner Hardware (Dual-Core-Prozessor) übereinstimmt.
Sie können diesen Artikel lesen, um weitere Informationen zur Funktionsweise von Aggregationen mit PLinq zu erhalten: Ссылка
Tags und Links java .net c# multithreading performance