Diese Seite ist unverschlüsselt! Um sicherzustellen, das Ihr Passwort nicht ausgelesen werden kann, sollten Sie auf die verschlüsselte Seite wechseln!

    Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (ANSI-Standard) » Arrays einlesen
Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: [ 1 ] > 2 <
010
29.09.2003, 12:16 Uhr
~(un)wissender
Gast


nZahl / 16 zu schreiben ist genau dann ok, wenn man sich darauf verlassen kann, dass der Comiler das als nZahl >> 4 versteht.
Division kann, wenn in einer großen Schleife vorkommend, die Performanz ganz erheblich einbrechen lassen.
Auf den x86ern dauert die Division ca. 40 mal so lange wie eine Addition und ist nur schwer parallelisierbar, willl heißen 40(!) Additionen können wesentlich schneller sein als eine Division.

Die gute Nachricht:
Die Comiler sind unglaublich clever was das ersetzen von Divisionen angeht und /16 zu erkennen ist die leichteste Übung.
Der g++ ersetzt auch % oft durch &, sieht ganz klasse aus.
Also immer /16 schreiben
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
011
29.09.2003, 14:12 Uhr
ao

(Operator)



Zitat:
~(un)wissender postete
nZahl / 16 zu schreiben ist genau dann ok, wenn man sich darauf verlassen kann, dass der Comiler das als nZahl >> 4 versteht.
Division kann, wenn in einer großen Schleife vorkommend, die Performanz ganz erheblich einbrechen lassen.

Im Gegenteil.

Quelltext-"Optimierungen", die ohne zwingenden Grund den Sourcecode verschleiern, sind inakzeptabel.

Es ist wahr, dass Divisionen auf den meisten Prozessoren erheblich länger brauchen als Schiebeoperationen. Daraus aber die allgemeine Regel abzuleiten, dass es besser ist zu schieben als zu teilen ist im Zeitalter optimierender Compiler falsch.

nZahl >> 4 zu schreiben ist *nur dann* OK, wenn der Compiler die Division nicht zur Shift-Operation optimiert *und* wenn nachgewiesen ist, dass das Shiften an dieser Stelle einen signifikanten Performance-Gewinn bringt *und* wenn im Quelltext eindeutig dokumentiert wird, was die Shift-Operation eigentlich bewirken soll und warum keine Division kodiert wurde.

ao
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
012
29.09.2003, 15:57 Uhr
virtual
Sexiest Bit alive
(Operator)


Im Allgemeinen gebe ich recht, im Speziellen solte man sich aber an der Semantik orientieren, die man versucht zum Ausdruck zu bringen. Hier kann es Sinn machen, dem >>/<< Operatoren den Vorzug zu gewähren, zB:

C++:
class VersionTag
{
     unsigned long m_nVersionTag;
public:
     ...
     unsigned getMajor() const { return m_nVersionTag>>24; }
     unsigned getMinor() const { return (m_nVersionTag>>16)&0xff; }
     unsigned getPatchLevel() const { return m_nVersionTag&0xffff; }
};

Hier soll zum Ausdruck gebracht werden, daß in m_nVersionTag einzelne Bitgruppen bestimmte Eigenschaften repräsentieren. Analoges Beispiel wäre eine Farbe, deren Farbwert als RGB Wert in einem long gespeichert wird.

Für den von ao angeführten Fall wäre aber - da denke ich genauso - der Shiftoperator ziemlicher 98, 117, 108, 108, 115, 104, 105, 116
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
013
29.09.2003, 21:50 Uhr
~(un)wissender
Gast



Zitat:
ao postete
[quote]~(un)wissender postete
nZahl / 16 zu schreiben ist genau dann ok, wenn man sich darauf verlassen kann, dass der Comiler das als nZahl >> 4 versteht.
Division kann, wenn in einer großen Schleife vorkommend, die Performanz ganz erheblich einbrechen lassen.

Im Gegenteil.

Quelltext-"Optimierungen", die ohne zwingenden Grund den Sourcecode verschleiern, sind inakzeptabel.

Es ist wahr, dass Divisionen auf den meisten Prozessoren erheblich länger brauchen als Schiebeoperationen. Daraus aber die allgemeine Regel abzuleiten, dass es besser ist zu schieben als zu teilen ist im Zeitalter optimierender Compiler falsch.

nZahl >> 4 zu schreiben ist *nur dann* OK, wenn der Compiler die Division nicht zur Shift-Operation optimiert *und* wenn nachgewiesen ist, dass das Shiften an dieser Stelle einen signifikanten Performance-Gewinn bringt *und* wenn im Quelltext eindeutig dokumentiert wird, was die Shift-Operation eigentlich bewirken soll und warum keine Division kodiert wurde.

ao[/quote]

@ao
Na, da sind aber einige Leute anderer Meinung und ein Informatiker sollte schon erkennen, dass >> 4 = /16 oder &1 = %2 wenn er das nicht erkennt, kann er eh nicht gut genug programmier, um komplexere Dinge zu modellieren.

Außerdem ao, schau dir mal meinen Post genau an:
Habe ich da nicht gesagt, dass man immer /16 schreiben kann (und sollte)?

