Hat Pascal Probleme mit der Speicherverwaltung?

[tryunderror]

"Naja, was heißt "besser"?"

Sorry
hatte ich nicht klar gesagt.
Die Frage ist theoretisch gedacht.
In der Praxis würde ich wenn ich Party mache und es kommen 50 Leute
dann lege ich array 1:50 an und leg da records rein. Fertig. Schlampig schnell und egal.
MIch interessiert
wie in die Heapverwaltung eingreifen

a schneller als jetzt
b nie ein Loch weil da passieren dann die Zugriffsfehler
c Automatisch auslagern.

[Warf]

"Naja, was heißt "besser"?"

Sorry
hatte ich nicht klar gesagt.
Die Frage ist theoretisch gedacht.
In der Praxis würde ich wenn ich Party mache und es kommen 50 Leute
dann lege ich array 1:50 an und leg da records rein. Fertig. Schlampig schnell und egal.
MIch interessiert
wie in die Heapverwaltung eingreifen

a schneller als jetzt
b nie ein Loch weil da passieren dann die Zugriffsfehler
c Automatisch auslagern.

Ich habe diesen Beitrag jetzt 3 mal gelesen verstehe beim besten Willen allerdings nicht worauf du hinaus möchtest

[baumina]

Wie und wo genau das Zeugs im Heap liegt kann dir doch egal sein. Du sagst im Programm nur "gib mir Speicher" (mit Create, New, etc.) und "ich geb den Speicher wieder frei" (mit Free / Dispose, etc.). Wie es im Heap im Detail ausschaut ist Sache der Speicherverwaltung des Betriebssystems.

[BeniBela]

hatte ich nicht klar gesagt.
Die Frage ist theoretisch gedacht.
In der Praxis würde ich wenn ich Party mache und es kommen 50 Leute
dann lege ich array 1:50 an und leg da records rein. Fertig. Schlampig schnell und egal.

Mach ich bei kleinen Programmen auch immer so.

Alles in ein großes (dynamisches) Array .

Man kann sogar eine Linked-List so machen. Da verweist man dann statt Pointer durch Arrayindizes.

a schneller als jetzt
b nie ein Loch weil da passieren dann die Zugriffsfehler
c Automatisch auslagern.

Die hardcore Variante ist newinstance und FreeInstance zu überschreiben.

Zum Beispiel:

Code: Alles auswählen

 
type TGlobalObject = class
  i: Integer;
  class function newinstance: tobject; override;
  procedure FreeInstance; override;
end;
 
var dataBlock: array[1..1024] of byte;
 
class function TGlobalObject.newinstance: tobject;
begin
  result := tobject(@dataBlock);
  InitInstance(result);
end;
 
procedure TGlobalObject.FreeInstance;
begin
 
end;         
 

Wenn man das jetzt mit

Code: Alles auswählen

 
var a, b: TGlobalObject;
 
begin
   a := TGlobalObject.Create;
   b := TGlobalObject.Create;
 
   a.i := 10;
   b.i := 20;
   writeln(a.i);     
 

verwendet, dann gibt es 20 aus. Und den Aufruf von free kann man sich sparen.

In C++ ist die Speicherverwaltung eine Katastrophe, da dort verschiedene
Arten der Speicherverwaltung (Heap/Stack) gemischt auftreten. Das gibt dann natürlich schnell
ein Chaos. Wer damit eine Zeitlang leben muss, wird zwangsläufig auf die Idee kommen,
dass man ohne Garbage-Collector nicht leben kann - dabei hätte es eigentlich gereicht wenn man
einfach erst mal die Heap- und Stack-basierten Systeme sauber voneinander getrennt hätte.

C++ hat die beste Speicherverwaltung aller Sprachen (abgesehen vielleicht von den ganz Neuentwicklungen wie Rust)

Da wählt man dann halt beim Verwenden aus, ob man das Objekt auf dem Stack, Heap oder Heap-mit-Ref-Counting haben.

In 90% der Fälle bleibt alles auf dem Stack und dann hat man keinerlei Speicherprobleme. Sonst verwendet man die Variante ref-counting.

In Pascal hat man keine Wahl, und muss die Variante nehmen, die der Klassenautor gewählt hat. Und wenn es dann nicht ref-counted ist, kriegt man Probleme

[tryunderror]

"Naja, was heißt "besser"?"

Sorry
hatte ich nicht klar gesagt.
Die Frage ist theoretisch gedacht.
In der Praxis würde ich wenn ich Party mache und es kommen 50 Leute
dann lege ich array 1:50 an und leg da records rein. Fertig. Schlampig schnell und egal.
MIch interessiert
wie in die Heapverwaltung eingreifen

