Geschwindigkeit einiger Operationen

hustbaer

im endeffekt ist vollkommen egal was schneller ist
BTW: ein guter compiler wird bei unsigned typen und bool den gleichen code erstellen...

Senfer schrieb:

Hab aber gerade einen Performancetest gemacht:

Wenn Du Windows hast und Deine Entwicklungsumgebung das unterstützt, kannst Du das auch kurz machen:
#include <cstdlib> 
#include <iosteam>

#include <windows.h>

using namespace std;

int main(int argc, char *argv[])
{
   int iGrenze = 100000000;

   DWORD dwStart1 = 0;
   DWORD dwStart2 = 0;
   DWORD dwStop1 = 0;
   DWORD dwStop2 = 0;

   bool x = false;

   dwStart1 = GetTickCount();

   for(int i = 0; i < iGrenze; i++)
      x = (i > 0);

   dwStop1 = GetTickCount();
   dwStart2 = GetTickCount();

   for(int i = 0; i < iGrenze; i++)
      x = (i == 0);

   dwStop2 = GetTickCount();

   cout << "Test 1: " << dwStop1 - dwStart1 << endl;
   cout << "Test 1: " << dwStop2 - dwStart2 << endl;

}
Das kannst Du ein paar mal machen, kommt aber immer raus, dass das untere um ca. ein fünftel schneller ist.

(hoffe, ich hab den Code richtig abgetippt, war nämlich auf dem anderen Rechner )

Bitte mach den Debugmodus aus.
Da kannst du garnix messen, weil dir ein vernünftiger Compiler das mit x alles weg optimiert, weil du es garnicht verwendest und deine iGrenze konstant ist.

Das ist wieder mal so ein premature microoptimierungs gescheiße hier.

volkard

Ihr seid so schlecht schrieb:

Das ist wieder mal so ein premature microoptimierungs gescheiße hier.

ach, das wort "premature" lese ich hier oft. ist das nicht seltsam?
die hardware kennenzulernen und zu lernen, was ein compiler so kann, das ist doch etwas im allerhöchsten maße positives.

volkard schrieb:

ach, das wort "premature" lese ich hier oft. ist das nicht seltsam?

Ne, nicht seltsam, ganz normal, dass das hier immer wieder gemacht wird, bei so vielen Anfängern

die hardware kennenzulernen und zu lernen, was ein compiler so kann, das ist doch etwas im allerhöchsten maße positives.

ja, aber wieso meinen dann immer noch so viele, dass sie es besser können als der Compiler? Wartbaren und leicht zu erweiternden Code zu schreiben ist so gut wie immer wichtiger, als solcher kleinscheiß, wie < vs. ==...

volkard

Ihr seid so schlecht schr schrieb:

ja, aber wieso meinen dann immer noch so viele, dass sie es besser können als der Compiler?

weil ihnen keiner zeigt, wie geil heute die compiler sind, sondern im gegenteil: wenn sie ein wenig forschen wollen, sofort mit der premature keule eins übergezogen bekommen.

Wartbaren und leicht zu erweiternden Code zu schreiben ist so gut wie immer wichtiger, als solcher kleinscheiß, wie < vs. ==...

und erzeugt sogar schnelleren code, denn oft kann man noch sehr spät seinen algorithmus tunen, zum beispiel durch auswahl einer besser angepaßten datenstruktur oder durch herauswerfen von ein paar sonderfällen. und das geht um so besser, je einfacher und klarer der code ist. aber welcher kleinscheiß ist gut und welcher böse? die doppelt verkettete liste zu tunen, daß sie zum ring wird, dabei das root-element als leeres pseudo-existent zu halten, und ruck zuck in der gesamten klasse ganz ohne fallunterscheidung auszukommen, ist was tolles. auf der jagt nach einem kleinen harmlosen if, om das loszuwerden, nur weils manchmal 13 strafzyklen kostet, eröffnet sich plötzlich das zaubertal der verketteten ringe. wie gut, daß ich gesucht habe und mich nicht davon abhalten ließ.

volkard schrieb:

aber welcher kleinscheiß ist gut und welcher böse?

