Mein Coding Blog, Wiener-Würstchen-Niveau, C++11, Optimierung, etc...

knivil

Es gibt einen Unterschied zwischen Codieren und Code schreiben (programmieren). Ich nehme an, du meinst letzteres. Demnach solltest du auf codieren ganz verzichten, wenn du weder ueber Datenuebertragung oder Verschluesselung redest. "Meta-Template-Codierung" klingt schon falsch. Bei "Codiere so explizit wie möglich" fasse ich mir einfach nur an den Kopf.

Explizite Typumwandlungen bei primitiven Typen wie

float l_Number1Point6 = 1.6f;
int l_Number = (int)l_Number1Point6; // What is now in l_Number?

finde ich jetzt nicht schlimm. Aber vielleicht mag mich jemand eines besseren belehren. Dagegen finde ich deine Namensgebung ... seltsam. Wichtig bei solchen Sachen/Regeln ist es, den Grund anzugeben. Warum? Einfach "schlimm" schreiben reicht mir nicht.

Gero_Programmierstil_de

danke fürs feedback!

das mit codierung als falsches synonym für programmieung hat sich bei mir irgenwann sprachlich ma eingeprägt. hast natürlich recht. thx!

pyhax

Sieht ganz ok auf, bloß du solltest ein etwas mehr auf Rechtschreibung / Tippfehler achten.

PS: Im Titel dieses Threads steht Blong :p

Gero_Programmierstil_de

knivil schrieb:

Explizite Typumwandlungen bei primitiven Typen wie
float l_Number1Point6 = 1.6f;
int l_Number = (int)l_Number1Point6; // What is now in l_Number?

Vielleicht ist es nicht das beste Beispiel, vielleicht sollte ich meine Gründe auch noch genauer erläutern.
Ich habs darum gewählt, weil man ohne weitere Hinweise vielleicht meinen könnten, das sich nun eine 2 in l_Number befindet. wegen der Rundung etc..
passt da nich so gut rein, ich werds nochma überarbeiten.

Dagegen finde ich deine Namensgebung ... seltsam. Wichtig bei solchen Sachen/Regeln ist es, den Grund anzugeben. Warum? Einfach "schlimm" schreiben reicht mir nicht.

OK! thx! ich werd den beitrag überarbeiten.

pyhax schrieb:

Sieht ganz ok auf, bloß du solltest ein etwas mehr auf Rechtschreibung / Tippfehler achten.

OK! THX!

http://www.programmierstil.de/message/Optimierung_von_prozeduralen_Programmcode_(Teil_2)/7.html

was soll man dazu außer - bitte nicht nachmachen - noch sagen

http://www.programmierstil.de/message/Optimierung_von_prozeduralen_Programmcode_(Teil_2)/7.html schrieb:

Die 2,3 Kilo-Byte Speicher sind quasi nix.

ich hab schon wieder das keyword übersehen

ich weiß, dass du dir damit eine menge mühe gegeben hast. daher hab ich mir auch die zeit genommen, das anzuschauen.

ich denke es war für dich eine ganz gute übung. aber, und nimm mir das jetzt nicht übel, ich hoffe, dass anfänger aus besseren texten lernen, weil das ganz entscheidenden einfluss auf die spätere qualität hat, die wir für die zukunft gut gebrauchen können.

wir haben alle mal klein angefangen und aus erfahrung kann ich dir sagen, dass wenn man sich etwas anfangs 'falsch' aneignet, diese 'fehler' wenn überhaupt nur sehr schwer auszubügeln sind.

Cyres

steht zwar "ignorieren" drüber, aber worauf willst du bei "Copy-Construktor+Destruktor = Move Constructor" hinaus? oO

hustbaer

Gero_Programmierstil_de schrieb:

Das Niveau ist Fall recht hoch angesiedelt.

