Variablentypen Byte, ShortInt, etc. noch sinnvoll?

[XoRiC]

Hallo,

ich habe eine Frage zu den (un-)gängigen Variablentypen in Delphi. ich neige meist dazu, Variablentypen so klein wie möglich zu wählen. Wenn ich also von einer Variable weiß, dass sie stets positiv ist und beispielsweise nicht größer als 20 wird, dann deklariere ich sie als Byte. Wenn eine Variable -1, 0 und 1 sein kann, nehme ich z.B. ShortInt usw.

Hier mal ein Beispiel wie mein Code desöfteren aussieht. Der Inhalt besitzt keinen tieferen Sinn:

Delphi-Quellcode:

function Add_or_subtract: ShortInt;
begin
  // Code unwichtig, liefert z.B. -1 oder +1
end;

procedure Test(max: byte);
  var i: integer;
      add: ShortInt;
      j: byte;
begin
  // ..
  i := 10;
  add := Add_or_subtract;
  for j := 1 to max do i := i + add;
  // ..
end;

Nun hat sich schon das eine oder andere Mal der Compiler beschwert, dass ich bei mathematischen Operationen oder if-Abfragen Variablen unterschiedlichen Typs verwende, z.B. verschiedener Breite oder unsigned mit signed.
Nun frage ich mich, ob das überhaupt noch sinnvoll ist, da der Arbeitsspeicher heutzutage ja mehr als ausreichend ist und wohl niemand einen Unterschied merkt, ob eine Hand voll Variablen als ShortInt oder als Integer im Speicher liegen. In meinem obigen Beispiel hätte ich dann z.B. alternativ sämtliche Variablen als Integer deklariert.

Ich persönlich mag diesen Programmierstil, alles so klein wie möglich zu halten. Es gibt mir oft einen guten Überblick, welchem Zweck die ein oder andere Variable dient. Da mein laufender Prozess nach meinem derzeitigen Verständnis durch Typumwandlungen aber eher verlangsamt wird (?) und ich neulich über einen Artikel gestolpert bin, nach dem sogar schon Booleans teilweise im 32-Bit Format gespeichert werden, wollte ich mal in die Runde fragen, ob mir zu diesem Thema jemand ein paar Informationen geben kann.

Danke wie immer für Tipps und Links,
Gruß Xoric

[Bernhard Geyer]

Alles was der prozessor nicht passend zu seiner Speicherausrichtung gleich "fassen" kann dauert lang einzulesen. Aktuelle Prozessoren haben hier ein Alignment von mindestens 4 Byte, eher 8-16 Byte (Auch unter 32-Bit OS). Das hat mit Speicherbusbreite/Cache-Ausrichtung etc. zu tun.

[Corpsman]

ja ich dachte auch mal so wie du.

Doch nun da ich das Informatik Studium schon fast hinter mir habe sehe ich das anders.

Ich nutze wo es nur geht Integer variablen, da diese auf 32 Bit Architekturen immer schön in ein Register gehen. Und so viel ich weis macht Delphi das intern auch, so lange du nicht so was wie Packed deklarierst ( In meinem LZW Sample muste ich eine Bitweise Speicherung sogar extra nachbilden, um diese auch zu bekommen ).

Für Kleinere Mengen wie dein ( -1, 0 , 1 ) Beispiel wähle ich so gut es geht selbst deklarierte Mengen also
Type TWerte = (ja, nein, ungewiss) ; Der Compiler wählt intern eh eine eigene Darstellung ( ebenfalls wieder zahlen, in dem Fall dürfte es 0 bis 2 sein ).

Der Vorteil ist hier also klar der, der Lesbarkeit. Und gerade bei komplexeren Projeckten sollte die Lesbarkeit / Wartbarkeit dein primäres Ziel sein.

Der 2. Vorteil hierbei ist, natürlich auch das das Typ System von Delphi dir hier bei ungewollten Zuweisungen entsprechende Fehler auswirft.

