Speicher Defragmentierung

Übersicht

BlitzMax, BlitzMax NG

Allgemein

	StarGazer Betreff: Speicher Defragmentierung	Di, Feb 10, 2009 18:27 Antworten mit Zitat
Ich habe mal von einem Kollegen gehört, es soll nicht so gut sein, ständig etwas in den Speicher zu legen, und es wieder zu löschen, da dadurch der Speicher fragmentiert wird, und er sich dann irgendwann Defragmentierung muss. Ist das denn in BlitzMax genauso ? Was passiert dann denn mit den Localen innerhalb der Functionen ? Sollte man stattdessen immer Globale benutzen, die man in jedem Aufruf selbst auf 0 setzt ? Und bei Arrays ?, das könnte noch schlimmer sein. Gibt es in BlitzMax eine Möglichkeit schnell einen Mehrdimensionale Arrays zu leeren ohne diesen zu löschen ? In BlitzMax lege ich einfach eine Locale an, dieses wird ja immer gelöscht nach dem verlassen der Function. Code: [AUSKLAPPEN] [EINKLAPPEN] Local map[256,256] Was jedoch nicht so gut wäre wenn es dadurch immer aus dem Speicher gelöscht wird, wegen der besagten Fragmentierung des Speichers. Man kann also eine Globale anlegen Code: [AUSKLAPPEN] [EINKLAPPEN] Global map[256,256] Nur müsste man es dann immer durch eine For-Schleife löschen, was viel Rechenzeit kostet. Code: [AUSKLAPPEN] [EINKLAPPEN] For x = 0 to 255 For y = 0 to 255 Map[x,y] = 0 Next Next Vom Kollegen habe ich gehört, dass es in C / C++ einen Befehl dafür gibt, der schnell einfach einen Speicher leer, er heißt „ memset „ Gibt es in BlitzMax auch so einen Befehl ? denn die For-Schleife ist keine tolle Lösung.

StarGazer

Betreff: Speicher Defragmentierung

Di, Feb 10, 2009 18:27
Antworten mit Zitat

Ich habe mal von einem Kollegen gehört, es soll nicht so gut sein, ständig etwas in den Speicher zu legen, und es wieder zu löschen, da dadurch der Speicher fragmentiert wird, und er sich dann irgendwann Defragmentierung muss.
Ist das denn in BlitzMax genauso ?

Was passiert dann denn mit den Localen innerhalb der Functionen ? Sollte man stattdessen immer Globale benutzen, die man in jedem Aufruf selbst auf 0 setzt ?

Und bei Arrays ?, das könnte noch schlimmer sein.
Gibt es in BlitzMax eine Möglichkeit schnell einen Mehrdimensionale Arrays zu leeren ohne diesen zu löschen ?
In BlitzMax lege ich einfach eine Locale an, dieses wird ja immer gelöscht nach dem verlassen der Function.
Code: [AUSKLAPPEN]

Local map[256,256]

Was jedoch nicht so gut wäre wenn es dadurch immer aus dem Speicher gelöscht wird, wegen der besagten Fragmentierung des Speichers.

Man kann also eine Globale anlegen
Code: [AUSKLAPPEN]

Global map[256,256]

Nur müsste man es dann immer durch eine For-Schleife löschen, was viel Rechenzeit kostet.
Code: [AUSKLAPPEN]

For x = 0 to 255
For y = 0 to 255
Map[x,y] = 0
Next
Next

Vom Kollegen habe ich gehört, dass es in C / C++ einen Befehl dafür gibt, der schnell einfach einen Speicher leer, er heißt „ memset „
Gibt es in BlitzMax auch so einen Befehl ? denn die For-Schleife ist keine tolle Lösung.

	BtbN	Di, Feb 10, 2009 19:00 Antworten mit Zitat
Ich würde mir dadrüber keinerlei gedanken machen. Ich halte diesen Speicher-Fragmentierungs-Kram für eine erfindung der Unternehmen, die Software verkaufen wollen um den Speicher zu defragmentieren. Bei Festplatten macht das auch durchaus sinn, da eine unfragmentierte Datei dort nicht den Kopf zwingt, zu springen, was ein schnelleres auslesen ermöglicht. Hat dein Kollege vermutlich in der ComputerBild oder einem ähnlich informationshaltigen Blättchen gelesen. Im Ram gibt es keinen Schreib/Lese Kopf, und somit dürfte es keine oder nur EXTREM geringe(nicht messbare), änderungen geben. Und MemSet bewegt da garnichts. Es nullt nur den bereits allocierten Speicher. Du kannst auch prinzipiell überhaupt nichts daran machen, wo und wie der Speicher im ram landet. Du sagst nur dem OS, ich hätte gern X byte speicher, und es gibt dir eine Addresse im ram zurück, wo du deine X byte hinpacken kannst. Wo im speicher er das anlegt, kannst du nicht beeinflussen und kann dir auch vollkommen latte sein.