Das Niveau ist eher "Anfänger der mal anfängt ein Blog zu schreiben weil er meint bestimmte Dinge so gut verstanden zu haben dass er es jetzt der Welt mitteilen will".
(BTW: Ich vermute dass hier ein "auf jeden" in dem Satz fehlt, sonst macht der für mich nämlich keinen Sinn. Falls nicht klär mich bitte auf.)

Gero_Programmierstil_de schrieb:

Vielleicht schaut der ein oder andere mal rein.

Ich hab mir nur mal die beiden Einträge Optimierung von prozeduralen Programmcode (Teil 1) und (Teil 2) angesehen. Dazu ein paar Kommentare:

Man sollte dem Compiler so viel mitteilen über das, was man machen möchte, wie nur irgentwie möglich.
Je mehr der Compiler wirklich genau "weiss" über den zu übersetzenden Code, und je weniger er raten muss, desto mehr Optimierungsspiel-raum hat er dann auch. Explizit geht immer über implizit.

Sorry, aber Unsinn. Der Compiler muss nie raten. Sämtliche mir bekannten Programmiersprachen definieren in jedem Fall genau was zu passieren hat. Auch bei sog. "impliziten" Konvertierungen o.Ä.
Einen expliziten Cast irgendwo zu schreiben, wo die selbe Konvertierung auch implizit erfolgen würde, bringt - was Performance angeh, und um die geht es dir ja wie du schreibt - genau gar nix.

Dieser Punkt erstreckt sich über ziemlich viel. Und da kann man natürlich gewaltig viel falsch machen.
Man sollte möglichst genaustens Bescheid wissen, welche Sicht auf den Code der Compiler hat.

Ja, man sollte eine Sprache immer möglichst gut beherrschen wenn man programmieren will.

Datentypen

Man sollte sich beim Umgang mit Daten so weit einschränken wie möglich, aber so wenig wie nötig.
Und jede dieser Einschränkungen muss man dem Compiler natürlich auch genaustens mitteilen.
Die Standart-Datentypen und deren Werte-Bereiche sollten ja allgemein bekannt sein.
(...)
Am besten ist immer, man hat sich seine eigenen integralen Datentypen ge-typedef't und verwendet ausschliesslich diese.
Bei mir heissen sie UINT8, UINT16, UINT32, UINT64, SINT8, SINT16, SINT32, SINZ64, usw..

Newsflash: auf den meisten Plattformen spielt es keine Rolle ob man mit nem int oder short oder gar char rechnet. Alles gleich schnell.

Und was die Typedefs angeht... da gibt's bei C und C++ ne nette Header namens <stdint.h> bzw. <cstdint>, und da drinnen werden int8_t, int16_t ..., uint8_t, uint16_t ... definiert. Eigene Typen definieren ist nicht nötig. Und sollte man auch auf jeden Fall immer nur in einem eigenen Namespace machen.

Der Grund warum diese Typedefs Sinn machen steht auch nicht dort: C und C++ definieren nämlich nur Mindestanforderungen an den Wertebereich, nicht den genauen Wertebereich. Die intN_t/uintN_t Typen haben dagegen, wenn es sie gibt, immer exakt N Bit. Schlimmer noch, der Satz "Die Standart-Datentypen und deren Werte-Bereiche ..." legt nahe dass der Standard einen exakten Wertebereich für jeden Standardtypen festlegen würde - was eben nicht so ist.

Const-Correctness
Const-Correctness muss in diesem Zusammenhang natürlich genannt werden.
Wenn ich in einer Funktion eine Variable rein bekomme, welche ich nur auslese, aber nicht verändere, dann sollte das auch der Compiler wissen, auch wenn er vielleicht davon ausgehen könnte (niemals darauf verlassen).