Willst du diese Zuweisungen kannst du natürlich auch über Integer Constanten gehen

Delphi-Quellcode:

Const
 Twert_Ja : Integer = 0;
 Twert_nein : Integer = 1;
 Twert_Ungewiss : Integer = 2;

Generell kannst du dem Compiler eine ganze Menge zutrauen, die heutigen Compiler können erstaunlich viel Optimieren, und stellen deinen Code ganz schön um ( siehe dazu asm Code im vergleich zum Quellcode ..)

[XoRiC]

@ Bernhard und Corpsman

Ich studiere selbst Informatik, was der Compiler macht und wo er sich raushält ist für mich bisher aber ein Rätsel geblieben. Jedenfalls werde ich wohl meinen bisherigen Programmierstil über den Haufen werfen und mich gemäß euren Erklärungen umgewöhnen ;)

Im Hinblick auf kommende 64 Bit Systeme stellt sich mir dann aber die Frage, ob Integer wirklich die beste Lösung sind. Ich habe von Variablentypen ("Cardinal"?) gehört, die automatisch die Wortbreite des Prozessors einnehmen. Wären dann nicht das die geeigneten Datentypen um sicherzustellen, dass das Programm auch auf späteren Systemen kompatibel sein wird? Oder wie sollte ein zukunftsorientierter Quellcode im Hinblick auf die verwendeten Variablentypen aussehen?



@ Corpsman

Vielen Dank auch für den Tipp bezüglich der deklarierten Mengen. Das sieht vielversprechend aus und war mir bisher noch nicht geläufig :)



Viele Grüße,
Xoric

[Medium]

Für die Geschwindigkeit macht es keinen Unterschied, ob man den kleinst möglichen Typen, oder den der der Wortbreite des Prozessors entspricht nimmt. Die Größe macht bei ein paar (auch gern ein paar zig) Variabelchen praktisch null unterschied. Die Fluktuationen die das OS einbringt (Allokationen etc.), und vor allem dem was durch fremden Code (u.a. auch Delphi Komponenten) beigetragen wird, macht solche Optimierungen zu einem Fliegenschiss .
Einzig und allein bei größeren Arrays/Listen würde ich ein wenig drauf achten, aber wirklich auch erst dann wenn ich mich im Bereich von >10MB Strukturen bewege, bzw. mehreren davon. Aber bei der gemeinen Laufvariable z.B. macht es wenig Sinn knauserig zu werden. Ich bin ja auch eher einer der es gern klein, handlich und kompakt hat - nicht zuletzt weil mir teilweise das "Rumgehure" mit RAM und CPU Cycles in so manch größerer Software auf den Geist geht. Aber SO kleinlich würde ich mittlerweile nicht mehr werden.


Edit: Integer und Cardinal sind beides "generische" Typen, die der Wortbreite der CPU entsprechen. Das stimmt bei Delphi jetzt nicht 100%ig, da unter 32 Bit Compilern immer gegen 32 Bit Register kompiliert wird, bei einem hoffentlich bald erscheinenden 64er Delphi werden diese Typen aber 64 Bit breit sein - bzw. sollten sie das, irgendwo gab's mal ein Blog in dem das wegen Rückwärtskompatibilität in Frage gestellt wurde. Jedoch sollte man, wenn man exakt auf eine Breite angewiesen ist bei manchen Zwecken, schon prinzipiell nicht auf diese generischen zurückgreifen, sondern fest definierte wie Byte, Word oder DWord nehmen. Der einzige Unterschied zwischen Integer und Cardinal ist: Integer hat ein Vorzeichen.

[Corpsman]

na wenn du Informatik studierst, empfehle ich dir die Vertiefungslinie Compilerbau. Die ist der Wahnsinn.

Ich dachte Cardinal sei bei Delphi ein Integer ohne Vorzeichen ??

