Gibt es von TParallel.for auch sowas wie TParallel.ForIn?

[Mokus]

Wunderschönen guten Morgen,

die Frage steht eigentlich schon im Betreff,

kleine, vielleicht blöde frage, aber gibt es die Parralle For Schleife auch schon als For IN ?

wollte eigentlich diese 4 Zeilen Parallel machen ...

Code:

for MyElem in MyList do
begin
  myElem.TutDinge();  
end;

oder muss es wirklich so sein

Code:

TParralel([...], procedure(i:integer)
begin
    List[i].TutDinge()
end; );

[Der schöne Günther]

Ich habe noch nicht einmal geschaut, gehe aber davon aus dass es das nicht gibt. Wenn du etwas parallelisierst, geht es dir um Geschwindigkeit. Das for..in ist im Endeffekt nur Syntax-Zucker und kann nicht schneller sein. Wenn du z.B. durch einen Container von Records iterierst würde es mich nicht wundern wenn der Compiler jedes mal aktiv einen neue Kopie davon anlegt anstatt direkt darauf zu gehen.

[Mokus]

nicht falsch verstehen,
ich habe nie erwartet dass for in schneller ist ...

mir geht es darum, ob es diesen "synatax zucker ( schönes wort ! ) auch in form der Paralelisierung schon exisitert.
Somit würde ich mir das extra merken des Objektes schließlich sparen.
Erhoffe mir dadurch nur lesbarkeit und Vereinfachung der Schreibarbeit.

Performance technisch macht das kein unterschied, das ist mir klar

[himitsu]

Gibt es ein TParallel.For, was kein "i bis n" nimmt, sondern einen Enumerator oder wenigstens eine TList, bzw. ein Array?

Wenn ja, dann kannst du FOR-IN damit nutzen, denn das macht nicht anderes, als nachzugucken, ob es eine Methode DeineKlasse.GetEnumerator gibt und verwendet den.
(für dynamische Arrays in einer etwas obtimierteren Form, mit Index und ohne Enumerator)

[Uwe Raabe]

Das gibt es nicht und das hat auch seinen Grund: Das for..in verwendet einen Iterator, der explizit oder implizit von der zu iterierenden Menge geliefert wird. Iteratoren stellen ein MoveNext und ein GetCurrent zur Verfügung, das innerhalb der Schleife verwendet wird. Die meisten (wenn nicht sogar alle) Iteratoren verwenden einen internen State um diese Funktionalität zu implementieren. Das ist im einfachsten Fall der Index in einem Array, mit dem das GetCurrent realisiert wird und der beim MoveNext erhöht wird. Die Tatsache, daß man die Gesamtanzahl der Iterationen nicht im Voraus kennt, ist auch nicht gerade hilfreich.

Wollte man diese Iteration nun parallelisieren, würde das mit dieser Form des Iterators natürlich nicht gehen. Man müsste also erstmal eine Reihe von Iterationen (genauer Stride * ThreadCount) ausführen und die jeweiligen GetCurrent-Werte zwischenspeichern. Das kann je nach Anwendungsfall schon mal recht aufwändig werden. Das setzt allerdings voraus, daß sich diese Werte wirklich sauber zwischenspeichern lassen. Eine Iteration z.B. über ein DataSet, bei dem der aktuelle Datensatz in der Schleife verändert wird, fällt offensichtlich schon mal als Anwendungsfall heraus - von der fehlenden Multithread-Eignung eines TDataSet ganz zu schweigen.

Es ist schon schwierig genug, eine simple Schleife sauber zu parallelisieren. Kommt dann noch eine womöglich unbekannte Implementation eines Iterators dazu, würde ich vermutlich erstmal die Finger davon lassen.

[Stevie]

Nein, gibt es nicht. Und wenn man sich mal durchliest, was es bei PLINQ alles zu beachten gibt, sieht man, dass das auch keineswegs trivial ist.

[Mavarik]

Dann übergib doch einfach den For-Variable an eine TTask.

[Mokus]

@Uwe Raabe
das ist mal eine ausführliche Antwort, leider hört die sich sogar sehr logisch an ...
Danke dafür !

Es ist nun bei der einfache For schleife, auf Grund von Problemen mit der Connection und die schon erwähnten Probleme mit TDataset ... geblieben ! :<

danke für alle antworten !