Scheißegal, das muss man nicht wissen. Wenn das Programm fertig ist und es sich rausstellt, dass es irgendwo zu langsam ist, nimmt man einen Profiler und findet damit die richtig große Scheiße im Code und die wird dann aufgeräumt und das geht fast immer indem man irgend ein O(n) in O(log(n)) oder ähnliches umbaut. Wenn du vorher optimierst, dass sich ein Dialog nicht in 116ms sondern in 83ms öffnet, dann interessiert das keinen. Wenn aber ein User oder Tester kommt und sagt, dass er nicht immer eine Minute warten will bis die Datei geöffnet ist und du machst daraus 20 Sekunden, dann bringt das was. Vor einigen Jahren fand ich so kleinkram auch noch wichtig, bis ich dann irgendwann richtig produktiv eingesetzen Code optimiert hab. Es ehißt zwar, kleinvieh macht auch Mist, aber wenn der Compiler bereits den Mist weg räum oder wenn er sowieso wo liegt wo es keinen stört, dann ist es premature optimization. Aber ob was stört, sieht man meistens erst wenn das Programm fertig ist. Das bedeutet jetzt nicht, dass man nicht gleich nen besseren Algorithmus verwenden kann, wenn man ihn kennt, aber < oder == ist kein Algorithmus, sondern Kleinscheiß.

volkard

was genau hast du an meinem letzten posting nicht verstanden?

Shade Of Mine

Ihr seid so schlecht schrieb:

volkard schrieb:

aber welcher kleinscheiß ist gut und welcher böse?

Scheißegal, das muss man nicht wissen.

Nicht alles was man tut ist zwangslaeufig produktiv auf ein fertiges Produkt abgeziehlt.

In der Tat ist es so, dass das ja Codemonkeys von Programmierern unterscheidet. Wenn du immer nur geziehlt das Programm fertig bekommen willst, dann lernst du dabei einfach nichts und entwickelst dich nicht weiter.

Deshalb ist es genauso wichtig diese Spielereien zu machen die nichts bringen ausser eben Erkenntnis, wie Meyers, Sutter, etc. zu lesen. Sonst entwickelt man sich ja nicht weiter. Viele Leute wollen das zwar nicht, aber das merkt man dann auch wenn man mit solchen Leuten dann zusammen arbeiten muss.

Ein gesundes mass an Neugier ist essentiell wenn man ein guter Programmierer werden will (das fuehrt dann ja auch dazu dass man ueber den Tellerand sieht und andere Sprachen mit anderen Konzepten lernt).

volkard schrieb:

was genau hast du an meinem letzten posting nicht verstanden?

Was für dich premature optimization ist und was nicht.

Shade Of Mine schrieb:

Ihr seid so schlecht schrieb:

volkard schrieb:

aber welcher kleinscheiß ist gut und welcher böse?

Scheißegal, das muss man nicht wissen.

Nicht alles was man tut ist zwangslaeufig produktiv auf ein fertiges Produkt abgeziehlt.

In der Tat ist es so, dass das ja Codemonkeys von Programmierern unterscheidet. Wenn du immer nur geziehlt das Programm fertig bekommen willst, dann lernst du dabei einfach nichts und entwickelst dich nicht weiter.

Deshalb ist es genauso wichtig diese Spielereien zu machen die nichts bringen ausser eben Erkenntnis, wie Meyers, Sutter, etc. zu lesen. Sonst entwickelt man sich ja nicht weiter. Viele Leute wollen das zwar nicht, aber das merkt man dann auch wenn man mit solchen Leuten dann zusammen arbeiten muss.

Ein gesundes mass an Neugier ist essentiell wenn man ein guter Programmierer werden will (das fuehrt dann ja auch dazu dass man ueber den Tellerand sieht und andere Sprachen mit anderen Konzepten lernt).

Neue Konzepte sind was ganz anderes als < vs. ==.

Shade Of Mine

Ihr seid so schlecht schrieb:

Neue Konzepte sind was ganz anderes als < vs. ==.

Nein.
Denn < vs == ist ebenfalls ein Konzept, oder besser eine Ausprägung eines Konzeptes: nämlich der Maschinennahen Programmieren.

Muss man es wissen? Nein. Ist genauso wie Funktionale Programmierung, die muss man auch nicht kennen. uU bringt es einem mal etwas, aber worum es geht ist Wissen zu erweitern und es gibt kein unnötiges Wissen.