Platzverschwendung im Speicher bei Verwendung von Char Datentypen
-
Artchi schrieb:
Ein 32Bit-Prozessor kann nur auf 32 Bit gleichzeitig zugreifen und er kann sich auch nur in 32 Bit-Schritten im Speicher fortbewegen.
Woher hast du denn das? AMD oder Intel Prozis können sich genauso schön in 8 oder 16 bit Schritten bewegen. Ob 32 bit Zugriffe schneller sind als 8 bit wage ich fast zu bezweifeln. 16 bit könnten schon langsamer sein, da mehr Instruction Bytes verarbeitet werden müssen. Viel wichtiger für die Geschwindigkeit ist die Ausrichtung des Speichers.
-
Helium schrieb:
ich habe heute mal mit dem Debugger der Visual C++ 6.0 IDE herumgespielt
Muss man noch mehr sagen
Wo soll da das Problem sein?
Der Debugger zeigt mir die Register und den Speicherinhalt an,
ich finde das äußerst praktisch.
-
Bashar schrieb:
Wie passt die Tatsache, dass gcc die chars dicht ablegt, in eure tolle Theorie?
Habs zwar noch nicht nachgeprüft, aber wenn das so wäre, dann wäre das klasse, denn das würde auch erklären warum der gcc beim Compilieren mehr
Zeit benötigt als der Visual C++ Compiler, denn in diesem Fall geht der GCC ordernlichter vor, d.h. der Maschinencode ist hinterher sauberer und nicht so verschwenderisch wie beim Visual C++ Compiler.
-
sdf schrieb:
Bashar schrieb:
Wie passt die Tatsache, dass gcc die chars dicht ablegt, in eure tolle Theorie?
Habs zwar noch nicht nachgeprüft, aber wenn das so wäre, dann wäre das klasse, denn das würde auch erklären warum der gcc beim Compilieren mehr
Zeit benötigt als der Visual C++ Compiler, denn in diesem Fall geht der GCC ordernlichter vor, d.h. der Maschinencode ist hinterher sauberer und nicht so verschwenderisch wie beim Visual C++ Compiler.Blödsinn.
Ob der Compiler jetzt ein char zu einem DWORD 'padded' oder nicht, ist von der Dauer wohl irrelevant.Dass der gcc sehr schnellen Code erzeugt, dürfte wohl klar sein.
Der Grund warum er so langsam ist, ist der interne Aufbau. GCC ist ja eine Sammlung von Compilern, man kann eine neue Sprache implementieren ohne einen vollständigen Compiler zu schreiben - im Prinzip muss man nur ein Frontend implementieren - der Rest wird vom GCC übernommen.
Dieses Konzept bedeutet, dass der GCC extrem Portabel ist, da man nur ein Backend für einen neuen Prozessor schreiben muss, und schon laufen alle GCC Sprachen dort
Allerdings ist er dadurch natürlich wieder langsamer. Und wenn ich mir den Trend so ansehe, ist Geschwindigkeit beim GCC nicht so wichtig.
-
Shade Of Mine schrieb:
sdf schrieb:
Bashar schrieb:
Wie passt die Tatsache, dass gcc die chars dicht ablegt, in eure tolle Theorie?
Habs zwar noch nicht nachgeprüft, aber wenn das so wäre, dann wäre das klasse, denn das würde auch erklären warum der gcc beim Compilieren mehr
Zeit benötigt als der Visual C++ Compiler, denn in diesem Fall geht der GCC ordernlichter vor, d.h. der Maschinencode ist hinterher sauberer und nicht so verschwenderisch wie beim Visual C++ Compiler.Blödsinn.
Ob der Compiler jetzt ein char zu einem DWORD 'padded' oder nicht, ist von der Dauer wohl irrelevant.Also ich sehe das anders.
Es wird einem zwar immer mehr Speicher geradezu nachgeschmissen,
aber die Anwendungen brauch insgesammt ebenfalls immer mehr Speicher,
d.h. das summiert sich auf und Speicher ist damit sozusagen immer ein knappes Gut, deswegen sollte man sparsam mit ihm umgehen.Dass der gcc sehr schnellen Code erzeugt, dürfte wohl klar sein.
Es ging nicht darum, ob er schnellen Code erzeugt sondern darum wie lange er dazu braucht.
Der Grund warum er so langsam ist, ist der interne Aufbau. GCC ist ja eine Sammlung von Compilern, man kann eine neue Sprache implementieren ohne einen vollständigen Compiler zu schreiben - im Prinzip muss man nur ein Frontend implementieren - der Rest wird vom GCC übernommen.
Danke für die Info.
-
sdf schrieb:
Shade Of Mine schrieb:
sdf schrieb:
Bashar schrieb:
Wie passt die Tatsache, dass gcc die chars dicht ablegt, in eure tolle Theorie?
Habs zwar noch nicht nachgeprüft, aber wenn das so wäre, dann wäre das klasse, denn das würde auch erklären warum der gcc beim Compilieren mehr
Zeit benötigt als der Visual C++ Compiler, denn in diesem Fall geht der GCC ordernlichter vor, d.h. der Maschinencode ist hinterher sauberer und nicht so verschwenderisch wie beim Visual C++ Compiler.Blödsinn.
Ob der Compiler jetzt ein char zu einem DWORD 'padded' oder nicht, ist von der Dauer wohl irrelevant.Also ich sehe das anders.
Es wird einem zwar immer mehr Speicher geradezu nachgeschmissen,
aber die Anwendungen brauch insgesammt ebenfalls immer mehr Speicher,
d.h. das summiert sich auf und Speicher ist damit sozusagen immer ein knappes Gut, deswegen sollte man sparsam mit ihm umgehen.Da gibt es nichts anders zu sehen. Es ist von der Übersetzungszeit her irrelevant, ob der Compiler die Bytes zusammensteckt oder nicht.
Der Rest paßt irgendwie grad nicht zum Thema.
-
Bashar schrieb:
Wie passt die Tatsache, dass gcc die chars dicht ablegt, in eure tolle Theorie?
Vielleicht weil es eine Option gibt, die sowas erlaubt? In VC++ Professionell kann man wählen, ob der Code "schnell" oder "platzsparend" arbeiten soll. Wobei schnell bedeuten kann, das mehr Speicher belegt wird. Und platzsparend evtl. langsamen Code.
So kenne ich es vom VC++ Pro.
-
groovemaster2002 schrieb:
Artchi schrieb:
Ein 32Bit-Prozessor kann nur auf 32 Bit gleichzeitig zugreifen und er kann sich auch nur in 32 Bit-Schritten im Speicher fortbewegen.
Woher hast du denn das? AMD oder Intel Prozis können sich genauso schön in 8 oder 16 bit Schritten bewegen. Ob 32 bit Zugriffe schneller sind als 8 bit wage ich fast zu bezweifeln. 16 bit könnten schon langsamer sein, da mehr Instruction Bytes verarbeitet werden müssen. Viel wichtiger für die Geschwindigkeit ist die Ausrichtung des Speichers.
Na gut, wenn du meinst, das auf diesem Planeten nur AMD und Intel existiert? Ich weiß nicht ob diese CPUs auch 8 Bit-Zugriffe erlauben. Ich weiß nur, das die ARM-Familie z.B. nur 32 Bit-Zugriffe erlaubt, und dadurch irrsinnig schnell ist.
OK, da die heutigen Intels zu 20 Jahre alten 8086 kompatibel sein müssen, kann es gut sein, das da noch 8 Bit-Befehle und Register umkriechen. Technik die Begeistert!
-
sdf schrieb:
Helium schrieb:
ich habe heute mal mit dem Debugger der Visual C++ 6.0 IDE herumgespielt
Muss man noch mehr sagen
Wo soll da das Problem sein?
Der Debugger zeigt mir die Register und den Speicherinhalt an,
ich finde das äußerst praktisch.Ja aber der Debugger packt auch tonnenweise Kram in den Code, der im Release nicht mehr da ist.
01 CC CC CC
Noch eindeutiger geht's kaum. CC CC CC stammt garantiert vom Debuggen.
-
Helium schrieb:
sdf schrieb:
Helium schrieb:
ich habe heute mal mit dem Debugger der Visual C++ 6.0 IDE herumgespielt
Muss man noch mehr sagen
Wo soll da das Problem sein?
Der Debugger zeigt mir die Register und den Speicherinhalt an,
ich finde das äußerst praktisch.Ja aber der Debugger packt auch tonnenweise Kram in den Code, der im Release nicht mehr da ist.
Und wie schau ich mir den Code dann nach dem Release an?
-
sdf schrieb:
Und wie schau ich mir den Code dann nach dem Release an?
Lass dir den ASM Code generieren und schau den an
-
mein gcc-Testprogramm sah übrigens so aus:
#include <iostream> using namespace std; int main() { char a,b; cout << &a - &b << endl; }abhängig von den Optimierungseinstellungen kam -1 oder 1 raus.
BTW wenn es tatsächlich so wär, dass Bytes auf 32bit ausgerichtet schneller verarbeitet werden können, warum ist dann ein char nicht 32bit groß? Compiler sollten diesen Modus der Geschwindigkeit wegen wenigstens anbieten.
-
Artchi schrieb:
Na gut, wenn du meinst, das auf diesem Planeten nur AMD und Intel existiert?
Warum legen einige Leute nur jedes Wort auf die Goldwaage? Sry wenn ich dir mit meiner Aussage impliziert hab, dass ich nur AMD und Intel Prozis kenne. Dem ist natürlich nicht so. Aber ich gehe mal davon aus, dass die meisten der Forumuser einen der 2 Prozis in ihrem Rechner haben.
Artchi schrieb:
OK, da die heutigen Intels zu 20 Jahre alten 8086 kompatibel sein müssen, kann es gut sein, das da noch 8 Bit-Befehle und Register umkriechen.
Dem ist nicht so, weil die Prozessoren zu 20 Jahren alten kompatibel sein müssen. Sondern weil die 8 bit Register Teil der 32 bit Register sind. Und wenn sie schon da sind, warum dann nicht auch nutzen.
-
Bashar schrieb:
BTW wenn es tatsächlich so wär, dass Bytes auf 32bit ausgerichtet schneller verarbeitet werden können, warum ist dann ein char nicht 32bit groß? Compiler sollten diesen Modus der Geschwindigkeit wegen wenigstens anbieten.
weil man so 4 chars auf einmal zum cpu senden kann, ich habe sogar mal ein string klasse geschrieben die alle möglichen Operationen mit sizeof(int) chars gemacht hat, erst später merkte ich das ich gegen die str* Funktionen nicht gewinnen würde, aber sonst war sie recht schnell