Forum: PC-Programmierung Zählt die Programgröße mit zum RAM verbrauch?


von Kaj (Gast)


Lesenswert?

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

von Klaus (feelfree)


Lesenswert?

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.

von Nein (Gast)


Lesenswert?

Kaj schrieb:

> Braucht das Programm dann ~1.5MB im RAM?

Nein.

von Christian M. (christian_m280)


Lesenswert?

Klaus schrieb:
> Microcontrollern

Diesmal hat der TO aber ein Forum ausgewählt, und zwar 
"PC-Programmierung" ;)

Gruss Chregu

von Εrnst B. (ernst)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Noch ein Kommentar (Gast)


Lesenswert?

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

von Frank K. (fchk)


Lesenswert?

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
von rbx (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Kernspeicherleiter (Gast)


Lesenswert?

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.

von Daniel A. (daniel-a)


Lesenswert?

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?

von Oliver S. (oliverso)


Lesenswert?

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

von Tilo R. (joey5337) Benutzerseite


Lesenswert?

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.

von rbx (Gast)


Lesenswert?

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.

von Cppbert (Gast)


Lesenswert?

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

von rbx (Gast)


Lesenswert?

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.

von Oliver S. (oliverso)


Lesenswert?

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

von rbx (Gast)


Lesenswert?

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

von Oliver S. (oliverso)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

rbx schrieb:
> oder die
> von Datenträgern genutzt werden können.

Es gibt keinen Code der ohne RAM vom Datenträger genutzt werden kann

von Kugelfischprinzip - blas Dich auf um zu Überleben (Gast)


Lesenswert?

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

von rbx (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

btw: Watcom und Haskell brauchen auch RAM - also poste doch dazu auch 
noch was irrelevantes

von oszi40 (Gast)


Lesenswert?

Wieviel RAM? Jeder Speichertest braucht nur wenige k und schreibt 
alles voll!

von Andras H. (kyrk)


Lesenswert?

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.

von Oliver S. (oliverso)


Lesenswert?

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
Noch kein Account? Hier anmelden.