 |
Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
tfv
Anmeldungsdatum: 06.01.2008
Beiträge: 16
|
 Verfasst am: 22.08.2008, 07:47 Titel: Variablen, Speicherbedarf, Stack: Zu wenig Arbeitsspeicher |
 |
|
Ich schreibe an einem Freebasic-Programm mit großen Datenmengen, habe Probleme mit dem Konzept des Arbeitsspeichers.
1.) Wie sehe ich, wie viel Arbeitspeicher von einzelnen Variablen und von allen zusammen verbraucht wird? (?fre bringt irgendwie nichts, weil sich der Speicher dauernd verändert, und compilieren mit unterschiedlichen dim-Größen verändert exe-Größe nicht)
2.) warum kann ich mit -t die Stackgröße nicht bis zu meinem Speicherausbau vergrößern?
Die Situation scheint wie folgt zu sein:
A.) Mit der Compileroption -t (size in byte) kann die Größe des Stacks festgelegt werden, 200.000.000, also 200 MB ist bei mir möglich, danach gibts Abstürze oder Fehlermeldungen, Speicherausbau aber 2 GB und mit ?fre wird 1.5 GB frei angezeigt
B.) Dim scheint Variablen in den Stack zu legen, dim shared irgendwo anders hin (wohin? exe-Größe ändert sich nicht, offensichtlich wird der Speicherplatz erst dynamisch im Programm angelegt, was ja sinnvoll ist)
Bin für alle Tips oder Hinweise auf weiterführende Doku dankbar. |
|
| Nach oben |
|
 |