a schneller als jetzt
b nie ein Loch weil da passieren dann die Zugriffsfehler
c Automatisch auslagern.

Ich habe diesen Beitrag jetzt 3 mal gelesen verstehe beim besten Willen allerdings nicht worauf du hinaus möchtest

a Ich will wissen was der Compiler tut bei nil und dispose und new
b Das will ich optimieren.
c Daten auslagern simuliert unendlichen Speicher.

[tryunderror]

Wie und wo genau das Zeugs im Heap liegt kann dir doch egal sein. Du sagst im Programm nur "gib mir Speicher" (mit Create, New, etc.) und "ich geb den Speicher wieder frei" (mit Free / Dispose, etc.). Wie es im Heap im Detail ausschaut ist Sache der Speicherverwaltung des Betriebssystems.

Ja und nein.
Das wird erst interessant
zb Du hast 1 GB HD
und hast 6 GB Daten rein und davon sind 4 wieder weg. Mit weg meine ich Zwischenergebnisse. Also musst Du 2 GB auf 5 GB verwalten. Bitcoins Abrechungen werden endlos. Und da musst Du den Heap organisieren. Nehmen wir an, Du handelst mit Bitcoins und willst alle Protokolle speichern.

[baumina]

a Ich will wissen was der Compiler tut bei nil und dispose und new
b Das will ich optimieren.
c Daten auslagern simuliert unendlichen Speicher.

- New reserviert dir den Speicher für die Variable und erzeugt einen Zeiger (Pointer), der auf die Variable zeigt.
- Dispose gibt dir den Speicher, den die Variable belegt, wieder frei. Dadurch ist der Pointer ungültig, da er auf eine ungültige Adresse im Speicher zeigt, deswegen wird oft nach Dispose der Pointer auf Nil gesetzt (sichere Programmierung).
- Pointer auf Nil setzen macht mit dem Speicher, den die Variable belegt, gar nichts. Nur zeigt er nicht mehr dorthin, deswegen ist es meist sinnvoll bevor der Pointer auf Nil gesetzt wird, den Speicherplatz durch ein Dispose freizugeben (außer ein anderer Pointer zeigt noch auf den Speicherbereich),

P.S. in die komplexe Speicherverwaltung von Windows einzugreifen ist nicht ratsam.

Übrigens: Ein dynamisches Array (Array of Integer) landet im Heap, ein statisches Array (Array [0..100000] of Integer) dagegen im Stack.

[Warf]

"Naja, was heißt "besser"?"

Sorry
hatte ich nicht klar gesagt.
Die Frage ist theoretisch gedacht.
In der Praxis würde ich wenn ich Party mache und es kommen 50 Leute
dann lege ich array 1:50 an und leg da records rein. Fertig. Schlampig schnell und egal.
MIch interessiert
wie in die Heapverwaltung eingreifen

a schneller als jetzt
b nie ein Loch weil da passieren dann die Zugriffsfehler
c Automatisch auslagern.

Ich habe diesen Beitrag jetzt 3 mal gelesen verstehe beim besten Willen allerdings nicht worauf du hinaus möchtest

a Ich will wissen was der Compiler tut bei nil und dispose und new
b Das will ich optimieren.
c Daten auslagern simuliert unendlichen Speicher.

a: New: Das Programm sagt dem Betriebsystem: Hey gib mir ma x Byte Speicher. Dispose: Das Programm sagt dem Betriebsystem: Den Speicher dort brauche ich nicht mehr.
Wenn du es genau wissen willst, linux z.B. geht beim allokieren nach dem QuickFit Algorithmus vor, und bei dispose wird einfach nur ein Eintrag in der Memory Table gemacht dass dieser Speicherbereich nicht mehr belegt ist
b: Nimm linux und optimiere den Kernel, auch wenn das recht schwer wird, der Linux kernel ist schon ziemlich gut
c: Das nennt sich Paging und das machen Moderne Betriebsysteme (Seit c.a. 1990) selbst. Nur dein Virtueller Adressraum ist durch die Architektur begrenzt (32 Bit: 4GB, 64 Bit 2^64 Byte) und Durch das System (Windows 10 Pro 64 bit max 156 GB, Windows 32 Bit: 2 GB)

Wenn dich so was interessiert leg dir doch mal dieses Buch zu. Das habe ich im rahmen der Betriebsystem Vorlesung der Uni mal angeschaut und ein paar Kapitel gelesen, ist echt gut, war mir aber letztlich zu teuer um es außerhalb der Bibliothek zu lesen.

