Parallel.ForEach vs Task.Factory.StartNew

Jaka jest różnica między poniższymi fragmentami kodu? Czy oba nie będą używać wątków puli wątków?

Na przykład, jeśli chcę wywołać funkcję dla każdego elementu w kolekcji,

Parallel.ForEach<Item>(items, item => DoSomething(item));

vs

foreach(var item in items)
{
  Task.Factory.StartNew(() => DoSomething(item));
}

Pierwsza jest znacznie lepszą opcją.

Parallel.ForEach, wewnętrznie, używa Partitioner<T>do dystrybucji twojej kolekcji na elementy pracy. Nie wykona jednego zadania na przedmiot, a raczej zgrupuje go, aby obniżyć związane z tym koszty ogólne.

Druga opcja zaplanuje jeden Taskna element w Twojej kolekcji. Chociaż wyniki będą (prawie) takie same, spowoduje to znacznie więcej kosztów ogólnych, niż to konieczne, szczególnie w przypadku dużych kolekcji, i spowoduje, że ogólne czasy działania będą wolniejsze.

FYI - używanym Partycjonerem można sterować za pomocą odpowiednich przeciążeń dla Parallel.ForEach , jeśli jest to pożądane. Aby uzyskać szczegółowe informacje, zobacz Niestandardowe partycjonery w MSDN.

Główną różnicą w czasie wykonywania jest to, że druga będzie działać asynchronicznie. Można to powielić za pomocą Parallel.ForEach, wykonując:

Task.Factory.StartNew( () => Parallel.ForEach<Item>(items, item => DoSomething(item)));

W ten sposób nadal korzystasz z partycjonerów, ale nie blokuj, dopóki operacja nie zostanie zakończona.

Zrobiłem mały eksperyment z użyciem metody „1 000 000 000 (jeden miliard)” razy z „Parallel.For” i jednym z obiektami „Task”.

Zmierzyłem czas procesora i stwierdziłem, że Parallel jest bardziej wydajny. Równolegle. Dzieli twoje zadanie na małe elementy robocze i wykonuje je równolegle na wszystkich rdzeniach w optymalny sposób. Podczas tworzenia wielu obiektów zadań (FYI TPL wewnętrznie będzie korzystała z pulowania wątków) będzie przenosić każde wykonanie każdego zadania, powodując więcej stresu w polu, co jest widoczne z poniższego eksperymentu.

Stworzyłem również małe wideo, które wyjaśnia podstawową licencję TPL, a także pokazuje, jak Parallel.For bardziej efektywnie wykorzystuje Twój rdzeń http://www.youtube.com/watch?v=No7QqSc5cl8 w porównaniu do normalnych zadań i wątków.

Eksperyment 1

Parallel.For(0, 1000000000, x => Method1());

Eksperyment 2

for (int i = 0; i < 1000000000; i++)
{
    Task o = new Task(Method1);
    o.Start();
}

Parallel.ForEach zoptymalizuje (może nawet nie rozpocząć nowych wątków) i zablokuje, dopóki pętla nie zostanie zakończona, a Task.Factory wyraźnie utworzy nową instancję zadania dla każdego elementu i zwróci przed zakończeniem (zadania asynchroniczne). Parallel.Foreach jest znacznie wydajniejszy.

Moim zdaniem najbardziej realistycznym scenariuszem jest sytuacja, w której zadania wymagają dużej operacji. Podejście Shivprasad koncentruje się bardziej na tworzeniu obiektów / alokacji pamięci niż na samym przetwarzaniu. Przeprowadziłem badanie, które wywołało następującą metodę:

public static double SumRootN(int root)
{
    double result = 0;
    for (int i = 1; i < 10000000; i++)
        {
            result += Math.Exp(Math.Log(i) / root);
        }
        return result; 
}

Wykonanie tej metody zajmuje około 0,5 sekundy.

Nazwałem to 200 razy przy użyciu Parallel:

Parallel.For(0, 200, (int i) =>
{
    SumRootN(10);
});

Potem nazwałem to 200 razy staromodnym sposobem:

List<Task> tasks = new List<Task>() ;
for (int i = 0; i < loopCounter; i++)
{
    Task t = new Task(() => SumRootN(10));
    t.Start();
    tasks.Add(t);
}

Task.WaitAll(tasks.ToArray()); 

Pierwszy przypadek ukończono w 26656 ms, drugi w 24478 ms. Powtórzyłem to wiele razy. Za każdym razem drugie podejście jest marginalnie szybsze.