Elektronix
Anmeldungsdatum: 29.06.2006
Beiträge: 742
|
| Verfasst am: 22.08.2008, 09:11 Titel: Re: Variablen, Speicherbedarf, Stack: Zu wenig Arbeitsspeich |
|
|
| tfv hat Folgendes geschrieben: | Ich schreibe an einem Freebasic-Programm mit großen Datenmengen, habe Probleme mit dem Konzept des Arbeitsspeichers.
1.) Wie sehe ich, wie viel Arbeitspeicher von einzelnen Variablen und von allen zusammen verbraucht wird? (?fre bringt irgendwie nichts, weil sich der Speicher dauernd verändert, und compilieren mit unterschiedlichen dim-Größen verändert exe-Größe nicht)
2.) warum kann ich mit -t die Stackgröße nicht bis zu meinem Speicherausbau vergrößern?
Die Situation scheint wie folgt zu sein:
A.) Mit der Compileroption -t (size in byte) kann die Größe des Stacks festgelegt werden, 200.000.000, also 200 MB ist bei mir möglich, danach gibts Abstürze oder Fehlermeldungen, Speicherausbau aber 2 GB und mit ?fre wird 1.5 GB frei angezeigt
|
Naja, Du muß dem System schon noch Raum für eigene Aufgaben lassen. Schließlich braucht Windows auch noch etwas Platz, und das Programm selbst...200MB sind doch ne Menge.
[Edit]Hab grade Voltas Post gesehen: 200.000.000 sind 200 GB, nicht 200 MB!
| Zitat: |
B.) Dim scheint Variablen in den Stack zu legen, dim shared irgendwo anders hin (wohin? exe-Größe ändert sich nicht, offensichtlich wird der Speicherplatz erst dynamisch im Programm angelegt, was ja sinnvoll ist)
|
Heap?
Daß sich die Exe-Größe nicht ändert, ist doch normal. Darin steht ja nur der Programmtext, die Variablen werden in einem anderen Segment (Datensegment) angelegt. Der Text für eine DIM-Anweisung ist immer gleich lang, egal, ob Du ein Byte oder ein Double dimensionierst. Außerdem wird die Exe-Größe in kb angegeben, einzelne Bytes werden gerundet.
_________________
Und die Grundgebihr is aa scho drin- DOS is jo nett.
Zuletzt bearbeitet von Elektronix am 22.08.2008, 10:11, insgesamt 2-mal bearbeitet |
|
| Nach oben |
|
|
volta
Anmeldungsdatum: 04.05.2005
Beiträge: 1876
Wohnort: D59192
|
| Verfasst am: 22.08.2008, 09:46 Titel: |
|
|
| tfv hat Folgendes geschrieben: | | Compileroption -t (size in byte)... |
??? siehe http://www.freebasic-portal.de/index.php?s=tutorials&id=30&seite=1 | Zitat: | | -t <Wert> Setze Stack-Größe in KByte (Standard: 1MB, z.B. für Stack von 8MB: -t 8192) |
| tfv hat Folgendes geschrieben: | | ...200.000.000, also 200 MB ist bei mir möglich.. |
hat deine Festplatte 200GB frei für die Auslagerungsdatei?
_________________
Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater. |
|
| Nach oben |
|
|
The_Muh
aka Mark Aroni
Anmeldungsdatum: 11.09.2006
Beiträge: 718
|
| Verfasst am: 22.08.2008, 12:13 Titel: Re: Variablen, Speicherbedarf, Stack: Zu wenig Arbeitsspeich |
|
|
| tfv hat Folgendes geschrieben: | Ich schreibe an einem Freebasic-Programm mit großen Datenmengen, habe Probleme mit dem Konzept des Arbeitsspeichers.
|
wie viel daten willst du denn verarbeiten? Mein MuhEdit läft mit 256MiB noch flüssig, theorethisch sind sogar noch größere datenmengen drin, wenn der RAM des computers das Hergibt. ich selbst hab mit bis zu 195MiB text noch flüssig arbeiten können, mehr hab ich mich nicht getraut zu testen, da ich nicht viel ram habe. Außerdem kommt es nartürlich auf die Art der daten an, bei Text z.b. kannst du einfach Arrays nutzen und jede Zeile im Array einzeln lagern. Ich mach bei MuhEdit nix anderes. Bei Bild-daten oder großen Zahlenwerten wird das eventuell schon schwieriger, aber ich glaube nicht das du so große Bilder verarbeiten willst.
_________________
// nicht mehr aktiv // |
|
| Nach oben |
|
|
MisterD
Anmeldungsdatum: 10.09.2004
Beiträge: 3071
Wohnort: bei Darmstadt
|
| Verfasst am: 22.08.2008, 14:38 Titel: |
|
|
warum nicht getraut? hast du noch windows 98?  es gibt sowas wie speicherschutz, dein OS riegelt das programm schon ab wenns mehr fressen will als da ist.
_________________
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra |
|
| Nach oben |
|
|
Mao
Anmeldungsdatum: 25.09.2005
Beiträge: 4409
Wohnort: /dev/hda1
|
| Verfasst am: 22.08.2008, 16:06 Titel: |
|
|
Normal deklarierte Variablen werden i.d.R. auf den Stack gepackt, dynamisch gezogener Speicher wird vom Heap genommen.
Es gibt eigtl. keinen Grund, den benötigten Stack-Speicher zu erhöhen, außer für extreme Rekursion.
_________________
Eine handvoll Glück reicht nie für zwei.
--
 |
