Schleifenvariable ausserhalb der Schleife benutzen

[Delphi-Laie]

Zitat von himitsu:

Wobei der Compiler ja auch intelligent genug sein könnte, um zu erkennen, daß die Variablen nicht gleichzeitig verwendet werden
und würde dann den selben Speicher für Beide gemeinsam nutzen.

Gleichzeitig nicht, aber eine Variable kann sequentiell bzw. zeitversetzt für alles mögliche genutzt werden. Bei Werteüberschneidungen wegen gleichzeitiger Benutzung, die wahrscheinlich zu inkosistentem Verhalten des Compilates führen, erwarte ich von einem Delphi der Generation XE2, daß es das grundsätzlich bemerkt und warnt, sofern das nach der (Un-)Logik des Quelltextes nicht ausgeschlossen werden kann.

Compiler kann man durchaus noch viel intelligenter bauen. So kann z.B. ein Compiler Codeabschnitte bzw. einzelne Befehle, die nicht kausal im Zusammenhang stehen, automatisch parallelisieren, sozusagen bei so etwas wie ein selbständiges "Threadmanagemen" erstellen bzw. durchführen (natürlich mit Compilerschaltern zu-/abschaltbar, abhängig von der Prozessoren- oder Prozessorenkernanzahl, auch die ungefähre Codegröße, die das auslöst usw.). Was man alles in einen solchen Compiler hineinzaubern könnte...! Und daß Delphi dergleichen bis heute nicht bietet....Mit solchen Mosereien hielt ich mich bisher aber bewußt zurück, und daß Delphi das nicht bietet, ist für mich als Hobbyprogrammierer kein echter Nachteil. Und die Sprache Pascal ist ja zum Glück gut les- und strukturierbar, deshalb mag ich (auch) Delphi.

[Luckie]

Zitat von Delphi-Laie:

Compiler kann man durchaus noch viel intelligenter bauen. So kann z.B. ein Compiler Codeabschnitte bzw. einzelne Befehle, die nicht kausal im Zusammenhang stehen, automatisch parallelisieren, sozusagen bei so etwas wie ein selbständiges "Threadmanagemen" erstellen bzw. durchführen

Gibt es solche Compiler schon? Das Problem ist, woher weiß der Compiler, dass keine Abhängigkeiten bestehen? Woher weiß der Compiler dass keine Synchronisation statt findet, denn nur dann geht das. Der Compiler müsste ja die Programm Logik erfassen und erkennen, was der Programmierer will. Und dann wäre es ja nur noch ein kleiner Schritt bis zu: "Computer mach mal." Und hinten kommt das fertige Programm raus.

[Delphi-Laie]

Ob es so etwas wirklich gibt, ist mir nicht bekannt. Allerdings las ich davon in einem - dezent formuliert - nicht mehr ganz taufrischen Sonderheft der Reihe "Spektrum der Wissenschaft", und zwar eines der Reihe "Verständliche Forschung" von 1989(!). Die Konzepte sind also schon jahrzehntealt. Und Hand auf's Herz: Schon beim flüchtigen Überblicken eine Quellcodes kann man oft sicher parallelisierbare und sicher abhängige (und dann sequentiell auszuführende) Befehle und Blöcker erkennen bzw. unterscheiden.

[Medium]

Auto-Threading ist heikel wie sonst was! Hab mich damit mal ne Zeit theoretisch beschäftigt, und die Generalaussage in der meisten Literatur war (grob): Um eine im allgemeinen Fall überhaupt merkbare Beschleunigung zu erreichen, ist die Komplexität und Fehleranfälligkeit des Vorhabens - aus praktischen Gesichtspunkten - zu groß. Die meisten Autoren waren sich einig, dass es in Summe wohl weniger Arbeit machen würde, an den paar Stellen, an denen es hochspezialisiert effektiv einsetzbar wäre, wenn die Programmierer die jeweils angepasste Lösung manuell implementierten.
Das wird vor allem dann nachvollziehbar, wenn man bedenkt, dass gerade für Multithreading so günstiges Streaming (Operationen wie Daten) derart stark mit den verwendeten Strukturen und der Aufgabe verwoben sind, dass ein Compiler im Grunde "verstehen" müsste, was der Programmierer da gerade machen will, um auch semantische Optimierungen vornehmen zu können - sonst wäre der Gewinn im Mittel kaum merkbar, und wirtschaftlich Unsinn. (Theoretisch nach wie vor höchst interessant!)
Da finde ich es auch irgendwie okay, dass ein Entwickler, der Parallelität herstellen will, sich dieser Sache sehr bewusst sein muss. Dadurch ist er quasi gezwungen geeignete Datenstrukturen und Abläufe zu implementieren, und ggf. sogar einen Algorithmus komplett zu reformulieren um die nötigen Eigenschaften herzustellen.

