Ja genau, wenn man das so fix hinschreibt, ist das Primär eine fixe parallele Schleife. Das Problem dabei ist das dieses harmlos scheinende [c](1 to n).par.map(_ * 2)[/c] dazu führt das alle Kerne für ein Problem belegt werden, bei dem von einer nicht sonderlich effizienten Gesamtlösung auszugehen ist. Ein Algorithmus, der das Problem als Ganzes betrachtet, könnte mit Sicherheit Effizienter arbeiten, er würde aber durch solche vermeintlichen Optimierungen behindert.
Bei OpenMP hast Du die Möglichkeit da viel feingranularer einzugreifen. Statt einem [c]#pragma omp parallel for[/c] schreibst Du halt z.B. ein [c]#pragma omp for schedule(guided)[/c]. (Das ist der Punkt auf den Gregorrr bereits hingewiesen hat.)
Ganz bewusst sogar! 
Außerdem ist das doch genau der Punkt, auf den ich die ganze Zeit hinauswill und bei dem ich in diesen Thread eingestiegen bin, nämlich inwieweit funktionale Ansätze bei der Multi-/Manycore - Programmierung förderlich sind:
Einfach "Funktional = gut für Parallelität" ist dann nämlich wirklich zu einfach gemacht. Und schlimmstenfalls kann ein einfaches [c](1 to n).par.map(_ * 2)[/c] irgendwo versteckt auch eine optimierte Lösung hinrichten.
Genau, bei den Möglichkeiten der Compileroptimierung hat reine funktionale Programmierung Vorteile. Den Vorteil erkauft man sich aber entweder über komplizierte Datenstrukturen, die eben doch nicht richtig immutable sind, oder durch blankes Byteschupsen in gigantischem Umfang (Da ging es in Deinem verlinkten Thread ja hauptsächlich drum )
Ja genau. Das Problem ist, das beide Seiten nicht nur Einfluss auf das Gesamtlaufzeitverhalten haben, sondern auch das Laufzeitverhalten der anderen Seite beeinflussen können. Ein System das (zumindest unterstützend hilft) das automatisch zu lösen, dürfte nicht ganz trivial werden.
(Und der Compilerbau ist der einzige Ansatzpunkt, den ich dafür überhaupt sehe.)
Genau. Schwangere wirken nur plakativer als die beiden Formeln der Herrn
Viele Grüße,
Fancy
