Rueckgabetyp int als Verschwendung?
-
Hallo Zusammen,
Ist int als Rueckgabetyp nicht Verschwendung als 4 byte? Ich meine, wo ich
momentan einiges mit bits zu tun habe, denke ich, "char" zb. fuer simple
Werte wie (-1,0,1) vollkommen ausreichen als einen int. Aber niemand benutzt
es. Dabei haette man nur ein byte hin und her geschickt.. Ich koennte genauso gut
Fallunterscheidung machen wie beim int. Was nun schlecht sein koennte ist die
Signatur vielliecht
/* in h file */ char createFile(char* filename...... );Warum wird ein (signed natuerlich) char dafuer nicht benutzt sondern int
haeufig? Haette man bessere Performance erzielt wenn man doch char benutzen
wuerde?Gruss,
-
Int hat üblicherweise eine für das System angemessene/performante Größe. Für die Rückgabe eines Chars auf einer 32-bit Maschine würde vermutlich eh ein ganzer Register verwendet werden (so wie bei einem int auch).
Gruß
Don06
-
jsbach schrieb:
Warum wird ein (signed natuerlich) char dafuer nicht benutzt sondern int
haeufig? Haette man bessere Performance erzielt wenn man doch char benutzen
wuerde?ich würde sagen, das hängt davon ab, wie man Performance definiert: meinst du im Hinblick auf Geschwindigkeit, oder Speicherplatz?
Der übersetze Code ist in der Regel kleiner, wenn du int nimmst, weil der Compiler nicht mehr mit der Byte Größe "jonglieren" muss, um genau ein char oder short zurückzugeben, weil Register in der Regel 4 Byte lang sind.
Im Programmierhandbuch der ARM Architektur wird zum Beispiel dazu geraten, immer int zu nehmen, selbst wenn man nur eine 0 oder eine 1 zurückliefert.
-
Gilt das generell für die Grunddatentypen oder nur für Rückgabewerte?
In meinen Programmen verwende ich für solche kleinen Werte meistens short int. Das ist zwar immer noch eine Verschwendung, aber meiner Ansicht nach besser als int. Aber durch die vorherigen Posts bin ich jetzt ein bisschen verunsichert; kann man gerade so gut immer int nehmen? Was gewinn ich denn mit short?Aber wenn es sich kaum lohnt, möglichst kleine Datentypen zu verwenden, wieso gibts dann die überhaupt? Für Prozessoren mit kleinerem Register?
Muss man heute denn nicht mehr auf Speicherplatz achten?
-
supertux schrieb:
ich würde sagen, das hängt davon ab, wie man Performance definiert: meinst du im Hinblick auf Geschwindigkeit, oder Speicherplatz?
Als erstes habe ich mir gedacht: Es waere dadurch eine Optimierung in beide
Richtungen gleichzeitig moeglich. Jetzt wo ich eure Postings gelesen habe,
denke ich mitder Optimierung in Geschwindigkeit wird nix.supertux schrieb:
Der übersetze Code ist in der Regel kleiner, wenn du int nimmst, weil der Compiler nicht mehr mit der Byte Größe "jonglieren" muss, um genau ein char oder short zurückzugeben, weil Register in der Regel 4 Byte lang sind.
Don06 schrieb:
Int hat üblicherweise eine für das System angemessene/performante Größe. Für die Rückgabe eines Chars auf einer 32-bit Maschine würde vermutlich eh ein ganzer Register verwendet werden (so wie bei einem int auch).
Ok, ich sehe. Es hoert sich so an als ob Typen < 4bytes entsprechend bei binary
Erstellung fuer den Register durch den Compiler "jongliert" werden(un/shift zu 4byte) ;).
Analog zu dieser Fakt, es waere dann sinnvoll auf einen x86_64 immer longs
zurueckzuliefen, oder? Natuerlich ausgegangen davon dass ein long auf dieser
Maschine 8bytes sind.Gruss,
-
was auf x86 besser geeignet ist, weiß ich nicht. Ich kenne mich nicht so genau mit der x86 Architektur aus.
Ich denke, dass jede Architektur ihre Eigenschaften hat und hängt auch vom Compiler ab. Als ich einen Mikrokernel für einen Intel XScale geschrieben habe, musste ich mich damit auseinandersetzen, was dort besser geeignet ist. Da ARM im Prinzip nur 32-Register kennt und die Parameter Übergabe erstmal nur von r0 bis r3 (all purpose registers) abhängt, ist der Code immer kürzer, wenn man mit int/short statt char arbeitet, weil sonst der Compiler öfters unnötige Byteshifts getan hat. Auf anderen Architekturen muss das nicht unbedingt gelten, wenn z.b. die Parameter Übergabe anders funktioniert (z.b. über dedizierte Register).
Klar habe ich auch mit char's gearbeitet, wenn ich bspweise schnell auf ein Byte eines Speicherblocks zugreifen musste, ohne selber bitmasks und shifts berechnen zu müssen. Das sind aber spezielle Fälle und es gibt ihmo keine allgemeine Regel nach der man sich richten muss, sondern man muss sich für jede Funktion extra Gedanken machen, wo man was optimieren will.
-
jsbach schrieb:
Analog zu dieser Fakt, es waere dann sinnvoll auf einen x86_64 immer longs
zurueckzuliefen, oder? Natuerlich ausgegangen davon dass ein long auf dieser
Maschine 8bytes sind.ich hab' mal gehört, dass compiler für diese 64bit-x86's auch 32bittige ints haben. das finde ich doof, denn eigentlich wär's besser, wenn 'int' dort 64bits hätte, weils der registerbreite entspricht.
topic: richtig angschmiert mit 'int' sind leute, die 'nen 8-bit prozessor verwenden, weil 'int' mindestens 16 bits haben muss. da ist 'char' dann oft die bessere wahl.
-
Nexus schrieb:
Gilt das generell für die Grunddatentypen oder nur für Rückgabewerte?
In meinen Programmen verwende ich für solche kleinen Werte meistens short int. Das ist zwar immer noch eine Verschwendung, aber meiner Ansicht nach besser als int. Aber durch die vorherigen Posts bin ich jetzt ein bisschen verunsichert; kann man gerade so gut immer int nehmen? Was gewinn ich denn mit short?Gar nichts. Zur Datenspeicherung bei wenig Kapazitäten kann man über eine Verwendung von short int nachdenken. Ansonsten solltest du besser int nehmen. Erst recht bei temporären Instanzen wie Rückgabewerten. Unter x86-32 hat short int sogar negative Auswirkungen. Hier muss für 16 Bit Instruktionen nämlich ein Prefix vorangestellt werden, was den Code nicht nur vergrössern, sondern auch noch langsamer sein kann.
jsbach schrieb:
Ok, ich sehe. Es hoert sich so an als ob Typen < 4bytes entsprechend bei binary
Erstellung fuer den Register durch den Compiler "jongliert" werden(un/shift zu 4byte) ;).
Analog zu dieser Fakt, es waere dann sinnvoll auf einen x86_64 immer longs
zurueckzuliefen, oder?Nein. Wie bereits gesagt wurde, int ist immer der geeignetste Typ für die jeweilige Plattform. Daher sollte man diesen auch verwenden. Und auf einer 64 Bit Plattform muss long auch nicht unbedingt 64 Bit breit sein. Das hängt vom verwendeten Datenmodell ab. Win64 nutzt zB LLP64, und dort ist long genauso breit wie int, nämlich 32 Bit. Erst long long ist 64 Bit breit.