Ist es vielleicht das, dass du hier nicht erklärst was "const correctness" überhaupt bedeutet, was du mit "hohes Niveau" meinst? Ich sehe das eher als schwäche.
Und Newsflash: const ermöglicht nur in den wenigsten Fällen zusätzliche Optimierungen. Selbst wenn der Compiler (warum auch immer) nicht inlinen kann kann er mit const meist nicht mehr optimieren als ohne. Was const für UDTs (user defined types) bedeutet ist nämlich nicht so klar, das entscheidet der Programmierer.
Wenn der Compiler die Implementierung einer "const" Memberfunktion nicht sieht, dann kann er auch nicht davon ausgehen dass diese keine Membervariablen verändert. Genau so wenig wie er davon ausgehen kann dass eine Funktion die einen const T* Parameter nimmt das Objekt auf das der Zeiger zeigt nicht verändert.
Was eingebaute Typen angeht gibt es einige Ausnahmen wo doch was geht, aber grundsätzlich eignet sich const nicht zur Performance-Optimierung, sondern nur zur Verständlichkeits-Optimierung.

Typumwandlung aka casting
Casting is eigentlich sehr "böse", und sollte immer mit viel Bedacht eingesetzt werden.
Niemals sollte man casten, wenn man nicht genau weiss was passiert.

Erst schreibst du so explizit wie möglich, und jetzt ist casten böse? Hm.
Kaum ein Programm wird auf Typumwandlungen verzichten können, d.h. es gibt diese Typumwandlungen auf jeden Fall. Ist jetzt deiner Meinung nach explizit oder implizit besser?
Davon abgesehen: die meisten Konvertierungen sind mehr oder weniger gratis. Ausnahme sind Konvertierungen zwischen bool <-> nicht_bool und float/double <-> nicht_float_oder_double .

float l_Number1Point6 = 1.6f;
int l_Number = (int)l_Number1Point6; // What is now in l_Number? 1 or 2?

Dass du hier eine total eigenwillige (=ungewöhnliche=selten anzutreffende=verwirrende) Benamsung verwendest wurde ja schon erwähnt.

Diese Funktion soll den 8-Bit Wert inByte in die entsprechende dezimal Darstellung umwandeln und zurückgeben (ASCII und statisch gespeichert).
Wir gehen hier davon aus, dass das input-Byte immer komplett interpretiert wird.
Also zum Input-Byte 0 kommt der Output-String: "00000000" raus.
Für 1 -> "00000001", usw.

dezimal == binär ?

Die POSIX-CRT Funktion, die dem am nächsten kommt, kennt man: char *itoa (int value, char * str, 10); (definiert in stdlib.h)
Sie gehört allerdings nicht zum ANSI-C standart und ist higly-deprecated.
Wenn überhaupt, nimmt man gleich printf() oder itoa_s().

WTF?
* Wo ist itoa bitte deprecated?

printf ist kein Ersatz für itoa (wenn dann sprintf , aber auch das ist kein direkter Ersatz)
itoa_s ist schon gleich überhaupt kein Standard. Wenn du also bekrittelst dass itoa nicht ANSI C ist (k.A. ob das stimmt, ist auch egal, weil itoa überall verfügbar ist), dann solltest du itoa_s nicht als "Ersatz" erwähnen.

Stufe 1: Wenig Speed, wenig Size
(...)
Diese Funktion ist die optimalste, wenn man in Richtung Size optimieren will.

Frage: weisst du was eine Schleife ist?

Stufe 2: Viel Size, Viel Speed
Kommen wir nun zur schnellsten Implementierung:
(...)
Und nur eine einzige Table Lookup-Operation ist nötig: return s_Results[inByte];

Also... ob das die schnellste Implementierung ist sei mal dahingestellt. Der grosse Table kann den Cache ganz schön zumüllen. Könnte leicht Programme/Plattformen geben wo die Nibble-Variante schneller ist.
Und BTW: s_Results[inByte] ist aus CPU-Sicht kein Table-Lookup (du speicherst ja keine Zeiger auf die Strings sondern direkt die Strings in dem Array), sondern einfach nur ne Multiplikation + Addition (als optimierter Code fliegt die Multiplikation vermutlich sogar raus, ein einziger "LEA" Befehl sollte bei x86 ausreichen wenn ich mich recht erinnere).