BtbN

Di, Feb 10, 2009 19:00
Antworten mit Zitat

Ich würde mir dadrüber keinerlei gedanken machen. Ich halte diesen Speicher-Fragmentierungs-Kram für eine erfindung der Unternehmen, die Software verkaufen wollen um den Speicher zu defragmentieren.
Bei Festplatten macht das auch durchaus sinn, da eine unfragmentierte Datei dort nicht den Kopf zwingt, zu springen, was ein schnelleres auslesen ermöglicht. Hat dein Kollege vermutlich in der ComputerBild oder einem ähnlich informationshaltigen Blättchen gelesen.
Im Ram gibt es keinen Schreib/Lese Kopf, und somit dürfte es keine oder nur EXTREM geringe(nicht messbare), änderungen geben.
Und MemSet bewegt da garnichts. Es nullt nur den bereits allocierten Speicher.
Du kannst auch prinzipiell überhaupt nichts daran machen, wo und wie der Speicher im ram landet. Du sagst nur dem OS, ich hätte gern X byte speicher, und es gibt dir eine Addresse im ram zurück, wo du deine X byte hinpacken kannst. Wo im speicher er das anlegt, kannst du nicht beeinflussen und kann dir auch vollkommen latte sein.

	Geeecko	Di, Feb 10, 2009 19:14 Antworten mit Zitat
Naja... Variablen haben vorher schon eine (relative-)Adresse im Speicher vom assembler zugewiesen bekommen Glaube ich jedenfals zu wissen xD

Geeecko

Di, Feb 10, 2009 19:14
Antworten mit Zitat

Naja...
Variablen haben vorher schon eine (relative-)Adresse im Speicher vom assembler zugewiesen bekommen Wink

Glaube ich jedenfals zu wissen xD

	BtbN	Di, Feb 10, 2009 22:21 Antworten mit Zitat
Variablen an sich werden auf dem Stack erstellt und existieren nur in ihrem Kontext. Ich denke hier ging es eher um auf dem Heap abgelegte Speicherblöcke.

BtbN

Di, Feb 10, 2009 22:21
Antworten mit Zitat

Variablen an sich werden auf dem Stack erstellt und existieren nur in ihrem Kontext. Ich denke hier ging es eher um auf dem Heap abgelegte Speicherblöcke.

	StarGazer	Di, Feb 10, 2009 23:58 Antworten mit Zitat
Mir ging es allgemein wie man mit der Speicherverwaltung umgehen sollte. Zb haben mein Units nur einen Move wenn sie sich bewegen. Sobald sie wieder stehen bleiben wird dieser gelöscht. Das spart so zwar Speicher, aber da das sehr oft passiert, wird der Speicher laut meinem Kollegen fragmentiert, und irgendwann wird dieser sich dann defragmentieren, was Rechenzeit kosten würde. Auch bei meinem A* Pathing erstelle ich eine LOCALE Map, und nach dem Pathing da sie local ist, wird sie gelöscht. Und daß passiert dann die ganze Zeit, bei sehr vielen Figuren. Daher die Sorge wegen der Fragmentierung. Mein Kumpel meinte daß das nicht so toll ist. Es wäre besser da alles lieber immer im Speicher zu lassen, weil schneller. Daher wollte ich, wo es geht, vielleicht sogar bei Variablen, es irgendwie alles Global halten. In C sollen die Variablen, auch die Localen, alle an eine Feste Speicheradresse angelegt sein, also so daß sie nicht immer gelöscht und woanders neu erstellt werden. Ich habe ja keine Ahnung von C und co, aber ab und zu ergeb sich mal ein Gespräch mit nem Kumpel der C++ codet.

StarGazer

Di, Feb 10, 2009 23:58
Antworten mit Zitat

