TRUE oder true?
-
Bashar hat eigentlich immer Recht mit seinen Aussagen, deswegen bin ich gespannt auf seine Begründung.
-
Original erstellt von TomasRiker:
Soweit ich weiß, ist das kein Quatsch. Wir haben es mit 32-Bit-Prozessoren zu tun. Rechnen mit Bytes erfordert eine Konvertierung von Byte nach DWORD, dann die Berechnung, und anschließend wieder zurückkonvertieren (so steht's jedenfalls in "Inside DirectX"). Außerdem hat der Pentium4-Prozessor es gern, wenn Variablen in 16-Byte-Blöcken angeordnet sind. Darum gibt es ja bei DirectX 9 z.B. die Klasse D3DXMATRIX16 (oder "A16"?).klar nimmt der prozessor immer schöne stücke - aber stell dir mal ne schleife vor - da kann er glatt 4 bools nehmen während er nur 1 BOOL bekommt.
der compiler ist schon klug genug zu optimieren, und er macht aus 1 Byte wenn er es für richtig hält 4 byte (zur compile time) und wenn er denkt dass es nicht gut ist, dann lässt er 1 byte.
das ist doch auch der grund warum man sagt:
builitin by value übergeben und nicht per const reference - weils per value schneller ist -> der compiler kann optimieren wie und wo er will.
-
Original erstellt von TomasRiker:
Rechnen mit Bytes erfordert eine Konvertierung von Byte nach DWORD, dann die Berechnung, und anschließend wieder zurückkonvertieren (so steht's jedenfalls in "Inside DirectX").wird durch meine Erfahrung nicht bestätigt. Die Addition zweiter chars wird im gcc durch eine Byte-Addition dargestellt. Was du sagst, stimmt dann, wenn in dem Ausdruck auch ints vorkommen.
Ausserdem wird mit bool nicht gerechnet ...Der Vorteil mag nicht mal annähernd 1:4 sein, aber gleich einen Nachteil aus !Dword zu zimmern ist übertrieben.
-
der compiler ist schon klug genug zu optimieren, und er macht aus 1 Byte wenn er es für richtig hält 4 byte (zur compile time) und wenn er denkt dass es nicht gut ist, dann lässt er 1 byte.Man sollte sich nicht immer auf die optimierungen des compilers verlassen.
Wenn man eine Var zum Rechnen braucht nimmt man eben int weil man weiß dem Rechner schmeckts am Besten. Zu sagen, ich nehm BYTE , der Compiler wirds schon richten, is net unbedingt die richtige Einstellung..Ich habs grad mal getestet..BYTE gegen int: ohne Optimierung war int deutlich schneller, mit Optimierung gleich
[ Dieser Beitrag wurde am 19.02.2003 um 14:19 Uhr von crass editiert. ]
-
Original erstellt von crass:
Man sollte sich nicht immer auf die optimierungen des compilers verlassen.
Wenn man eine Var zum Rechnen braucht nimmt man eben int weil man weiß dem Rechner schmeckts am Besten. Zu sagen, ich nehm BYTE , der Compiler wirds schon richten, is net unbedingt die richtige Einstellung..Diese Einstellung ist Blödsinn.
Der Compiler kann nicht alles richten, aber wenn man schreibt was man meint statt zu schreiben, was Compiler vor 10 Jahren zu besserem Assembly-Code verwursten konnten, wird das schnell ins Auge gehen.Du kritisierst: Verlasst Euch nicht darauf, dass Euer Compiler optimiert! und machst es so jedem optimierenden Compiler schwer, weil Du voraussetzt, dass ein Compiler so dumm sein muss, dass er nicht erkennt wie das Byte-Alignment günstigerweise auszusehen haben sollte. Schreibe keine Programme für bestimmte Compiler sondern welche für eine bestimmte Sprache!
Performance gewinnt man nicht durch BOOLS und Byteshifts sondern durch performante Algorithmen, gut designte Datenstrukturen/ Klassen und Code in dem Du schreibst, was Du machen möchtest und nicht irgendwelche Spielereien aus vermodernden Optimierungskisten (Besser wartbar werden Deine Programme dadurch obendrein)!
-
ein anderes argument für bool ist wohl das die stl und auch die stream bibliothek es kennt...
so kann man z.b. per boolalpha nen stream dazu bewegen das er true und false anstatt nur 1 und 0 akzeptiert... wenn ich aber ein BOOL ausgebe das aus irgendeinem grund sagen wir den wert 42 hat bekomme ich auch im uotput den wert 42 und nicht 1 oder true...[ Dieser Beitrag wurde am 19.02.2003 um 23:47 Uhr von japro editiert. ]
-
da bei einem 1 byte bool der Prozessor erst die anderen 3 Bytes, die fehlen, ausmaskieren muss, könnte sein dass das langsamer ist.
[ Dieser Beitrag wurde am 20.02.2003 um 07:37 Uhr von Lars editiert. ]
-
was glaubst du wie er das macht? AND mybyte,0xFFFFFF00?
Der Prozessor hat ein paar Sachen direkt eingebaut, irgendwas müssen sie ja mit den Millionen von Transistoren auch anstellen. Das mag elektrisch gesehen ein paar Picosekunden langsamer sein, aber solang das innerhalb eines Taktes abgeschlossen ist und keine Resourcen belegt (ALU, Pipeline whatever die da so hübsches haben) spielt das keine Rolle.
-
ausserdem weisse ich nochmal kurz auf Exceptional C++ hin - da wird genau beschrieben warum man einen builtin bool braucht.
also ich verlasse mich auf meinen compiler. ich schreibe auch, wenn ich 2 minuten in sekunden angeben muss:
2*60
und nicht
120warum? weils lesbarer ist.
ich weiss, dass der compiler das wegoptimiert. Der compiler kann das besser als ich - der berechnet sachen die ich nichtmal aussprechen kann. insofern vertraue ich ihn, dass er meinen code schön schnell macht.
-
Was hat das eigentlich mir Spiele-/Grafikprogrammierung zu tun...