Stufe 3: Viel Size, Viel Speed, aber Null-Byte sparen (...)

Pack ich grad gar nicht. Das ist so ziemlich die sinnloseste Implementierung die ich mir vorstellen kann. Hast du nicht geschrieben es gibt "aus Programmiersicht exakt 4 wirklich sinnvolle Optimierungs-Stufen zwischen Speed und Size"? Also sinnvoll ist diese "Stufe" ganz sicher nicht.

Auf modernen PC's mit Gigabytes an Speicher sollte Stufe 2 verwendet werden.
Die 2,3 Kilo-Byte Speicher sind quasi nix.

Und welche Version verwenden wir auf modernen PCs mit 32 kB 1st Level-Cache?

-----------------------------------------------------------------

Fazit: ein Haufen Gebrabbel mit kaum lesenswerten Informationen (und schlechter Rechtschreibung nebenbei). [cyn]Ganz klar "heads niveau", ja.[/cyn]

Wenn du das ganze unter dem Motto "ich entdecke gerade C++, und schreibe hier einige meiner Gedanken nieder, die ich grad für sinnvoll halte, die aber auch totaler Quatsch sein könnten" bringen würdest, dann wäre es OK.

So wie du es versucht zu verkaufen ... "guckt mal her dann zeig ich euch wie man das richtig macht" ... sorry, aber ne.

Swordfish

Also falls irgendwem nen Fehler aufällt und es nich um Rechtschreibung geht, bitte sofort kommentieren (auch bei kleineren Begrifflichkeits-Fehlern).

Na, dann geh'n ma mal die "kleineren Begrifflichkeits-Fehler" [sic!] suchen ...

cooky451

Ack hustbaer, ich war offen gesagt nur zu faul den ganzen Kram zu schreiben und hab es dann bleiben lassen.

Gero_Programmierstil_de

thx fürs feedback, hab mir auch schon gedacht, dass "heads-niveau" vorallem hier hier bestimmt aneckt.

vielen dank an hustbaer.

...

hast recht. auf jeden. .
danke.

ein paar kurze anmerkungen und fragen:
ito war leider nie iso-definiert. meine schlussfolgerungen sind natürlich quatsch.
wegen schleife: wollt das mit dem ausrollen übergehen/ausklammern. vor allem, weil ich am ende die operationen runterbete.
was ich mich grad noch frag: ist table lookup nicht doch die richtige bezeichnung aus nächst höherer abstraktion zu assembly?

ich überarbeite den teil, es wär wirklich sehr nett, wenn du das dann nochma anschaun könntest.

DocShoe

Verschwendung von Zeit und Webspace.

- Themen werden nur oberflächlich angekratzt, ohne in´s Detail zu gehen. Damit haben sie praktisch keine Relevanz und bringen den Leser nicht weiter.
- subjektiver, fürchterlicher Schreibstil. Seriöse Fachliteratur sollte sachlich und neutral formuliert werden, ohne Kraftausdrücke und/oder Leetspeak.

Ich glaube, du überschätzt dich und dein C++ Wissen.

hustbaer

Gero_Programmierstil_de schrieb:

ich überarbeite den teil, es wär wirklich sehr nett, wenn du das dann nochma anschaun könntest.

Wie DocShoe schon geschrieben hat: ist vermutlich Verschwendung von Lebenszeit - deiner und der anderer (die deine Seite finden und lesen).

Erklären sollten Leute die a) das Thema wirklich gut verstanden haben und b) gut erklären können.
Leider bleiben nur sehr wenige Leute übrig die das für ein bestimmtes Thema erfüllen, weswegen es auch so wenig gute Erklärungen gibt. Die Frage ist aber, ob eine weitere schlechte bis max. mittelmässige Erklärung zu irgen deinem Thema was bringt.
Ich vermute nein.

Geh lieber baden/fussballspielen/laufen/...
Oder, wenn du dich unbedingt mit Programmierung beschäftigen willst, lerne erstmal noch ein wenig statt zu versuchen zu lehren.