Mir ging es allgemein wie man mit der Speicherverwaltung umgehen sollte.
Zb haben mein Units nur einen Move wenn sie sich bewegen. Sobald sie wieder stehen bleiben wird dieser gelöscht. Das spart so zwar Speicher, aber da das sehr oft passiert, wird der Speicher laut meinem Kollegen fragmentiert, und irgendwann wird dieser sich dann defragmentieren, was Rechenzeit kosten würde.
Auch bei meinem A* Pathing erstelle ich eine LOCALE Map, und nach dem Pathing da sie local ist, wird sie gelöscht. Und daß passiert dann die ganze Zeit, bei sehr vielen Figuren. Daher die Sorge wegen der Fragmentierung. Mein Kumpel meinte daß das nicht so toll ist. Es wäre besser da alles lieber immer im Speicher zu lassen, weil schneller.
Daher wollte ich, wo es geht, vielleicht sogar bei Variablen, es irgendwie alles Global halten.
In C sollen die Variablen, auch die Localen, alle an eine Feste Speicheradresse angelegt sein, also so daß sie nicht immer gelöscht und woanders neu erstellt werden. Ich habe ja keine Ahnung von C und co, aber ab und zu ergeb sich mal ein Gespräch mit nem Kumpel der C++ codet.

	Xeres Moderator	Mi, Feb 11, 2009 1:07 Antworten mit Zitat
Muss man in C++ nicht sowieso seinen Speicher selber managen wohingegen Bmax den Garbage Collector eingebaut hat? Lauter Globale Variablen zu benutzen wird das Programm eher komplizierter und länger in der Entwicklung halten, als das der positive Effekt der Geschwindigkeitsoptimierung - so es ihn überhaupt gibt - überwiegt. Ohne aussagekräftiges Beispiel halte ich den GC für intelligent genug das selber ordentlich zu managen.
Win10 Prof.(x64)/Ubuntu 16.04\|CPU 4x3Ghz (Intel i5-4590S)\|RAM 8 GB\|GeForce GTX 960 Wie man Fragen richtig stellt \|\| "Es geht nicht" \|\| Video-Tutorial: Sinus & Cosinus THERE IS NO FAIR. THERE IS NO JUSTICE. THERE IS JUST ME. (Death, Discworld)

Xeres

Moderator

Mi, Feb 11, 2009 1:07
Antworten mit Zitat

Muss man in C++ nicht sowieso seinen Speicher selber managen wohingegen Bmax den Garbage Collector eingebaut hat?
Lauter Globale Variablen zu benutzen wird das Programm eher komplizierter und länger in der Entwicklung halten, als das der positive Effekt der Geschwindigkeitsoptimierung - so es ihn überhaupt gibt - überwiegt.
Ohne aussagekräftiges Beispiel halte ich den GC für intelligent genug das selber ordentlich zu managen.

Win10 Prof.(x64)/Ubuntu 16.04|CPU 4x3Ghz (Intel i5-4590S)|RAM 8 GB|GeForce GTX 960
Wie man Fragen richtig stellt || "Es geht nicht" || Video-Tutorial: Sinus & Cosinus
THERE IS NO FAIR. THERE IS NO JUSTICE. THERE IS JUST ME. (Death, Discworld)

	mahe	Mi, Feb 11, 2009 2:41 Antworten mit Zitat
Kommt auf den GC-Algorithmus an. Wenn nur Speicher freigegeben wird, kann es natürlich zu Fragmentierung kommen. Wenn jedoch auch umkopiert wird (Mark-and-Compact oä) bleibt die Fragmentierung völlig aus.
ʇɹǝıdɯnɹɹoʞ ɹnʇɐuƃıs - ǝpoɥʇǝɯ-ɹoɹɹıɯ ɹǝp uı ,ɹoɹɹǝ,

mahe

Mi, Feb 11, 2009 2:41
Antworten mit Zitat

Kommt auf den GC-Algorithmus an.
Wenn nur Speicher freigegeben wird, kann es natürlich zu Fragmentierung kommen.
Wenn jedoch auch umkopiert wird (Mark-and-Compact oä) bleibt die Fragmentierung völlig aus.

ʇɹǝıdɯnɹɹoʞ ɹnʇɐuƃıs - ǝpoɥʇǝɯ-ɹoɹɹıɯ ɹǝp uı ,ɹoɹɹǝ,

	BladeRunner Moderator	Mi, Feb 11, 2009 11:29 Antworten mit Zitat