|
| Nach oben |
|
|
tfv
Anmeldungsdatum: 06.01.2008
Beiträge: 16
|
| Verfasst am: 22.08.2008, 21:29 Titel: |
|
|
Also erstmal besten Dank an alle für die schnelle Mithilfe.
@Volta
Hast natürlich völlig recht bzgl. 200 GB, dies war allerdings nur ein Tippfehler in meinem Posting, als Compileroption habe ich
-exx -t 200000 eingegeben, also 200 MB, mehr wird mit Fehlermeldung "zu wenig Speicher" abgefangen.
Wie du richtig bemerkt hast, wird der Speicherwert hinter -t in kb und nicht wie von mir behauptet in Byte angegeben.
@MisterD
| Zitat: |
es gibt sowas wie speicherschutz, dein OS riegelt das programm schon ab wenns mehr fressen will als da ist.
|
Da bin ich mir eben nicht ganz so sicher. ich habe ohne array-bound-Verletzungen Programmabstürze, obwohl eigentlich genug Speicher da sein müsste, und mein Verdacht ist im Moment, dass bei der Dimensionierung in fremde Speicherbereiche geschrieben wird und diese dann beim tatsächlichen Überschreiben Abstürze auslösen. Ich weiss natürlich, dass 500 MB Variablenspeicher den Compiler etwas ausreizen (physikalisch hab ich XP und 2 GB RAM)
Die -exx Option habe ich verwendet.
@Mao
| Zitat: |
Normal deklarierte Variablen werden i.d.R. auf den Stack gepackt, dynamisch gezogener Speicher wird vom Heap genommen.
Es gibt eigtl. keinen Grund, den benötigten Stack-Speicher zu erhöhen, außer für extreme Rekursion.
|
Die FBIde-Befehlsreferenz sagt bei der Erklärung der Compileroption -t, dass lokale Arrays auf dem Stack erzeugt werden, und ich verwende sowas wie
dim shared a(100,4,100000) as single oder
dim a(100,4,100000) as single
Dies würde wohl bedeuten, dass dim shared die Variable auf dem Heap speichert und dim (auch im Hauptprogramm, als dort lokale Variable, oder gilt das nur für Subroutinen) auf dem Stack?
Ich hatte in einer früheren Compilerversion mal eine Fehlermeldung der Art "der Speicher langt nicht, Variable besser als shared definieren".
Ist der freie Bereich im Heap (Fragmentierungsprobleme mal beiseite gelassen) das, was ich mit "Print fre" sehe?
Bei Compilieren eines Arrays (nicht shared, sondern normal) mit 100.000.000 Single-Werten geht das Compilieren und der Programmaufruf tierisch schnell, mit ?fre sehe ich aber keine Veränderung im verfügbaren Speicherplatz
In den Stack kann das nicht reinpassen (4 Byte mal 100 Mio Werte wären 400 MB, ich hab aber nur 200 MB stack reserviert).
Wenn ich eine Mrd. Single Werte (bitte nicht lachen) im Array habe, dauert das Compilieren ewig und das asm-File wächst in den GB Bereich an (ich hab nicht gewartet, bis das fertig war), hier wird offensichtlich das asm-File mit dem Speicherplatz auf Platte ausgelagert.
Kernfragen für mich im Moment:
Wie sehe ich die Veränderung des freien Speicherplatzes im Heap durch meine Variablendimensionierung?
Wieviel Heap steht mir im Prozess zur Verfügung, gibts da eine Obergrenze unterhalb des freien Gesamtspeichers, und kann ich diese Obergrenze einstellen?
Vielen Dank für Eure Mithilfe |
|
| Nach oben |
|
|
MisterD
Anmeldungsdatum: 10.09.2004
Beiträge: 3071
Wohnort: bei Darmstadt
|
| Verfasst am: 23.08.2008, 19:00 Titel: |
|
|
| Zitat: |
@MisterD
| Zitat: |
es gibt sowas wie speicherschutz, dein OS riegelt das programm schon ab wenns mehr fressen will als da ist.
|
Da bin ich mir eben nicht ganz so sicher. ich habe ohne array-bound-Verletzungen Programmabstürze, obwohl eigentlich genug Speicher da sein müsste, und mein Verdacht ist im Moment, dass bei der Dimensionierung in fremde Speicherbereiche geschrieben wird und diese dann beim tatsächlichen Überschreiben Abstürze auslösen. Ich weiss natürlich, dass 500 MB Variablenspeicher den Compiler etwas ausreizen (physikalisch hab ich XP und 2 GB RAM)
Die -exx Option habe ich verwendet.
|
dein OS schießt dann das programm ab weils sachen macht dies nicht darf.. dann ist zwar dein programm weg aber was anderes geht davon nicht kaputt.
_________________
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra |
|
| Nach oben |
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
