Generelle Frage zur verwendung von Datentypen

volkard

GreeN19 schrieb:

Beispiel :
Ich nutze ein 64 Bit System und nutze nur int (32Bit) statt long (64 Bit) was macht das für einen unterschied?

Keinen. Also mal von möglichen Überläufen abgesehen. Na, wenns mit 64-bit geht aber mit 32-bit überläuft, wäre ja 32-bit NICHT der passende Datentyp. Darum gehts also nicht.

GreeN19 schrieb:

Die kleinste addressierbare Einheit (Wort) wäre in dem Szenario 64 Bit ,also müssten doch die 32 Bit vom int Typ mit 32 weiteren 0er Bits aufgefüllt werden ,bevor sie im RAM abgespeichert werden können ,oder verstehe ich da etwas falsch?

Nee, sehe ich nicht. Es gibt ja auch die kurzen Registernamen noch und die kurzen Speicher/Lade-Befehle.

GreeN19 schrieb:

Wenn ich richtig liege was macht es dann heute überhaupt noch für einen Sinn bei normalen 32/64 Bit Systemen die Variablengröße immer genau passend zu wählen ?

*Genau* passend ist Unfug.

for(char i=0;i<10;++i) //da muss man doch weinen. 
   cout<<arr[i];

Aber es kann passieren, daß zum Beispiel eine 64-bittige Integer-Division ganz erheblich langsamer ist als eine 32-bittige Integerdivision. Ja, es passiert schon, daß der Modulo-Operator auf signed schneller sein kann als auf unsigned.

GreeN19

Stimmt ,dass das ich nenn es mal "auffüllen" eines Typs der zu klein ist selbst nochmal Performance kostet da hatte ich garnicht dran gedacht sprich es ist sogar genau das Gegenteil der Fall und zu klein gewählte Variablen verursachen selbst nochmal Rechenaufwand ,weil sie mit Nullen aufgefüllt werden müssen.

@volkard

Woran genau sollte ich sparen ,wenn ich sehr viele Daten auf einmal abspeichern möchte ?
An der größe der Variablen selbst zu sparen würde ja ,wenn ich Mr.Long richtig verstehe keinen Sinn machen ,weil diese ohnehin mit Nullen "aufgefüllt" werden muss ,wenn sie zu klein für die Wortbreite der CPU ist ,oder ist mit "maskieren" etwas anderes als auffüllen gemeint?

Und was genau meinst du mit "der Kanal klemmt. " ?

SeppJ

GreeN19 schrieb:

Woran genau sollte ich sparen ,wenn ich sehr viele Daten auf einmal abspeichern möchte ?
An der größe der Variablen selbst zu sparen würde ja ,wenn ich Mr.Long richtig verstehe keinen Sinn machen ,weil diese ohnehin mit Nullen "aufgefüllt" werden muss ,wenn sie zu klein für die Wortbreite der CPU ist ,oder ist mit "maskieren" etwas anderes als auffüllen gemeint?

Dieses Maskieren geschieht nur, wenn mit den Daten gerechnet wird. Wenn die Daten im eigentlichen Arbeitsspeicher des Computers liegen, haben sie schon die Größe, die du angibst (Hinweis: Das ist nicht immer unbedingt die Größe, die man als Laie erwarten würde). Angenommen, du speicherst lauter 16-Bit Worte und der Prozessor ist ein 32-Bit Prozessor, dann kann der auch (bei den üblichen Bauweisen) nur mit 32 Bits gleichzeitig umgehen. Wenn er dann ein bestimmtes 16-Bit Wort aus dem Speicher verarbeiten will, dann bekommt er das gewünschte Wort plus eines, das nebenan steht. Dann muss er den unerwünschten Teil verdecken und eventuell noch den gewünschten Teil passend zurecht rücken. Sehr aufwendig und daher langsam. (Andererseits kann ein clever geschriebenes Programm möglicherweise auch zwei solcher Worte gleichzeitig verarbeiten. Es ist also nicht unbedingt festgeschrieben, dass das langsam sein muss, es kann auch leicht doppelt so schnell werden, wenn man sich gut auskennt)

volkard

GreeN19 schrieb:

Woran genau sollte ich sparen ,wenn ich sehr viele Daten auf einmal abspeichern möchte ?

Zuerstmal am Leerzeichen vor Satzzeichen. Danach kommt aber dann doch eins.

GreeN19 schrieb:

An der größe der Variablen selbst zu sparen würde ja ,wenn ich Mr.Long richtig verstehe keinen Sinn machen ,weil diese ohnehin mit Nullen "aufgefüllt" werden muss ,wenn sie zu klein für die Wortbreite der CPU ist ,oder ist mit "maskieren" etwas anderes als auffüllen gemeint?

Weiß nicht, was MrLong damit meint. Ich kann doch mit so Sachen wie [DWORD PTR] bestimmen, wo der Prozessor (ohne Zeitverlust) maskiert.

GreeN19 schrieb:

Und was genau meinst du mit "der Kanal klemmt. " ?

float und double sind gleich schnell, weil der Prozessor intern eh lang rechet (sogar mit 80 bit).
Sagen wir mal, der Prozessor ist schnell, die Grafikkarte ist schnell, nur der PCI-Bus kann nicht pro Frame 750Mio doubles übertragen. Er packts einfach nicht so viele Daten zu schaufeln, so viele Megabyte pro Sekunde. Also schickt man float, rechnet vielleicht deswegen schon nur mit float.
Oder beim Schicken über Netzwerk oder beim Schreiben auf die Platte (schlimmer noch beim Einlesen), es kann sein, daß man da an Bandbreite sparen will und deswegen einen kleinen Typ nimmt, vielleicht sogar einen soo kleinen, daß er langsamer verarbeitet wird.

