Schleifenvariable ausserhalb der Schleife benutzen

[Delphi-Laie]

Dank Euch, also wieder etwas hinzugelernt.

Nun, den letzten Wert der Zählschleife entnähme ich ohnehin nicht der Laufvariable nach der Schleife. Die Laufvariable vor oder nach der Zählschleife für irgendetwas anderes einzusetzen (rezyklieren, bei mir wird nichts weggeworfen, "nichts darf umkommen"), bin ich allerdings kein Kind von Traurigkeit, sondern gehe speicherbewußt sparsam mit Variablen um.

Ergänzung:

Zitat:

Zitat von Luckie (Beitrag 1136876)

Nein, nach dem Verlassen der for-Schleife ist der Wert der Zählvariablen unbestimmt, weil sie nach der Schleife weggeschmissen wird. Das sagt dir aber auch der Compiler, wenn du die Warnungen nicht deaktiviert hast.

Luckie, Du meinstest wohl oder sicherlich, er wird weggeworfen, also der Wert der Variablen, nicht sie, die Variable selbst.

[Luckie]

Na ja, OK. Wenn man es genau ausdrückt, der Wert.

Aber ich würde davon abraten, Variablen zu "recyceln". Weil dann entweder keine eindeutige Benennung möglich ist oder die Benennung nicht mehr passt. Beides ist schlechter Code, weil es die Les- und Wartbarkeit verringert. Und sei wir doch mal ehrlich, die paar Byte auf dem Stack zusätzlich machen den Braten auch nicht fett. Da würde ich mir eher andere Stellen im Code zum optimieren vornehmen.

[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.

[Delphi-Laie]

Zitat:

Zitat von himitsu (Beitrag 1136908)

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:

Zitat von Delphi-Laie (Beitrag 1136909)

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 :lol:)

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.