Darin beschreibt Tanenbaum genau solche Probleme für Betriebsysteme, welche Lösungsansätze es gibt, und welche von den entsprechenden Systemen verwendet werden

[Socke]

Wie und wo genau das Zeugs im Heap liegt kann dir doch egal sein. Du sagst im Programm nur "gib mir Speicher" (mit Create, New, etc.) und "ich geb den Speicher wieder frei" (mit Free / Dispose, etc.). Wie es im Heap im Detail ausschaut ist Sache der Speicherverwaltung des Betriebssystems.

Viele Anforderungen und Freigaben können einer Fragmentierung des Arbeitsspeichers führen. Beispiel: Nach einiger Laufzeit sind von 4 GB wieder 2 GB frei; diese sind aber im Adressraum des Prozesses so verteilt, dass eine Anforderung über ein Array von 500 MB nicht erfüllt werden kann.
Gerade bei speicherhungrigen 32-Bit-Anwendungen (z.B. Spiele, Datenbanken) kann das zu Problemen führen, sofern das Speichermanagement nicht darauf ausgelegt ist. Sofern eine Anwendung in diesem Grenzgebiet arbeitet, wird häufig eine interne Speicherverwaltung zwischen der Anwendung (Objekte, Arrays, New und Dispose) und dem Betriebssystem geschaltet.

Bei 64-Bit-Anwendungen ist ein 64-Bit-Adressraum vorhanden. Damit führt Fragmentierung auf absehbare Zeit nicht mehr zu Problemen.

zb Du hast 1 GB HD
und hast 6 GB Daten rein und davon sind 4 wieder weg. Mit weg meine ich Zwischenergebnisse. Also musst Du 2 GB auf 5 GB verwalten. Bitcoins Abrechungen werden endlos. Und da musst Du den Heap organisieren. Nehmen wir an, Du handelst mit Bitcoins und willst alle Protokolle speichern.

Natürlich kannst du in den Arbeitsspeicher nur so viele Daten hineinladen, wie dort hineinpassen. Wenn du mehr Daten als Arbeitsspeicher hast, musst du diese nacheinander: laden, verarbeiten, ausladen. Das hat weniger mit der Speicherveraltung von Pascal, C oder Java sondern viel mehr mit einer konkreten Anwendung zu tun. Datenbanken haben beispielsweise eigene Softwarekomponenten, die den Speicherbereich für unterschiedliche Teilanwendungen (Cache, Zwischenergebnisse, Änderungslog) verwalten und auf Anfragen bereitstellen.

Wie wäre es mit einem Cache? Alle Anfragen an Daten laufen über diesen Cache; er entscheidet selbsständig, welche Daten im Speicher gehalten werden (alter der Belege, letzte Zugriffszeit, Häufigkeit der Zugriffe etc.) und kann bei Bedarf Arbeitsspeicher frei machen und anderweitig verwenden.

[tryunderror]

"Übrigens: Ein dynamisches Array (Array of Integer) landet im Heap, ein statisches Array (Array [0..100000] of Integer) dagegen im Stack."

Genau
darum geht es.
Aber das kann und will ich manipulieren.
Beispiel.

A array 1:1000 of record pointer auf adresse.
oder
B pointer auf das array




A landet im Stack.
B landet im Heap.

OK?

A und B mit identischen Daten brauchen (fast) denselben Speicherplatz,
nur
mal Heap, mal Stack.
Nun mache ich A
und lösche Element 37 .

Jetzt habe ich ein Loch im Speicherplatz, Feld 37 ist leer.
Aber ich kann es nun verwalten und evt. neu belegen.


Hätte ich gemacht:


Statt Array 1:1000 einen Pointerbaum mit 1000 Knoten, hätte Knoten 37 deleted (dispose)
wäre unkontrollierbar 37 verschwunden.

Anders formuliert: Der Speicher lässt sich auch dynamisch so organisieren, dass es wenig "Löcher" gibt.
ZB der WIN Nutzer macht jede Woche auf HD defrag, das füllt Löcher. (Hat nix mit Pascal zu tun).


Und wie gesagt
wir denken darüber nach.
ABER ich programmier was für mich, da ist mir Heapverwaltung pipegal.

[tryunderror]

Je virtueller der Speicherzugriff wird, umso mehr Bremsklötze hat man im System (-> langsamer ->? schlechter).

Dane für alle Buchtips Thread ist gebrannt und Buchtitel notiert Danke.