Ach so, nenne mir bitte eine Maschine wo Division nicht signifikant langsamer ist als eine Shiftoperation...
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
014
30.09.2003, 11:03 Uhr
ao

(Operator)



Zitat:
virtual postete
Im Allgemeinen gebe ich recht, im Speziellen solte man sich aber an der Semantik orientieren, die man versucht zum Ausdruck zu bringen. Hier kann es Sinn machen, dem >>/<< Operatoren den Vorzug zu gewähren, zB:

C++:
class VersionTag
{
     unsigned long m_nVersionTag;
public:
     ...
     unsigned getMajor() const { return m_nVersionTag>>24; }
     unsigned getMinor() const { return (m_nVersionTag>>16)&0xff; }
     unsigned getPatchLevel() const { return m_nVersionTag&0xffff; }
};

Hier soll zum Ausdruck gebracht werden, daß in m_nVersionTag einzelne Bitgruppen bestimmte Eigenschaften repräsentieren. Analoges Beispiel wäre eine Farbe, deren Farbwert als RGB Wert in einem long gespeichert wird.


Ich schrieb oben, man soll das kodieren, was man meint. Hier ist tatsächlich ein Schieben gewollt, und dann gehört der >>-Operator da auch hin. Hier wäre die Division die Verschleierung.

ao
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
015
30.09.2003, 11:27 Uhr
ao

(Operator)



Zitat:
~(un)wissender postete
Na, da sind aber einige Leute anderer Meinung

Die können sich gerne melden und dagegen argumentieren.

Mein Ansatz ist: Auf Quelltextebene geht Klarheit und Lesbarkeit über alles. Um Geschwindigkeit soll sich der Compiler kümmern. Ausnahmen sind nur zulässig unter den Bedingungen, die ich genannt habe.

Zitat:

und ein Informatiker sollte schon erkennen, dass >> 4 = /16 oder &1 = %2 wenn er das nicht erkennt, kann er eh nicht gut genug programmier, um komplexere Dinge zu modellieren.

Ist das dein Qualitätskriterium für Informatiker?

Zitat:

Außerdem ao, schau dir mal meinen Post genau an:
Habe ich da nicht gesagt, dass man immer /16 schreiben kann (und sollte)?

Du hast oben geschrieben, dass man nur dann dividieren soll, wenn der
Compiler einen Shift draus macht. Und darauf bezog ich mich.

Zitat:

Ach so, nenne mir bitte eine Maschine wo Division nicht signifikant langsamer ist als eine Shiftoperation...

Ich kenne keine. Aber deshalb würde ich nie behaupten, dass es keine gibt, sondern immer davon ausgehen, dass der Compiler wahrscheinlich weiß, was für die Target-CPU gut ist.

ao
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
016
30.09.2003, 12:15 Uhr
~(un)wissender
Gast



Zitat:

Ist das dein Qualitätskriterium für Informatiker?



Jupp, eines von vielen (die ich vielleicht auch nicht alle erfülle), wobei die eigentlich nicht von mir kommen :-)!


Zitat:

Um Geschwindigkeit soll sich der Compiler kümmern.



Das ist deine Ansicht.

Versteh mich nicht falsch, ich LIEBE guten Code und bemühe mich auch ihn selbst zu schreiben, aber Performance gehört halt auch zu gutem Code, da kann man sicherlich einiges dem Comiler überlassen, aber sicherlich NICHT alles.
Was nutzt dir die tolle Lesbarkeit eines Bubblesorts, wenn 1.000.000 Datensätze sortiert werden sollen?
(Ok, ist unfair, ich weiß, und ja, virtual, man nimmt die STL)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
017
30.09.2003, 13:16 Uhr
ao

(Operator)



Zitat:
~(un)wissender postete
Was nutzt dir die tolle Lesbarkeit eines Bubblesorts, wenn 1.000.000 Datensätze sortiert werden sollen?

Natürlich ist es in Ausnahmefällen erlaubt, Schweinecode zu schreiben, wenns um Geschwindigkeit, Speicher-Effizienz oder sonst was geht. Das hab ich auch in Posting 011 in diesem Thread bereits geschrieben.

Aber die Ausnahme muss *begründet* sein. Und die Begründung kann nur ein konkret nachgewiesener Performancegewinn im Applikationskontext (d.h. nicht an einer isolierten dreizeiligen Routine) sein. Man muss also reale Programme messen und vergleichen und kann nicht auf irgendwelche Befehlszyklen-Angaben im CPU-Handbuch verweisen.

ao
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
018
30.09.2003, 17:00 Uhr
~(un)wissender
Gast


Ich glaube wir habe da auf den letzten Prozenten eine etwas unvereinbare Meinung.
Ich gebe Performance eine ziemlich wichtig Rolle, denn nichts nervt mich mehr als ein langsames Programm.
Die Art des Programmierung hängt sicherlich auch etwa davon ab, wer den Code liest und wer ihn schreibt, wenn ich weiß, dass ich und mein Kumpel die einzigen sind, die daran arbeiten und wir ihn auch nicht groß warten wollen, dann kann man schon mal ein bißchen schludern.
In der Firma mit vielen Leuten ist sowas absolut inakzeptabel.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: [ 1 ] > 2 <     [ C / C++ (ANSI-Standard) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: