64bit- OS byte, short, int oder long bzw. float oder double?

[OOOverclocker]

Hallo.
Ein 64bit- System adressiert ja immer 64bit, also 8 Speicherzellen auf einmal.
Heißt das in der Konsequenz nicht, dass der Ressourcenverbrauch von byte(8bit), short(16bit), int(32bit) und long(64bit) immer gleich, also immer eine Adresse mit 64bit ist und somit man eigentlich für alles immer gleich long/double nehmen könnte ohne auf einem 64bit System Performanceeinbußen zu bekommen?

 

[XHelp]

Länge der Speicheradresse ist nicht das gleiche wie Länge des Inhaltes. Die Speicheradresse siehst du in Java eh nicht, von daher soll es dir da auch egal was wie wer was wann macht. Aber was du da in Klammern angibst ist eben die Länge des Inhaltes.

 

[OOOverclocker]

Länge der Speicheradresse ist nicht das gleiche wie Länge des Inhaltes. Die Speicheradresse siehst du in Java eh nicht, von daher soll es dir da auch egal was wie wer was wann macht. Aber was du da in Klammern angibst ist eben die Länge des Inhaltes.

Okay,
aber wenn ich in eine 64bit- Adresse einen 8bit großen Inhalt speichere, habe ich doch trotzdem 64bit verbraucht. Da liegt es doch nahe, gleich einen 64bit- Wert an der Adresse zu speichern.

 

[Dekker]

Okay,
aber wenn ich in eine 64bit- Adresse einen 8bit großen Inhalt speichere, habe ich doch trotzdem 64bit verbraucht. Da liegt es doch nahe, gleich einen 64bit- Wert an der Adresse zu speichern.

Nein. Stichwort Speicheroffset. Du kannst 64 Bit auch aufteilen und 16 x 8 Bit reinschreiben. Wie Java das genau intern macht weiß ich nicht, aber so verschwenderisch werden sie nicht mit dem speicher umgehen (zumindest hoffe ich das)...

 

[OOOverclocker]

Du kannst 64 Bit auch aufteilen und 16 x 8 Bit reinschreiben.

Huch, erklär mir mal wie das geht, da würde ich glaube ich viel Geld mit verdienen ;-)

Naja, okay wenn ich also 8x 8bit in eine 64bit Zelle reinschreibe, heißt das ja ich hole den Wert an dieser Speicherzelle raus, weil ich mir gemerkt habe, dass da noch meinetwegen 16bit frei sind, und hänge mir meine 8bit- Zahl hinten dran. Beim lesen hole ich mir wieder den Zelleninhalt, rufe ab, an welcher Stelle mein Wert steht, und splitte den Wert aus dem Zelleninhalt raus.
Ich muss mir also:
1. Merken, dass ich die Zelle in 8 Segmente unterteilt habe
2. Merken, in welchem Segment ich das Byte abgelegt habe.
Das sind 2 Operationen zusätzlich und außerdem noch mehr Speicherverbrauch. Ich bin mir immer noch nicht sicher, ob es nicht wirklich performanter ist, einfach gleich 64bit- Zahlen zu benutzen.

Edit: Nach langer Suche habe ich jetzt selbst eine Antwort gefunden. Demnach stimmt meine Vermutung.

Es lohnt sich normalerwiese nicht, um Speicherplatz zu sparen, byte, short oder float zu verwenden. Man benutzt eigentlich immer int, long und double, weil das schneller ist. Ein 32-Bit-Computer kann nun mal auf 32 Bit (4 Byte) am schnellsten zugreifen, nur Teile davon zu verwenden, verlängert die Zugriffszeit.

 

[XHelp]

Mal angenommen du wohnst in "Bischöflich-Geistlicher-Rat-Josef-Zinnbauer-Straße" (die gibt es wirklich :joke: ). Wäre es sinnvoll zu sagen: "Och, die Adresse ist eh lang, also kann ich mir direkt eine Villa kaufen"?
WIE du die Sachen adressierst hat nichts damit zu tun, WAS bei diesen Adressen ist.

 

[Guest2]

Moin,

verlassen sollte man sich imho auf gar nichts:

3.4 Words
No mention has been made of the storage requirements for values of the various Java Virtual Machine types, only the ranges those values may take. The Java Virtual Machine does not mandate the size of its data types. Instead, the Java Virtual Machine defines an abstract notion of a word that has a platform-specific size. A word is large enough to hold a value of type byte, char, short, int, float, reference, or returnAddress, or to hold a native pointer. Two words are large enough to hold values of the larger types, long and double. Java's runtime data areas are all defined in terms of these abstract words.

