Moin, zählt die Größe eines Programms mit zum RAM verbrauch? Angenommen, das Binary (ELF) hat eine größe von 1MB und ich allokiere im Programm 512kB. Braucht das Programm dann ~1.5MB im RAM? Grüße
Kommt drauf an. Ob das Programm direkt aus einem ROM/Flash ausgeführt wird (wie bei den meisten Microcontrollern), oder ob es zunächst ins RAM kopiert werden muss, bevor es dort ausgeführt wird.
Klaus schrieb: > Microcontrollern Diesmal hat der TO aber ein Forum ausgewählt, und zwar "PC-Programmierung" ;) Gruss Chregu
Kaj schrieb: > Braucht das Programm dann ~1.5MB im RAM? Schwieriger wird's, wenn dasselbe Programm mehrfach parallel läuft. Dann fällt der Speicherplatz für das Programm-Executable nur einmal an, die dynamische Speicherallokation natürlich mehrfach. Noch schwieriger ist's, wenn .so im Spiel sind. die brauchen auch nur einmal Platz im RAM wenn sie von mehreren Programmen verwendet werden. Als weitere Steigerungsstufe: Sowohl das elf als auch die .so werden per mmap in den Speicher gelegt. d.H. Platz brauchen sie auf der Platte, aber im RAM nur, wenn RAM verfügbar ist... Und um's noch komplizierter zu machen: Die 512kB-Allokation aus deinem Program braucht auch erst RAM, wenn das Programm diese komplett verwendet, also auch mal in den Speicher geschrieben hat. Mein Chrome hat sich z.B. 1.14 TB (ja, über 1000 Gigabyte) Speicher alloziert, verwendet davon aber nur 167 MB. Was eine gute Sache ist, weil soviel RAM habe ich garnicht im PC stecken.
Meiner Meinung nach kann man das NICHT Pauschal sagen. Weil : Jedes Ding ist anders. Das fängt schon damit an, ob das Programm in einer Sandbox läuft oder nicht. Bei einen MC ob + wie viel davon im Ram speichern ist / kopiert wird. Wie viel Variablen fordert das Prg an etc. Ich hab ein Arduino-Prg. geschrieben was obwohl der Compiler sagt es passt wunderbar in einen Nano spinnt, in einen Mega aber 1a läuft. Bei vielen Computers (und die die es sein wollen) gab/gibt es den Befehl MEM(ory) o.ä. worauf ein der Teil sagt, wie sein Speicher ausgelastet ist. Bei Windows findest man das im Task/Prozessmanager unter RES. bez. unter den Prozess in der Liste Prozesse. Aber selbst der Wert ist ungenau, weil er nur die reinen Prg.-Verbrauch anzeigt und NICHT den Framework-Verbrauch, weil der Teil ja "für alle" ist. Also logische Vorgehensweise. Prg. ins Gerät schieben, und dann gucken was noch an Speicher übrig ist.
> und ich allokiere im Programm 512k
Die heutigen PC Betriebssysteme benutzen nur RAM, wenn dein Programm den
allokierten Speicher auch beschreibt. Und wenn das RAM nicht ausreicht,
kann das BS die Daten aus dem RAM auf die Swap-Platte verschieben.
Ähnliches beim Programmcode. Wenn Code nur im Programm eingebunden ist,
aber nicht benutzt wird, lädt das BS den Code erst gar nicht ins RAM.
Kaj schrieb: > zählt die Größe eines Programms mit zum RAM verbrauch? > Angenommen, das Binary (ELF) hat eine größe von 1MB und ich allokiere im > Programm 512kB. Braucht das Programm dann ~1.5MB im RAM? ELF enthält verschiedene Abschnitte, z.B.: - Programmcode (bleibt normalerweise im virtuellen Speicher) - Relokationsinfos (bleiben nicht im Speicher) - initialisierte Daten (bleiben im virtuellen Speicher) - uninitialisierte Daten (belegen keinen Platz im ELF-File, aber im Speicher) - Stack (belegt keinen Platz im ELF-File, aber im Speicher) - Debuginformationen (werden nicht in den Speicher geladen) Schon alleine aus dieser Aufzählung ist klar, dass man von der Größe einer ELF-Datei nicht auf die Größe im virtuellen Speicher schließen kann, selbst wenn man von einem statisch gelinkten Binary ohne shared objects und ohne malloc() etc ausgeht. Du kannst aus dem ELF per objcopy ein BIN machen. Das kommt dann der Sache schon näher. fchk
:
Bearbeitet durch User
Kaj schrieb: > zählt die Größe eines Programms mit zum RAM verbrauch? Kommt auf das Programm an. Es gibt Programme, die laufen direkt im RAM. Oder es gibt auch Linuxe, die man (ab Distro-Werk) komplett ins RAM booten kann. Da laufen dann alle Programme im RAM. Andere Programme teilen sich in mehrere Funktionen auf, wo dann im Extremfall nur die einzelnen Funktionen (+ dazugehörende LinkLibs) im RAM ablaufen. Hinweise darauf, dass die Thematik nicht so ganz trivial ist, geben unter anderem Seiten zu RAM-Disks: https://de.wikipedia.org/wiki/RAM-Disk oder eben Linux ins Ram booten: https://wiki.ubuntuusers.de/Archiv/System_vom_RAM_booten/ https://unix.stackexchange.com/questions/191296/is-there-a-linux-os-that-can-be-loaded-entirely-into-ram http://reboot.pro/topic/14547-linux-load-your-root-partition-to-ram-and-boot-it/ oder Speicherverwaltung bei Betriebssystemen: https://de.wikipedia.org/wiki/Speicherverwaltung Generell wird mehr Speicher empfohlen, um die Arbeitsgeschwindigkeit des Programms zu steigern. - Umgekehrt kann man sich beim Programmieren Mühe geben, ein "kleineres" bzw. "sparsameres" Programm hinzubekommen. Mit Know How und Austausch funktioniert das ganz gut.
hihi. Ich habe zu Win-XP Zeiten mal eine kleine Software geschrieben die hat 35 K an Festplattenspeicher gekostet. Die Run-Time und spezial DLL's und das Zusatzmodul hat alles in allen ca. 1.8 GB auf die Platte geschaufelt. Bevor einer Fragt. Es war ein Spezial-Abfrage-Programm für eine AS-400 welches von einen Win-XP Rechner aus auf die AS-400 direkt zugegriffen hat. So viel zum Thema "Speicherverbrauch". Ich habe bis heute noch keine Ahnung was die Software an RAM-Speicher gebraucht hat. Ich halte es was PC's und CO. angeht, für ein "normal Sterblichen" fast unmöglich herauszufinden was seine Software an Speicher verbraucht. Dazu sind einfach viel zu viel Verknüpfungen etc. vorhanden. Denn wenn man richtig rechnet muss man auch die DLL's und das Grafik-Interface und die ganzen Treiber (Tastatur maus etc) dazu rechnen. Wieso : Ganz einfach. Wenn ich ein Display (i2c 1602) an einen Arduino anklemme und nutzen will, muss ich die passende Libs dazu Kompilieren und die mit in den Arduino schieben. Ergo wenn man gleiches mit gleichen vergleichen will ist meine Rechnung oben richtig. Und auch die Aussage das es bei gewissen Systemen fast unmöglich ist, diese Frage zu beantworten. Und dank "künstlichen RAM" = Auslagerungsdatei ist RAM in fast unbegrenzter Menge zu Verfügung. Leider zu Gunsten der Geschwindigkeit. Weshalb mein RECHNER 32 GB RAM hat und eine FIXE Auslagerungsdatei von 1 GB. Witzigerweise wird das OS bedeutend langsamer wenn man die Auslagerungsdatei abschaltet. Was mit erklärt wieso Ram-Verwaltung so kompliziert ist. MS Geht hat davon aus, das man eine Auslagerungsdatei IMMER hat.
Noch ein Kommentar schrieb: >> und ich allokiere im Programm 512k > > Die heutigen PC Betriebssysteme benutzen nur RAM, wenn dein Programm den > allokierten Speicher auch beschreibt. Und wenn das RAM nicht ausreicht, > kann das BS die Daten aus dem RAM auf die Swap-Platte verschieben. Bei .NET-Programmen kommt noch dazu, dass diese sich beim Start einen ordentlichen Happen RAM genehmigen, den Speicher aber fast komplett wieder freigeben, falls er anderweitig benötigt wird. Die Angabe im Task-Manager kann diesbezüglich sehr irreführend sein.
Frank K. schrieb: > Relokationsinfos Wie funktioniert das eigentlich, mit ASLR, und memory mapping? Bei einem simplen statisch gelinkten Programm kann man es / das Executable btw. die Datei ja einfach einmal in den Speicher mappen, und dann nimmt es nicht einmal zwangsläufig RAM Speicher ein, wenn man es nicht gerade braucht. Aber mit Linken und ASLR, da muss man ja die Sprungadressen im Code patchen, das sind ja diese Relokationen. Aber würde das Programm wirklich geändert, müssten alle geänderten Programmteile ja im RAM bleiben (oder in den Swap), und mit ASLR wären die ja dann auch nicht mehr bei jeder Instanz gleich, also nochmal Zusatzverbrauch. Das macht man vermutlich nicht wirklich so? Aber wie macht man das wirklich, um das zu verhindern?
rbx schrieb: > Kommt auf das Programm an. Es gibt Programme, die laufen direkt im RAM. Da wir hier im Forum "PC-Programmierung" geht, ist diese Aussage zwar nicht falsch, aber doch irgendwie sinnfrei. Es muß zwar nicht immer das komplette Programm im Ram liegen, aber das, was davon gerade läuft, läuft auf einem PC immer im Ram. Anders geht es gar nicht. Oliver
Daniel A. schrieb: > Frank K. schrieb: >> Relokationsinfos > > Wie funktioniert das eigentlich, mit ASLR, und memory mapping? > > Bei einem simplen statisch gelinkten Programm kann man es / das > Executable btw. die Datei ja einfach einmal in den Speicher mappen, und > dann nimmt es nicht einmal zwangsläufig RAM Speicher ein, wenn man es > nicht gerade braucht. ASLR variiert die Adressen vom Heap, dem Datensegment und den Adressen dynamisch gelinkter Bibliotheken. Der Programmcode an sich wird (so weit ich das verstehe) nicht geändert. > Aber mit Linken und ASLR, da muss man ja die Sprungadressen im Code > patchen, das sind ja diese Relokationen. Aber würde das Programm > wirklich geändert, müssten alle geänderten Programmteile ja im RAM > bleiben (oder in den Swap), und mit ASLR wären die ja dann auch nicht > mehr bei jeder Instanz gleich, also nochmal Zusatzverbrauch. wie gesagt, das Programm wird nicht geändert und die variierten Adressen, z.B. Heap oder gelinkte Bibliotheken, sind ohnehin Instanz-Abhängig. Aber ich bin da kein Profi. Wenn da jemand mit genauen Kenntnissen zu Implementierungen, z.B. auf Windows oder Linux, was sagen könnte wäre das sicher spannend.
Oliver S. schrieb: > Es muß zwar nicht immer das komplette Programm im Ram liegen, aber das, > was davon gerade läuft, läuft auf einem PC immer im Ram. Anders geht es > gar nicht. Das ist jetzt aber auch Quatsch, oder sinnfrei. Ein Programm kann auf dem Prozessor ablaufen, Interrupts triggern, Cache-Speicher nutzen oder eben dies und was (z.B. Zählvariablen) im Speicher ablegen oder aufrufen. Ich habe mir ein kleines Assemblerprogramm auf Diskette vorgestellt, das auch im Hexeditor recht übersichtlich ist. Da ist auch nichts, oder nicht viel mit Parameter mit Stackübergaben hin und zurück. Technisch gesehen landet natürlich das komplette Befehlslisting+Stacksegment im Speicher. Die Frage ist dann: Wer oder was braucht soviel mehr (oder weniger) Speicherplatz außer der Programminternen Speicherreservierung? Völlig untergeht hier die Frage: Code und Daten trennen, oder nicht? Beim DOS Realmode konnten Segmente überlappen. https://en.wikipedia.org/wiki/X86_memory_segmentation https://stackoverflow.com/questions/8728220/how-does-x86-real-mode-segments-overlap-help-memory-saving Betriebsysteme können auch Time-Sharing. https://de.wikipedia.org/wiki/Time-Sharing_(Informatik) Wie gesagt, das ist keine Frage oben, die man mal ebenso verallgemeinern kann. Man sollte in der Lage sein, sich selbst anzusehen, wieviel Speicher ein konkretes Programm auf einer konkreten Hardware mit konkretem Betriebssystem braucht.
rbx schrieb: > Das ist jetzt aber auch Quatsch, oder sinnfrei. Ein Programm kann auf > dem Prozessor ablaufen, Interrupts triggern, Cache-Speicher nutzen oder > eben dies und was (z.B. Zählvariablen) im Speicher ablegen oder > aufrufen. Wie soll auf einem PC ein Programm nicht aus dem RAM laufen, der Prozessor selbst hat keinen Speicher dafuer, der Cache wird darüber nicht genutzt, es ist nur die Frage wie viel einer Applikation nicht in den Speicher geladen werden (Header z.b nicht), oder auch Code über Shared Libraries nachgeladen werden koennen, aber der ausgeführte Code ist im RAM
Cppbert schrieb: > aber der ausgeführte Code > ist im RAM Ja, der Code, aber nicht das "Programm". Es gibt auch noch ROM-Bios Routinen, oder Interrupts oder z.B. andere Teile aus dem Rom oder die von Datenträgern genutzt werden können. Der Code, der eine Bildverarbeitung aufruft, verbraucht nicht viel Ram. Die Prozedur der Abwicklung des Geschehens aber schon.
rbx schrieb: > Ja, der Code, aber nicht das "Programm". Es gibt auch noch ROM-Bios > Routinen, oder Interrupts oder z.B. andere Teile aus dem Rom oder die > von Datenträgern genutzt werden können. Auf einem (nicht museumsreifen) PC? Oliver
Oliver S. schrieb: > Auf einem (nicht museumsreifen) PC? "museumsreif" anfangen hilft aber schon noch. Beispielsweise gibt es beim DOS das PSP - im Hexeditor hat man davon erstmal nichts gesehen. Und dann kam der Protected Mode.. https://resources.infosecinstitute.com/topic/handling-memory-in-protected-mode/ Passt vielleicht auch nicht ganz zur Frage oben, ist aber doch relevant: Alignement. ( https://www.intel.com/content/www/us/en/develop/documentation/cpp-compiler-developer-guide-and-reference/top/compiler-reference/intrinsics/data-align-mem-alloc-intrins-and-inline-asmbly/alignment-support.html ) ( https://developer.apple.com/forums/thread/651200 ) oder sowas hier: https://upx.github.io
rbx schrieb: > Beispielsweise gibt es > beim DOS das PSP Ja, und bei IBM gabs auch mal Lochkarten. Und all diese antike Technik hat mit der Frage des TO überhaupt nichts zu tun. Oliver
rbx schrieb: > "museumsreif" anfangen hilft aber schon noch. Beispielsweise gibt es > beim DOS das PSP - im Hexeditor hat man davon erstmal nichts gesehen. was hat das Program Semgent Prefix mit dem ganzen Post hier zu tun und der Rest-Text von dir ist wieder volle Power Geschwafel ohne jeglichen Bezug zu der Fragestellung - ProtectedMode, Memory-Alignment... blablabla
rbx schrieb: > oder sowas hier: > https://upx.github.io auch wenn gandenlos OT - ein gepacktes Program braucht im Speicher kein einziges Byte weniger als ein ungepacktes - nur auf der Festplatte/Diskette hat das relevanz - hier geht es um RAM-Verbraucht und sonst gar nichts - auch RAM-Disk (auch wenn im RAM liegend) haben mit der Fragestellung exakt 0 zu tun
rbx schrieb: > oder die > von Datenträgern genutzt werden können. Es gibt keinen Code der ohne RAM vom Datenträger genutzt werden kann
Kaj schrieb: > Braucht das Programm dann ~1.5MB im RAM? Mindestens. SharedLibs wären auch noch zu beachten. Und nicht selten buffered der Massenspeicher ein paar sektoren im Cache. Vielleicht rödelt noch ein Virenscanner im Hintergrund, der erst mal ne Kopie der exe serziert. Und windows soll ja neuerdings für Linux (ELF) programme no eigene Runtime-Kapsel/sandbox hochfahren. Also man hat nie genug RAM ...
cppbert schrieb: > und > der Rest-Text von dir Balablablubbediblubb Hilfosigkeitsgeschwätz von cppbert der nicht versteht, dass eine schrittweise Annäherung an das Thema hilfreicher ist als Wasserstrahl Know How von irgendwo her. Letztlich postest du auch nur deswegen - und nicht um etwas um zum besseren Verständnis der Zusammenhänge zu Frage oben beizutragen. Das gleiche ist, wenn man anfängt, mit Übertreibungen zu argumentieren. Das ist ebenfalls Hilflosigkeitsoffenbarung, offtopic, und Netiquette eigentlich auch nicht.
rbx schrieb: > Balablablubbediblubb Hilfosigkeitsgeschwätz von cppbert der nicht > versteht, dass eine schrittweise Annäherung an das Thema hilfreicher ist > als Wasserstrahl Know How von irgendwo her. dann erklär doch einmal was der upx Exe-Packer nur im entferntesten mit RAM-Verbrauch einer Applikation zu tun haben soll wenn es 0 Einfluss hat, oder was Code aus ROM mit RAM zu tun haben soll, welchen Einfluss der ProtectedMode haben soll oder warum Memory-Alignment größenordnungstechnisch irgendeine relevanz haben soll - warum postest du so was dermaßen unrelevantes
btw: Watcom und Haskell brauchen auch RAM - also poste doch dazu auch noch was irrelevantes
Wieviel RAM? Jeder Speichertest braucht nur wenige k und schreibt alles voll!
Kaj schrieb: > Braucht das Programm dann ~1.5MB im RAM? Je nach dem. Mit 0 initialisierte Variablen brauchen keinen extra Platz. int x = 0; Nicht initialisierte Variablen brauchen auch keinen extra Platz. int y; Variablen mit Vordefinierten Werten brauchen extra Platz. int z = -765; Alle Variablen mit Vordefinierten Werten werden in 2 Sections untergebracht. Eins kommt ins RAM, da liegt die Variable dann wirklich. Andere kommt ins ROM, da liegen die Init Werte. Bevor der Main ausgeführt wird, läuft ein Code der aus ROM die Werte ins RAM kopiert. Auf dem PC ist der ROM ja in dein ELF enthalten.
Andras H. schrieb: > Mit 0 initialisierte Variablen brauchen keinen extra Platz. int x = 0; Die liegen dann im virtuellen Null-segment ;) Oliver
Beitrag #7335089 wurde von einem Moderator gelöscht.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.