hustbaer

Gero_Programmierstil_de schrieb:

was ich mich grad noch frag: ist table lookup nicht doch die richtige bezeichnung aus nächst höherer abstraktion zu assembly?

Ja, stimmt schon.
Das ist so ziemlich der sinnloseste/unwichtigste meiner "Kritikpunkte".
Mir ist nur aufgefallen dass an der Stelle eigentlich strenggenommen noch kein Table-Lookup passiert, sondern wie gesagt bloss eine Adresse berechnet wird.

knivil

Vor allem wenn es um Speed vs Size geht, sollten doch einige Performancemessungen gemacht werden. Da man sich natuerlich fragt, wieviel besser denn Methode A im Vergleich zu Methode B ist. Generierter ASM-Code und Taktzyklen wuerde ich auch als Ersatz gelten lassen.

hustbaer

knivil schrieb:

Vor allem wenn es um Speed vs Size geht, sollten doch einige Performancemessungen gemacht werden. Da man sich natuerlich fragt, wieviel besser denn Methode A im Vergleich zu Methode B ist.

Ja. Wobei wirklich sinnvolle Tests leider nur in der Anwendung möglich sind.
Viele Dinge laufen für sich allein ganz toll, wenn sie den gesamten L1 Cache zur verfügung haben. Einiges davon läuft dann aber im Programm nicht mehr ganz so toll.

Generierter ASM-Code und Taktzyklen wuerde ich auch als Ersatz gelten lassen.

Echt?

Also ich nicht.
Taktzyklen-Angaben sind mittlerweile nicht mehr sinnvoll möglich, ausgenommen man hat ein brandaktuelles Tool eines CPU Herstellers. Und selbst da würde ich mich eher auch Messungen verlassen.

Die Zeiten eines 68K wo man einfach zusammenzählen konnte sind halt vorbei...

Gero_Programmierstil_de

Seriöse Dokumentation soll das natürlich nicht werden.
das ganze ist natürlich eher für mich und für paar kollegen. Ich lern dadurch ne Menge.
Der Rest findet sich, is ja auch erst 2 wochen alt, das ganze.
Ich kann auch gut genug über arroganz und sarkasmus in konstruktiver kritik hinwegsehen und das konstruktive dann nutzen. arroganz sei den high-skill-leuten auch gegönnt.
das niveau der bisherigen artiekl sind für das forum hier natürlich eher niedrig, gar provokativ.

So, genug dazu.
@hustbaer: danke für deine zeitverschwendung.

performance-messung: kommt doch immer auf den anwendungszweck der funktionalität an, ich find landau-symbolik und auseinandergenommene operationen bis kurz vor assembly-level eigentlich immer aussagekräftiger.

dot

Selten dass jemand hier mit Kritik auf derart konstruktive Art umzugehen weiß, dafür ein ehrliches von mir...

Gero_Programmierstil_de schrieb:

performance-messung: kommt doch immer auf den anwendungszweck der funktionalität an, ich find landau-symbolik und auseinandergenommene operationen bis kurz vor assembly-level eigentlich immer aussagekräftiger.

Landau-Symbole sind zwar theoretisch schön und gut, sagen aber erstmal gar nichts über reale Performance auf realer Hardware aus. In der Praxis kommt es sehr oft, wenn nicht sogar meistens gerade auf die Konstanten an, die dort unterschlagen werden. Wenn n nicht sehr groß ist, dann schlägt eine stupide lineare Suche auf einer modernen CPU den fanciest Suchbaum mit Abstand, weil die Datenstruktur dafür kompakter gehalten werden kann. Und ich hatte auch selber schon mit Fällen zu tun wo man mit Insertion Sort um Größenordnungen schneller war als mit Quicksort...

Cyres

Gero_Programmierstil_de schrieb:

das niveau der bisherigen artiekl sind für das forum hier natürlich eher niedrig, gar provokativ.

Das hat mit dem Niveau des Forums herzlich wenig zu tun.