A word is usually the size of a pointer on the host platform. On a 32-bit platform, a word is 32 bits, pointers are 32 bits, and longs and doubles naturally take up two words. A naive 64-bit implementation of the Java Virtual Machine may waste half of a word used to store a 32-bit datum, but may also be able to store all of a long or a double in one of the two words allotted to it.

The choice of a specific word size, although platform-specific, is made at the implementation level, not as part of the Java Virtual Machine's design. It is not visible outside the implementation or to code compiled for the Java Virtual Machine.

3.6.1 Local Variables
Each frame (§3.6) contains an array of variables known as its local variables. The length of the local variable array of a frame is determined at compile time and supplied in the binary representation of a class or interface along with the code for the method associated with the frame (§4.7.3).

A single local variable can hold a value of type boolean, byte, char, short, int, float, reference, or returnAddress. A pair of local variables can hold a value of type long or double.

Local variables are addressed by indexing. The index of the first local variable is zero. An integer is be considered to be an index into the local variable array if and only if that integer is between zero and one less than the size of the local variable array.

A value of type long or type double occupies two consecutive local variables. Such a value may only be addressed using the lesser index. For example, a value of type double stored in the local variable array at index n actually occupies the local variables with indices n and n +1; however, the local variable at index n +1 cannot be loaded from. It can be stored into. However, doing so invalidates the contents of local variable n.

The Java virtual machine does not require n to be even. In intuitive terms, values of types double and long need not be 64-bit aligned in the local variables array. Implementors are free to decide the appropriate way to represent such values using the two local variables reserved for the value.

Viele Grüße,
Fancy

 

[Gasd6462]

Implementors are free to decide the appropriate way to represent such values using the two local variables reserved for the value

Lol, also wenn man einen gescheiten Implementierer hat, ist die Größe der Datentypen abhängig von der Wortbreite und wenn man Pech hat muss die CPU dauernd herum rechnen, wo sich jetzt welche Variable in welchem Speicherplatz verkrochen hat :-D.

 

[Gast2]

Es lohnt sich normalerwiese nicht, um Speicherplatz zu sparen, byte, short oder float zu verwenden. Man benutzt eigentlich immer int, long und double, weil das schneller ist. Ein 32-Bit-Computer kann nun mal auf 32 Bit (4 Byte) am schnellsten zugreifen, nur Teile davon zu verwenden, verlängert die Zugriffszeit.

ja klar ... was soll da länger dauern, wenn auf weniger als die maximale Bandbreite zuzugreifen :lol: ... sorry - aber das ist Mist ... es wird immer auf alle 32 Bit zugegriffen - was zuviel ist wird von der CPU einfach weg geschmissen ... mal abgesehen davon rechnet die CPU immer mit der gleichen Bitbreite - egal ob ich 2 Bytes addiere oder 2 Integer

 

[Guest2]

Wenn man in C programmiert, sollte man sich imho schon bewusst sein, das die Speichergröße einzelner Datentypen und insbesondere deren Anordnung im Speicher eben doch Einfluss auf den Gesamtspeicherverbrauch und das Laufzeitverhalten des Programms hat.

Ein scheinbar einfaches

struct Blub
{
    char a;
    short b;
    char c;
};

verhält sich eben komplett anders, als ein scheinbar ähnliches

struct Blub
{
    char a;
    char c;
    short b;
};

Die erste Variante ist dabei entweder langsamer oder größer.

Zum Einstieg z.B.: Data structure alignment


Aber, bei Java liegt soviel zwischen dem, was man tippt und dem, was letztendlich ausgeführt wird, dass man sich imho nicht nach so etwas richten sollte. Imho sollte man immer den Datentyp nehmen, der am besten für das Problem geeignet ist.

Auch die beiden von mir zitierten Stellen, legen nahe das innerhalb der JVM die Datentypen byte, char, short, int und float immer gleich behandelt werden. long und double aber immer zwei "Speicherstellen" belegen, unabhängig, ob diese gebraucht werden (32 Bit System) oder nicht (64Bit System). Was der JIT anschließend daraus macht, ist dabei dann aber noch weniger offensichtlich.

Viele Grüße,
Fancy

 

[Gast2]

Die erste Variante ist dabei entweder langsamer oder größer.