struct Datum{
   int jahr;
   int monat;
   int tag;
}//12Byte

Das ist ok.

struct Datum{
   short jahr;
   char monat;
   char tag;
}//4Byte

Auch kein Fehler. Kann dreimal so schnell von der Platte geladen werden. Aber vor allem kann bei vielen Datensätzen davon der Prozessorcache mehr cachen. Oder die Auslagerungsdatei später erst benötigt werden, bei sehr sehr vielen Datensätzen, wenns RAM ausgeht).
An der Verarbeitungszeit sonst sehe ich kein Problem. Außer vielleicht am Rande die vage Andeutung, daß die Universalregister mit kurzen Namen bevorzugt würden und evtl der Registerdruck ein wenig steigt. (Für x86 oder x64 wohlgemerkt, also PCs. Microcontroller zum Beispiel könnten andere Regeln haben.)

struct Datum{
   unsigned jahr:15;
   unsigned monat:4;
   unsigned tag:5;
}//3Byte, Quatsch

Das riecht richtig lahm! Da muss der Compiler immer shift-Befehle einbauen und maskieren. Nuja, wenns zur Übertragung per ISDN wäre, warum nicht so übertragen, aber als 4-Byte-Struktur im Speicher halten?

(short nahm ich mit 16 bit an, eigentlich gibts, um so Annahmen nicht machen zu müssen, Typen wie int16_t im c++-standard.)

Kellerautomat

Halte ich alles fuer Bullshit. Man kann oft viel mehr sparen, wenn man anstatt das Layout zu aendern, mit den Werten etwas trickst. Z.B. kann man alle Daten implizit auf ein Bezugsdatum in der Vergangenheit, wie den 1.1.2000 beziehen, wenn man weiss, dass vorherige nie vorkommen werden. Dann braucht man ploetzlich keine 15 Bits mehr fuers Datum sondern kommt mit lediglich 5+ Bits aus, je nachdem wie weit die Daten in der Zukunft liegen sollen. Auf einmal passen Daten dann auch in 2 Byte hinein.

GreeN19

Genial vielen Dank für die Antworten jetzt habe ich es endlich mal richtig verstanden.
Sprich einfach gesagt :
Wenn ich Bandbreite des Busses/Speicher sparen will sollte ich immer nur die kleinst mögliche Variable nehmen wo der Wert reinpasst der rein soll.
Will ich nun aber CPU Rechenpower sparen sollte ich die Variablen möglichst mit der gleichen Größe wie die Wortbreite der CPU wählen ,damit sie nicht erst noch maskiert werden müssen.

Ihr habt natürlich auch schon Lösungen gebracht was man noch verbessern könnte ,aber da selbst dann noch alles als Laie zu entscheiden wo die CPU maskieren soll usw. lasse ich für mich erstmal außen vor da sind die Fehler sonst schon vorprogrammiert und der Zeitaufwand steht für mich momentan in keiner Relation zum Nutzen :).
Ich möchte mir nur einen einigermaßen sauberen Stil angewöhnen und auch verstehen was im Hintergrund passiert.
Also nochmal vielen Dank an alle die hier gepostet haben.

SeppJ

GreeN19 schrieb:

Ich möchte mir nur einen einigermaßen sauberen Stil angewöhnen und auch verstehen was im Hintergrund passiert.

Wie volkard schon subtil andeutete: Lass das Plenken und das Internet hält deinen Stil automatisch für deutlich sauberer

volkard

Kellerautomat schrieb:

Halte ich alles fuer Bullshit. Man kann oft viel mehr sparen, wenn man anstatt das Layout zu aendern, mit den Werten etwas trickst. Z.B. kann man alle Daten implizit auf ein Bezugsdatum in der Vergangenheit, wie den 1.1.2000 beziehen, wenn man weiss, dass vorherige nie vorkommen werden. Dann braucht man ploetzlich keine 15 Bits mehr fuers Datum sondern kommt mit lediglich 5+ Bits aus, je nachdem wie weit die Daten in der Zukunft liegen sollen. Auf einmal passen Daten dann auch in 2 Byte hinein.

Da muss ein Tippfehler irgendwo sein. Denke nicht, daß Du Dich auf 64 verschiedene Tage beschränken willst.

Marthog

volkard schrieb:

float und double sind gleich schnell, weil der Prozessor intern eh lang rechet (sogar mit 80 bit).
Sagen wir mal, der Prozessor ist schnell, die Grafikkarte ist schnell, nur der PCI-Bus kann nicht pro Frame 750Mio doubles übertragen. Er packts einfach nicht so viele Daten zu schaufeln, so viele Megabyte pro Sekunde. Also schickt man float, rechnet vielleicht deswegen schon nur mit float.

Nicht ganz. Die SSE-Befehle koennen floats auch mit 32 bit Genauigkeit verarbeiten und vielleicht kann der Compiler die Rechenoperationen dann auch vektorisieren.
Ebenso nutzen Grafikkarten die kleineren floats wesentlich effizienter und da man bei Spielen wenig Genauigkeit braucht, kann man auch problemlos auf floats zurueckgreifen.

Dennoch ist die Aussage schon richtig, dass man sich bloss nicht im Datentyp beschraenken braucht. Solange man nicht ueberall 64 bit integer auf 32 bit CPUs verwendet, sollte sich das nicht viel nehmen. Davon abgesehen ist das meiste eh zeitunkritisch.

oenone

Immer ein Bit über behalten.. Für zukünftige Erweiterungen!