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

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

  • ?

    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.

    0
  • C

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

    0

  • 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.

    0

  • 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 ... 😃

    0
  • C

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

    0
  • G

    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.

    0

  • 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.

    0

  • 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.

    0

  • 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.

    0
  • K

    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.

    0

  • 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...

    0
  • G

    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.

    0

  • 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...

    0
  • C

    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.

    0
  • M

    Was heißt denn überhaupt "heads niveau"? Wenn ich das bei Google eingebe, ist dieser Thread hier der erste Treffer.

    0
  • C

    Den Begriff habe ich vorher auch noch nie gehört, soll wohl ein hohes Niveau voraussagen, was ja auch schon angesprochen wurde (Achja, Niveau ist übrigens keine Hautcreme, so wirkt es nämlich bei dem Blog *hüstel* 🕶 )

    0

  • Scheint rap-verseuchte Jugendsprache für "sehr gut" zu sein, hab's mir aber auch erst ergoogeln müssen. Und bis auf Texte wo die Bedeutung im Zusammenhang dann mehr oder weniger klar wird hab ich auch nix gefunden.
    Mich würde auch die Etymologie interessieren.

    Ich rate mal: kommt vom englischen "heads" (Hauptwort) - entweder mit der Bedeutung "Chefleute" oder evtl. auch (weniger wahrscheinlich) mit der Bedeutung "erstes Destillat" bzw. "reines Zinnerz".
    Würde dann entweder bedeuten "gut genug für die Chefetage" bzw. eben "so gut wie das erstes Destillat/reines Zinnerz".
    Macht beides irgendwie Sinn.

    Wobei die Kombination des deutschen (*kicher*) Niveau mit dem englischen "heads" irgendwie komisch ist. Wenn schon dann "heads level".

    EDIT:
    Achjeh...

    "heads" wird anscheinend auch gerne kurz für "hip-hop heads" verwendet (Hip-Hop Fans halt, analog zu "metal heads"), bzw. auch kurz für "potheads", bzw. allgemein als bezeichnung für eine Gruppe von Leuten.

    Wobei von den dreien eigentlich nur "hip-hop heads" Sinn macht. Was sich dann auch mit der - anhand der Fundstellen der Phrase vermuteten - Hip-Hop- bzw. Rap-Affinität gut vertragen würde.
    (Was man ja von meiner pre-EDIT Vermutung nicht so wirklich behaupten kann).

    0
  • B

    hustbaer schrieb:

    Wenn schon dann "heads level".

    level-headed heißt aber wieder was ganz anderes...

    0
  • G

    Etymologie: "head" für das körperteil kopf, halt oben.

    ich kenns den begriff hauptsächlich aus älteren weniger bekannten boards, für die leute, die halt länger dabei sind.
    der begriff "oldfag" hat das dann abgelöst (4chan).
    definitiv umgangssprachlich/hiphop-lastig.

    0
  • K

    Hier wid hauptsaechlich Deutsch geschrieben. Mit Slang beeindruckst du niemanden.

    0
Anmelden zum Antworten