Theorie schrieb ich.
Denn ich kann immer zb Platz sparen und Code wird länger.
ZB
Ich baue Compiler.
Das geht mit wenig Code und viel Speicherplatz und viel Rechenzeit.
Oder
ich baue Compiler für dieselbe Sprache mit viel Code und viel Speicherplatz und wenig Rechenzeit.

Oder wenig Space und quick dann langer komplexer Code.

So hier das Thema ist
wie in Pascal Space verwalten.

Und nur als Gedankenspiel
Ich habe ein gb Space
und jeden Tag 10 GB Daten rein und raus
und davon wird auch zb 99 % gelöscht nach check.

Wie gesagt nur gedanklich
denn wenn ich einfach sage
Daten weg Dispose Nil dann habe ich Lücken in meinem gedachten Gigabyte drin.

Und Anmerkung: Im Code sind Daten vom Stack leichter zu finden als im Heap also auch damit,
was wo liegt. Bein Zeiger auf Zeiger ist das nicht so einfach.

[Komoluna]

Je virtueller der Speicherzugriff wird, umso mehr Bremsklötze hat man im System (-> langsamer ->? schlechter).

Dane für alle Buchtips Thread ist gebrannt und Buchtitel notiert Danke.

Theorie schrieb ich.
Denn ich kann immer zb Platz sparen und Code wird länger.
ZB
Ich baue Compiler.
Das geht mit wenig Code und viel Speicherplatz und viel Rechenzeit.
Oder
ich baue Compiler für dieselbe Sprache mit viel Code und viel Speicherplatz und wenig Rechenzeit.

Oder wenig Space und quick dann langer komplexer Code.

So hier das Thema ist
wie in Pascal Space verwalten.

Und nur als Gedankenspiel
Ich habe ein gb Space
und jeden Tag 10 GB Daten rein und raus
und davon wird auch zb 99 % gelöscht nach check.

Wie gesagt nur gedanklich
denn wenn ich einfach sage
Daten weg Dispose Nil dann habe ich Lücken in meinem gedachten Gigabyte drin.

Und Anmerkung: Im Code sind Daten vom Stack leichter zu finden als im Heap also auch damit,
was wo liegt. Bein Zeiger auf Zeiger ist das nicht so einfach.

Erst dachte ich "Google Translator", aber der macht keine Tippfehler...

[BeniBela]

Erst dachte ich "Google Translator", aber der macht keine Tippfehler...

Der lernt, was Leute auf Webseiten schreiben

Wenn das Original Tippfehler hat, werden die manchmal mitübersetzt

[Warf]

Je virtueller der Speicherzugriff wird, umso mehr Bremsklötze hat man im System (-> langsamer ->? schlechter).

Dane für alle Buchtips Thread ist gebrannt und Buchtitel notiert Danke.

Theorie schrieb ich.
Denn ich kann immer zb Platz sparen und Code wird länger.
ZB
Ich baue Compiler.
Das geht mit wenig Code und viel Speicherplatz und viel Rechenzeit.
Oder
ich baue Compiler für dieselbe Sprache mit viel Code und viel Speicherplatz und wenig Rechenzeit.

Oder wenig Space und quick dann langer komplexer Code.

So hier das Thema ist
wie in Pascal Space verwalten.

Und nur als Gedankenspiel
Ich habe ein gb Space
und jeden Tag 10 GB Daten rein und raus
und davon wird auch zb 99 % gelöscht nach check.

Wie gesagt nur gedanklich
denn wenn ich einfach sage
Daten weg Dispose Nil dann habe ich Lücken in meinem gedachten Gigabyte drin.

Und Anmerkung: Im Code sind Daten vom Stack leichter zu finden als im Heap also auch damit,
was wo liegt. Bein Zeiger auf Zeiger ist das nicht so einfach.

Lies dir bitte mal vernünftig was zu Memory Management, Virtueller Speicher und Paging durch, das was du schreibst ergibt einfach keinen Sinn.

Du kannst aus einem Array nicht einfach ein bestimmtes Element Löschen. Und selbst wenn du nur 1 GB speicher hast ist der Virtuelle speicherbereich deines Programmes mindestens 2-3 GB (32 Bit) groß.

Wenn du Speicherlücken erzeugst ist das kein Problem der Programmiersprache, dann hast du als Entwicker einfach ein kaputtes Programm gebaut.

Und Speicherlücken entstehen nur wenn du speicher nicht freigibst. Wenn du speicher freigibst bevor du ihn nicht mehr benötigst bekommst du eine Segfault und das kannst du über eine simple abfrage Assigned unterbinden