Ich hab schon reichlich daten im Speicher hin und hergeschoben und bislang noch keine katastrophalen Performancehits unter Bmax gehabt, ich denke also Du kannst davon ausgehen dass der GC von Max da vernünftig genug arbeitet. Überhaupt stellt sich das Problem ja erst dann wenn im gesamten physikalischen RAM keine Stelle mehr sein sollte die groß genug ist um die aktuelle Anforderung zu erfüllen, erst dann müsste ja 'defragmentiert' werden. (IdR. würde dann jedoch ein Programm wenn es nicht extra für diesen Fall gemanaget wird eh einfach abstürzen, da es keinen Speicher mehr allozieren kann). Wir reden hier aber von Anforderungen die sich üblicherweise im Bereich von 4- 20 Byte-Chunks bewegen, und das sollte nicht zum Problem werden. (Auch Listen bestehen ja intern aus Pointern und daher können die auch ohne Probleme fragmentiert im Speicher erstellt werden.) Worauf ich hinaus will: der unoptimierte, mit globalen verstopfte Code würde mir mehr Sorgen machen als dass meine App einmal alle 2 Stunden nen 2-Sekundenhänger haben könnte.
Zu Diensten, Bürger. Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

Mi, Feb 11, 2009 11:29
Antworten mit Zitat

Ich hab schon reichlich daten im Speicher hin und hergeschoben und bislang noch keine katastrophalen Performancehits unter Bmax gehabt, ich denke also Du kannst davon ausgehen dass der GC von Max da vernünftig genug arbeitet. Überhaupt stellt sich das Problem ja erst dann wenn im gesamten physikalischen RAM keine Stelle mehr sein sollte die groß genug ist um die aktuelle Anforderung zu erfüllen, erst dann müsste ja 'defragmentiert' werden. (IdR. würde dann jedoch ein Programm wenn es nicht extra für diesen Fall gemanaget wird eh einfach abstürzen, da es keinen Speicher mehr allozieren kann).
Wir reden hier aber von Anforderungen die sich üblicherweise im Bereich von 4- 20 Byte-Chunks bewegen, und das sollte nicht zum Problem werden. (Auch Listen bestehen ja intern aus Pointern und daher können die auch ohne Probleme fragmentiert im Speicher erstellt werden.)

Worauf ich hinaus will: der unoptimierte, mit globalen verstopfte Code würde mir mehr Sorgen machen als dass meine App einmal alle 2 Stunden nen 2-Sekundenhänger haben könnte.

Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI
Stolzer Gewinner des BAC#48, #52 & #92

	StarGazer	Mi, Feb 11, 2009 16:29 Antworten mit Zitat
mit Globalen meinte ich keine externen sondern Globale innerhalb der Functionen. In BMax gehts das ja, also würde es nicht alzu unordentlich werden, denke ich Und Locale Variablen die bei einem Functionsaufruf erstellt werden, kosten doch auch Zeit ? vielleicht schon daher sie Global innerhalb der Function anlegen ? Auf jedenfall Danke für eure Antworten, daß hat meine Sorge schon etwas verringert jedoch frage ich mich immer noch, ob daß nicht Ärger machen könnte. Bei meinem RTS an dem ich bastel, könnten tausende Figuren in der Welt rumlaufen, die x Functionen aufrufen, Speicher anlegen und wieder löschen ect. Da mache ich mir schon bissen Sorgen. Ich weis zwar noch nicht ob ich tausende darstellen könnte aber in so einem Aufbausimulations RTS ist das oft der Fall. Hoffe bei wird das keine Probeleme verursachen.

StarGazer

Mi, Feb 11, 2009 16:29
Antworten mit Zitat

mit Globalen meinte ich keine externen sondern Globale innerhalb der Functionen. In BMax gehts das ja, also würde es nicht alzu unordentlich werden, denke ich Smile

Und Locale Variablen die bei einem Functionsaufruf erstellt werden, kosten doch auch Zeit ? vielleicht schon daher sie Global innerhalb der Function anlegen ?

Auf jedenfall Danke für eure Antworten, daß hat meine Sorge schon etwas verringert Smile

jedoch frage ich mich immer noch, ob daß nicht Ärger machen könnte. Bei meinem RTS an dem ich bastel, könnten tausende Figuren in der Welt rumlaufen, die x Functionen aufrufen, Speicher anlegen und wieder löschen ect. Da mache ich mir schon bissen Sorgen. Ich weis zwar noch nicht ob ich tausende darstellen könnte Wink

aber in so einem Aufbausimulations RTS ist das oft der Fall. Hoffe bei wird das keine Probeleme verursachen.

	mahe	Mi, Feb 11, 2009 16:41 Antworten mit Zitat
Solange in Deinen Funktionen einfache Variablen sind (nicht mit new angelegt), liegen diese auf dem Stack und der fragmentiert ganz bestimmt nicht. Somit würden hier "globale" Variablen keinen Sinn machen. Zumal Du sie ja doch jedes mal initialisieren müsstest. Brächte also überhaupt keinen Vorteil.
ʇɹǝıdɯnɹɹoʞ ɹnʇɐuƃıs - ǝpoɥʇǝɯ-ɹoɹɹıɯ ɹǝp uı ,ɹoɹɹǝ,

