Laden...

Warum sollte man short statt int verwenden?

Erstellt von Ichthys vor 5 Jahren Letzter Beitrag vor 5 Jahren 1.816 Views
I
Ichthys Themenstarter:in
136 Beiträge seit 2007
vor 5 Jahren
Warum sollte man short statt int verwenden?

Hallo zusammen,

mal eine theoretische Frage: Warum sollte man short verwenden und nicht gleich int? Gibt es dafür handfeste Gründe?
Mir ist der Umfang von short (216) und int (232) bewusst. Aber ich sehe bislang keinen Vorteil bei short, außer dass man aus meiner Sicht etwas Ressourcen spart. Da ich im Internet dazu nicht wirklich was gefunden habe, würde ich gerne mal eure Meinung dazu hören.

Tante Edith: mir ist aufgefallen, dass der Beitrag in die falsche Kategorie gerutscht ist. Kann ein Moderator diesen bitte in die Kategorie "Rund um die Programmierung" verschieben?

Hinweis von gfoidl vor 5 Jahren

Ist verschoben.

F
10.010 Beiträge seit 2004
vor 5 Jahren

Man sollte short verwenden wenn man native structs auf .net mappen muss (Interop) .

Ansonsten gibt es keinen Grund.

I
Ichthys Themenstarter:in
136 Beiträge seit 2007
vor 5 Jahren

Aha. Und warum da? Da es ja Richtung .net geht, könnte man doch auch int verwenden? Was kann denn da schief gehen?

P
1.090 Beiträge seit 2011
vor 5 Jahren

Einfach mal an die Binär Darstellung denken
-1 short = 1000 0000 0000 0001
-1 int = 1000 0000 0000 0000 0000 0000 0000 0001

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

P
1.090 Beiträge seit 2011
vor 5 Jahren

8o Ist schon ein paar Jahre her, wo ich das das letzte mal gebraucht hab. Hatte jetzt nur noch im Kopf das das 1. Bit für das Vorzeichen ist.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

6.911 Beiträge seit 2009
vor 5 Jahren

Hallo Ichthys,

etwas Ressourcen spart

Ressourcen in Bezug auf Speicherbedarf u.U.
Ein int ist 4 bytes, während ein short 2 bytes ist. Das wäre somit die Hälfte, wenn da nicht Data structure alignment ins Spiel kommen würde.

Wie von FZelle erwähnt macht es eigentlich nur Sinn wenn ein Marshalling zu unmanaged / native Code nötig ist. Dort ist dann bei structs auch ein entsprechendes Layout vorzugeben (Sequential od. Explicit), damit die Runtime (CLR) kein Padding einbaut so wie ihr es passt.

Ressourcen in Bezug auf Rechenleistung eher gegenteilig.
Ein x64 Prozessor hat eine Wortbreite von 64 bit, also von 8 bytes (z.B. long) und mit den Registern rax, rbx, ...r15 kann direkt damit gearbeitet werden.
Für 4 byte Daten (int) hat der Prozessor einen gesonderten Modus (eax, ebx, ...), bei dem er nur die "halbe Registerbreite" verwendet und dieser Modus wird auch vom (Ryu)JIT unterstützt in der Codegenerierung.
Kleiner Datentypen wie short können vom Prozessor zwar verwendet werden (ax, ...) nur der (Ryu)JIT hat das nicht in seiner Codegeneriung und "weitet" die Werte (durch "zero extension" movzx) auf int od. long auf um damit rechnen zu können. Das ist weniger performant als mit den "nativen" Datentypen zu rechnen. (Anmerkung: daher gibt es in C++ auch den Datentyp size_t, welcher der Wortbreite des Prozessors bzw. exakter der Platform entspricht. Für C# gibt es eine Bestrebung auch so einen Datentyp zu haben, da sich damit v.a. low-level Library-Code wie er in einigen BCL-Typen vorhanden (z.B. Span, etc.) effizienter gestalten lässt, z.B. ist auf x64 ein for-Schleife die eien Array durchläuft mit long als Zählvariable effizienter als mit int, da für den Arrayzugriff (= Pointer) keine int -> long Erweiterung nötig ist).

Manche Prozessoren haben auch Durchsatzeinbußen wenn die "Viertelregister" (ax, ...) verwendet werden.
Bei x86 verhält es sich ähnlich, aber bei dem kenn ich mich nicht (mehr) gut aus.

Das war jetzt ein wenig low-level.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

C
1.214 Beiträge seit 2006
vor 5 Jahren

gfoidl hat das schon sehr gut beschrieben, ich möchte nur noch 1-2 Kleinigkeiten ergänzen:

  • Wenn es um sehr große Datenmengen geht, z.B. Milliarden von Messwerten, können 2 Byte (bzw. die Hälfte) schon sehr viel ausmachen. z.B., ob die Daten überhaupt in den Arbeitsspeicher passen, bzw. wieviel in den Arbeitsspeicher passen
  • Für die Performance ist Cachelokalität sehr wichtig. Die CPU ist sehr schnell, der Arbeitsspeicher im Vergleich dazu sehr langsam. Je mehr wichtige Daten in die Caches passen (und die CPU nicht auf den Arbeitsspeicher warten muss), desto besser. Je nach Anwendungsfall macht es Größenordnungen aus und kann u.U. viele Nachteile aufwiegen.