Ich würde dir auch noch empfehlen, großere Arbeitspakete zu schnüren. Wenn du jeden Pixel als einzelnes Arbeitspaket in der Parallel.For Schleife laufen lässt, hast du viel Overhead.
Versuch' doch mal, die Parallel-For Schleife über die Zeilen laufen zu lassen und dann im Rumpf die komplette Zeile zu berechnen.

Das macht keinen Unterschied
Das besste waren 5ms schneller, aber das kann auch eine durch das System bedingte Schwankung sein, das war nämlich auch min. genauso oft langsamer.

Den Grund sehe ich in der Arbeitsweise von Parallel.For
Das nimmt sich nämlich die Anzahl Durchläufe und teilt sie gleichmäßig auf die verfügbare Anzahl Threads (default => Anzahl Kerne) auf.
Habe ich 1000x1000 Pixel, dann führt jeder Thread exakt bei mir (4 logische Kerne) 250k Berechnungen durch.
Hab das in einem anderen Thema hier mal getestet, dass so echt gleichzeitige Abläufe möglich sind, zumindest wenn ich mir pro Berechnung einen Zeitstempel und die ThreadId geben lasse. Für jeden Thread bekomme ich dann die exakt gleichen Zeitstempel.

Probelmatisch wird das erst, wenn die Anzahl der Berechnungen sich nicht durch die Anzahl verfügbarer Threads teilen lässt, dann starte Parallel.For nach der Abarbeitung nämlich neue Threads um den Rest abzuarbeiten und das kostet Zeit. Das passiert (zumindest bei mir) aber nicht, da sich die Anzahl Pixel durch 4 teilen lässt.

OlafSt hat folgendes geschrieben :

Blöde Frage: Würde dies hier nicht auch genügen ? ...

Das Ergebnis sieht vieleicht ähnlich aus. Aber das entspräche aber nicht mehr der orginalen Apfelmänchen-Berechnungsvorschrift, da ein Teil der Berechnung schon mit einem geänderten Wert erfolgt.