mahe

Mi, Feb 11, 2009 16:41
Antworten mit Zitat

Solange in Deinen Funktionen einfache Variablen sind (nicht mit new angelegt), liegen diese auf dem Stack und der fragmentiert ganz bestimmt nicht. Somit würden hier "globale" Variablen keinen Sinn machen. Zumal Du sie ja doch jedes mal initialisieren müsstest.
Brächte also überhaupt keinen Vorteil.

ʇɹǝıdɯnɹɹoʞ ɹnʇɐuƃıs - ǝpoɥʇǝɯ-ɹoɹɹıɯ ɹǝp uı ,ɹoɹɹǝ,

	Geeecko	Mi, Feb 11, 2009 18:05 Antworten mit Zitat
Wie willst du denn Variablen vom Stack herunter nehmen, die nicht gerade obendrauf liegen, wenn du einen LIFO Stack hast? Im Speicher hast du ja die "Frames" und einen "FramePointer". Die Adressen die vom assembler zugiewesen worden sind, sind dann relativ zum aktuellen Frame.

Geeecko

Mi, Feb 11, 2009 18:05
Antworten mit Zitat

Wie willst du denn Variablen vom Stack herunter nehmen, die nicht gerade obendrauf liegen, wenn du einen LIFO Stack hast?
Im Speicher hast du ja die "Frames" und einen "FramePointer". Die Adressen die vom assembler zugiewesen worden sind, sind dann relativ zum aktuellen Frame.

	Firstdeathmaker	Do, Feb 12, 2009 11:02 Antworten mit Zitat
@ StarGazer: Fragmentierung wird erst wirklich zum Problem, wenn man wirklich dumme Sachen macht, wie z.B. ein Array immer wieder zu löschen und um 1 erhöht neu zu erstellen.
www.illusion-games.de Space War 3 \| Space Race \| Galaxy on Fire \| Razoon Gewinner des BCC #57 User posted image

Firstdeathmaker

Do, Feb 12, 2009 11:02
Antworten mit Zitat

@ StarGazer: Fragmentierung wird erst wirklich zum Problem, wenn man wirklich dumme Sachen macht, wie z.B. ein Array immer wieder zu löschen und um 1 erhöht neu zu erstellen.

www.illusion-games.de
Space War 3 | Space Race | Galaxy on Fire | Razoon
Gewinner des BCC #57 User posted image

	StarGazer	Do, Feb 12, 2009 13:58 Antworten mit Zitat
Danke euch für die Antworten, hat mir auf jedenfall geholfen. Werde meinen Code etwas umschreiben müssen, da ich doch mal NEW benutze und lösche, auch beim Pathing. Ich hoffe das sehr große Locale Arrays [2000,2000] oder mehr, innerhalb von Functionen, keine Probleme machen. Die sind beim Zugrief immer schön leer, müssen also nicht erst gelöscht werden

StarGazer

Do, Feb 12, 2009 13:58
Antworten mit Zitat

Danke euch für die Antworten, hat mir auf jedenfall geholfen.
Werde meinen Code etwas umschreiben müssen, da ich doch mal NEW benutze und lösche, auch beim Pathing.
Ich hoffe das sehr große Locale Arrays [2000,2000] oder mehr, innerhalb von Functionen, keine Probleme machen. Die sind beim Zugrief immer schön leer, müssen also nicht erst gelöscht werden Very Happy

	BtbN	Do, Feb 12, 2009 15:40 Antworten mit Zitat
Es stellt keinerlei Problem dar, New zu benutzen. Es ist nur RAM, der ist in heutigen Systemen eh im absoluten Überfluss und mit einer sau hohen geschwindigkeit verfügbar. Glaub mir, der Flaschenhals bei der geschwindigkeit liegt wo anders.

BtbN

Do, Feb 12, 2009 15:40
Antworten mit Zitat

Es stellt keinerlei Problem dar, New zu benutzen. Es ist nur RAM, der ist in heutigen Systemen eh im absoluten Überfluss und mit einer sau hohen geschwindigkeit verfügbar. Glaub mir, der Flaschenhals bei der geschwindigkeit liegt wo anders.

Übersicht

BlitzMax, BlitzMax NG

Allgemein

Nach Oben

BlitzBasic Portal

Speicher Defragmentierung

Betreff: Speicher Defragmentierung