Allerdings hab ich D5 gehabt, evtl. ist das mittlerweile anders. ( mittlerweile hab ich FPC, wäre interessant zu wissen wie's da ist )

Eine Variable die bei entsprechender Architektur ihre Breite ändert würde ich übrigens nicht nehmen. Gerade das du weist wie die Wertebereiche sind ist für dich als Programmierer wichtig.

Siehe neuere Programme und das Pointer / Integer Problem.

[himitsu]

Das ist zwar ein Alignment-Test, aber es geht ja in die selbe Richtung
und man sieht sehr gut, was "falsche" Größen/Ausrichtungen bewirken können.

und dann noch 2 Seiten zum Lesen
http://www.ibm.com/developerworks/library/pa-dalign/
http://msdn.microsoft.com/en-us/library/aa290049.aspx

Aber ganz in Ernst, sowas hat eigentlich nur eine Auswirkung, wenn es sehr viele und schnelle Operationen und es keine anderen stärker bremsenden Einflüsse gibt.


Also lokal nehme ich auch vorwiegend Integer und Co.,
aber in Records und bei fest definierten Wertebereichen, da nehm ich meißt einen passenenden Typ.

Außerdem sind gut ausgerichtete kleinere Typen dann nur dalb so "schlimm", wie unausgerichtete passende Typen.

[Medium]

Auf's Alignment wollte ich auch noch hinaus, wobei das gerade bei einzelnen Variablen eher unbedeutend ist, da zumindest Delphi meines Wissens nach nicht mutwillig misaligned wenn man es ihm nicht brutal aufzwängt. Und auch bei zusammengesetzten Typen gibt's immer noch die Projekteinstellung, und man muss es mit "packed" von Hand umgehen wenn man es wirklich braucht. Beim normalen Tagesgeschäft sollte man da eher selten dran geraten, und es ist noch nichtmal SO schlimm, wenn man nicht grad ganz wildes Zeug berechnet. Bei typischen Business-Applikationen eher selten der Fall.

[himitsu]

jupp, bei kleineren Typen muß maximal zusätzlich nur ein Shift und/oder eine Maske angewendet werden,
wenn es ausgelesen wird.

Beim Schreiben ist es schon aufwändiger:

1111 und 2222 = Word
******** = Integer einer 32-Bit-CPU

*1
*1
*1
*1 aka $22221111
*2
*2
*2
*2

die 2222 soll gespeichert werden:
- $******** auslesen
- $******** and $0000FFFF = $1111 extrahieren
- $2222 shl 16 = $2222 anrichtige Position schieben
- $22220000 or $00001111 = kombinieren
- $22221111 speichern

Als Integer bräuchte man es einfach nur einfügen,
aber die CPUs sind so gut optimiert, daß sowas eigentlich nur in Extremfällen sehr auffällt.

[XoRiC]

Mir ist nun einiges klarer als vorher. Danke für die vielen Antworten!


@ himitsu
Mit dem Thema werd ich sowieso noch zu tun bekommen, also vielen Dank für die beiden Links!

@ Medium

Zitat:

... macht solche Optimierungen zu einem Fliegenschiss :)

Ich habe mich sogar schon beim Optimieren von if-Bedingungen ertappt (Fragen wie: ist 'i = 0' oder 'i <= 0' schneller etc). Im Nachhinein hab ich an den Fingern meiner rechten Hand die eingesparten Taktzyklen abgezählt und bin etwas geknickt aber eine Erfahrung reicher zum Schluss gekommen, dass heutzutage die Optimierung von Code (wenn er nicht gerade in einer millionenfach durchlaufenen Schleife steht) bei einem 2 GHz Prozessor pure Zeitverschwendung ist. In den meisten Fällen erledigt solche Kleinigkeiten wohl sowieso der Compiler ;)

@ Corpsman

Zitat:

Ich dachte Cardinal sei bei Delphi ein Integer ohne Vorzeichen

Ich glaube du hast Recht, wie es scheint hab ich was verwechselt. Ich hab aber sowieso deinen Tipp beherzigt und bleibe beiinteger mit festem Wertebereich ;)


Gruß an alle,
Xoric