Ergo: Ein einfacher, "dummer" parallelisierender Compiler wäre sicher machbar, der praktische Nutzen im Mittel aber nicht gegeben. Zumal man sich einen Haufen möglicher Fehlerquellen einbrockt, und sei es schon nur das "wackelige" Debuggen in Threads (vor allem anonymen). Ein intelligenter dieser Art wäre so hochkomplex und würde teilweise in die KI gehen, dass der nötige Entwicklungsaufwand den Nutzen im Mittel kaum gerecht würde, bzw. teilweise nichtmals Theorien zu manchen Details der Umsetzung bestehen. Hochparallele DV ist, gerade durch die Öffnung der GPUs für unspeziellen Code vor kurzem, auch erst recht kurz ein in der Breite diskutiertes Thema. Zuvor war das eher den Spezis von Cray und Co überhaupt ein Anliegen, und so viel Theorie gibt's da einfach noch garnicht zu. Schon garnicht in Punkto Auto-Parallelisierung.

Was du so laks in ein paar Worten als "nice-to-have" nennst, ist ein Universum an Theorie und Komplexität

[hoika]

Hallo,

um noch mal zum Thema zu kommen

Mir ist schon bewusst, dass man das nicht macht (Schleifen-Variable ausserhalb benutzen).
Zum Verständnis:
der Compiler verwendet AX/EAX mit jnz,
was sehr effizient ist, daher auch das Rückwärtszählen,
falls die Variable in der Schleife nicht verwendet wird.
AX/EAX ist aber ein sehr oft verwendetes Register,
es wird also mit grosser Wahrscheinlichkeit
sofort für was anderes benutzt und damit ist der Schleifenzähl-Wert futsch.


Heiko

[Bummi]

zu meiner Zeit war das noch CX

[himitsu]

Der Compiler nimmt, hierfür das, wo er meint das sei noch frei und eigne sich gut dafür.

ECX ist zwar oftmals das Counter-Register, aber es ist nicht zwingend vorgeschrieben.
(das Assemblerbefehl LOOP nutzt zwar dieses Register, aber Delphi nutzt das langsame LOOP eh nicht)

Jenachdem was frei ist, nutzt Delphi EAX, ECX, EDX oder doch ein Plätzchen auf'm Stack.
EBX nutzt Delphi eher ungern, da dieses eine besondere Rolle spielt. (hat aber nix mit dem B zu tun )

Und da wo der Variablenwert noch lange der Schleife verfügbar war, wurde entweder dieses Register nicht neu beschrieben oder eben die Stelle auf'm Stack war (zufällig) noch unberührt.

[Delphi-Laie]

Zur Ehrenrettung des Compilers sei gesagt: Eine diesbezügliche (berechtigte!) Warnung gibt der Compiler schon bei Delphi 2.0 aus (die Version 1 kann ich dahingehend nicht prüfen, habe sie nicht installiert), vielleicht war das sogar zu Turbo-Pascal-Zeiten schon implementiert....schnell mal eben Turbo-Pascal 6.0 (nie wieder einen solch schnelle und stabile IDE wahrgenommen) gestartet: Dort gibt es keine solche Warnung, und die Variable hat auch den Wert, der ihr zum Ende der Schleife (also zum Start des letzten Schleifendurchlaufes) mit auf den Weg gegeben wurde.

[himitsu]

Der Grund ist ganz einfach:

OK, wenn man die schleife abbricht, dann hat die Variable diesen letzten Wert, aber wie ist das, wenn die Schleife sich ordentlich beendet?

Hat die dann den letzen Wert
- erst prüfen, dann weiterzählen und danach zurückspringen
- erst prüfen, dann zurückspringen und danach weiterzählen
oder ist sie da schon weiter?
- weiterzähen, prüfen ob noch im Bereich dann verlassen oder zurückspringen

PS: Intern läuft die Variable auch manchmal rückwärts, oder eben aus Optimierungsgründen irgendwie anders.
Sie wird dann innerhalb der Schleife umgerechnet, bei deren Nutzung (falls sie überhaupt genutzt wird).

Aber auchßerhalb der Schleife gibt es diese Umrechnung nicht mehr.



Da nun also die Variable nicht unbedingt den Wert hat, welchen man sich vorstellt, kann man dieses danach einfach nicht nutzen,
bzw. manchmal gibt es diese Variable nicht wirklich lange (im RAM), da die nur kurz in einem CPU-Register drin lag.

Und jetzt auf den blosen Verdacht hin, daß diese irgendwer nachher noch verwenden könnte, schaltet der Compiler hier eben nicht alle Optimierungen ab.
Oder komt gar auf die Idee alle Zählervariablen, nach der Schleife, nochmal auf deren "wirklichen" Wert umzurechnen, was reichlich sinnlos wäre und überall einen nutzlosen Overhad bedeuten würde.



Lösung: Geh zu Emba ins EDN, erstelle einen Antrag (QC), man möge doch bitte statt dieser Fehlermeldung eine Umrechnung der Variable einbauen, bzw. dafür sorgen, daß deren Wert in eine richtige Variable kopiert wird.