nein ... beide Varianten sind gleich schnell - beides sind 32 Bit ... das Einzige ist - so wie es bei Wikipedia beschreiben ist - das bei einer ungünstigen Ausrichtung 2x 4 Byte gelesen werden müssen ... das passiert aber bei modernen Compilern eben nicht mehr ... die entsprechende Option zur 4-Byte Ausrichtung ist Defaultmäßig aktiviert ... da werden eben entsprechende Dummy Bytes eingefügt um auf 4 zu kommen

char counter;
char sonstiges;
int value;

kann sein das dann im Speicher (bzw. Stack [sofern in einer Methode deklariert]) eine der beiden Varianten auftaucht

1 Byte counter - 1 Byte sonstiges - 2 Bytes nix - 4 Bytes value

oder eben (wohl eher)

4 Bytes value - 1 Byte counter - 1 Byte sonstiges

wenn die Variablen global definiert sind, dann kann es passieren das die Variablen mit anderen gemischt werden

1 Byte counter - 1 Byte sonstiges - 1 Byte irgendwas - 1 Byte nochwas - 4 Bytes value

wir sind aber in Java ... und ... was auch immer die JVM an der Stelle macht - das wird schon entsprechend schnell sein ... selbst bei aktuellen Rechnern kann uns das egal sein ... es ist genügend Speicher vorhanden, so das uns das nicht interessieren braucht ... anders ist es wenn man für einen Mirkoprozessor schreibt - dann ist das schon sehr interessant

 

[Dekker]

1 Byte counter - 1 Byte sonstiges - 2 Bytes nix - 4 Bytes value

oder eben (wohl eher)

4 Bytes value - 1 Byte counter - 1 Byte sonstiges

wenn die Variablen global definiert sind, dann kann es passieren das die Variablen mit anderen gemischt werden

1 Byte counter - 1 Byte sonstiges - 1 Byte irgendwas - 1 Byte nochwas - 4 Bytes value

wir sind aber in Java ... und ... was auch immer die JVM an der Stelle macht - das wird schon entsprechend schnell sein ... selbst bei aktuellen Rechnern kann uns das egal sein ... es ist genügend Speicher vorhanden, so das uns das nicht interessieren braucht ... anders ist es wenn man für einen Mirkoprozessor schreibt - dann ist das schon sehr interessant

Das war das was ich gemeint habe. Auch wenn ich vielleicht in Mathe besser aufgepasst haben sollte. Wie ich auf 16 * 8 = 64 kam werd ich wohl selbst nie verstehen :E

 

[Guest2]

nein ... beide Varianten sind gleich schnell - beides sind 32 Bit ... das Einzige ist - so wie es bei Wikipedia beschreiben ist - das bei einer ungünstigen Ausrichtung 2x 4 Byte gelesen werden müssen ... das passiert aber bei modernen Compilern eben nicht mehr ... die entsprechende Option zur 4-Byte Ausrichtung ist Defaultmäßig aktiviert ... da werden eben entsprechende Dummy Bytes eingefügt um auf 4 zu kommen

Genau und deswegen schrieb ich: "langsamer oder größer". Wenn das padding aktiviert ist, dann ist die Struktur größer, wenn nicht dann ist sie langsamer.

kann sein das dann im Speicher (bzw. Stack [sofern in einer Methode deklariert]) eine der beiden Varianten auftaucht

1 Byte counter - 1 Byte sonstiges - 2 Bytes nix - 4 Bytes value

oder eben (wohl eher)

4 Bytes value - 1 Byte counter - 1 Byte sonstiges

Nein. Bei einem struct verbieten es die einzelnen C/C++ Standards, dass die Reihenfolge geändert wird. Bei einem Methodenaufruf werden die calling conventions eingehalten (sofern die Methode nicht komplett wegoptimiert wird, "inline"). Lediglich bei lokalen "freien" Variablen darf der Compiler eingreifen.

Bei Java verhält sich der Compiler dabei ähnlich, die Reihenfolge von Variablen wird nicht geändert. (Der JIT hingegen kann dies möglicherweise?)

wir sind aber in Java ... und ... was auch immer die JVM an der Stelle macht - das wird schon entsprechend schnell sein ...

Ja, das ist in etwa das, was ich oben meinte als ich schrieb, dass man den Datentyp nehmen sollte, der am besten zum Problem passt.

Viele Grüße,
Fancy

 

[Gast2]

Bei Java verhält sich der Compiler dabei ähnlich, die Reihenfolge von Variablen wird nicht geändert. (Der JIT hingegen kann dies möglicherweise?)

würde hier auf den JIT tippen ... da der JIT "eher weis" auf welcher Hardware er läuft und somit besser optimieren kann (was ja seine Aufgabe ist)