cout langsamer als printf?



  • Warum ist cout langsamer als printf? Wegen der locales? Kann man das irgendwie ändern?



  • Wie hast du festgestellt, dass es langsamer ist?



  • die C++-Streams sind allgemein langsamer als ihre C-Derivate, aber sicherer, durch die Operatoren-Überladung usw. gibt es weniger Optimierungspotenzial und es gibt mehr Puffer zwischen den Schichten

    http://stackoverflow.com/questions/18688763/why-is-istream-ostream-slow
    http://stackoverflow.com/questions/4340396/does-the-c-standard-mandate-poor-performance-for-iostreams-or-am-i-just-deali



  • Evtl. flushst du auch (unabsichtlich) bei jeder Benutzung std::cout durch ein std::endl?



  • Objektorientierung ist generell langsamer, hat dann aber den Vorteil, dass die Programmcodes deutlich kürzer und sicherer werden.

    Aber alles, was mit IO zu tun hat, ist von sich aus schon so langsam, dass es dabei gar nicht auf die Geschwindigkeit ankommt.



  • HansKlaus schrieb:

    Objektorientierung ist generell langsamer

    Soso



  • Objektorientierung ist generell langsamer

    Soso - generell



  • dfsfds schrieb:

    Warum ist cout langsamer als printf? Wegen der locales?

    Bei den Implementierungen die ich kenne: ja, wegen den Locales.

    dfsfds schrieb:

    Kann man das irgendwie ändern?

    Du kannst Funktionen verwenden die sich nicht für Locales interessieren und/oder direkt in den Stream-Buffer schreiben.



  • HansKlaus schrieb:

    Objektorientierung ist generell langsamer

    Nein

    HansKlaus schrieb:

    Aber alles, was mit IO zu tun hat, ist von sich aus schon so langsam, dass es dabei gar nicht auf die Geschwindigkeit ankommt.

    Ganz schlimmer Quatsch. Versuch' mal mit IOStreams nen riesen Textfile zu lesen oder zu schreiben. Also schön Stück für Stück, so wie man es in allen Beispielen sieht. Dann guck dir an auf wieviel MB/s du damit kommst. Und dann guck dir an wieviel MB/s nen gutes Storage bei linearen Zugriffen schafft (kleiner Tip: so 1000 MB/s ist kein Problem). Oder auch eine einzelne SSD.



  • HansKlaus schrieb:

    Objektorientierung ist generell langsamer

    objektorientierung ist ein konzept. konzepte haben keine geschwindigkeit



  • hustbaer schrieb:

    HansKlaus schrieb:

    Aber alles, was mit IO zu tun hat, ist von sich aus schon so langsam, dass es dabei gar nicht auf die Geschwindigkeit ankommt.

    Ganz schlimmer Quatsch.

    I/O ist definitiv sehr oft ein flaschenhals. in der realität jedenfalls.



  • .. schon wieder so'n leidige Geschwindigkeitsdiskussion.
    Hier ein Thread, der sich um das selbe Thema dreht. Der OP kam mit einer >100MB-Datei von 12,5s auf 1,12s runter. Mit ziemlich viel Tricks, aber alles C++-Std-IO. Die 1s+ entsprachen exakt der Zeit, die ich in meinem Benschmark benötigt habe, um die Daten von der Platte in das Memory zu schieben. Wenn ein Programm richtig ausgelutscht ist, schlägt irgendwann Software immer Hardware.

    HansKlaus schrieb:

    Objektorientierung ist generell langsamer, hat dann aber den Vorteil, dass die Programmcodes deutlich kürzer und sicherer werden

    Ich nehme mal an, es gibt gefühlt 1 Millionen Quellen im I-Net, wo genau dies behauptet wird. 👎
    Wenn man zwei Konzepte 'objektorientiert' gegenüber 'prozedural' überhaupt in Sachen Geschwindigkeit vergleichen will, dann liegt 'objektorientiert' vorn - und zwar weit vorn! Große Programme mit Millionen LOC bekommt man nur dann wirklich schnell, wenn man verteilt, parallelisiert und asynchron konzeptioniert. Und das geht bei so großen Dingern eben nur mit objektorientierten Ansätzen.

    Gruß
    Werner



  • verteilt, parallelisiert und asynchron geht bei großen Projekten nur mit OOP? Das ist ja interessant.



  • Werner Salomon schrieb:

    Wenn man zwei Konzepte 'objektorientiert' gegenüber 'prozedural' überhaupt in Sachen Geschwindigkeit vergleichen will, dann liegt 'objektorientiert' vorn - und zwar weit vorn! Große Programme mit Millionen LOC bekommt man nur dann wirklich schnell, wenn man verteilt, parallelisiert und asynchron konzeptioniert. Und das geht bei so großen Dingern eben nur mit objektorientierten Ansätzen.

    Zusatz: Auch auf nur einem Kern: Mehr Durchblick durch OO bringt nachher viel mehr inhaltliches Optimierungspotenzial.



  • "viel Optimierungspotential" bedeutet aber, daß es anfangs weit vom Optimum entfernt ist.

    Mit auf Seiteneffektarmut hin optimierten funktionalen Routinen kann man manche Problemstellung von Anfang an recht nahe am Optimum platzieren, so der verwendete Grundalgorithmus gute Parallelisierbarkeit aufweist.



  • versionsnummer schrieb:

    "viel Optimierungspotential" bedeutet aber, daß es anfangs weit vom Optimum entfernt ist.

    Jupp. Anfangs vom Optimum weit entfernt.

    Ich hab gewohnheitsmäßig jeden C-Progger im Programmierwettbewerb an die Wand gestellt in Sachen Performance. Ist ja auch logisch. Ich hatte bessere Verfahren am Start.

    Naja, theoretisch, wenn ich mir mehr Mühe geben würde, täte ich die Schlaubergeralgos auch in C oder Cobol gut zu formulieren finden. Vielleicht hätte ich in Delphi nur zum Jux ebenso abgeschnitten.

    Sorry für den Exkurs.
    Wenn man cout(und Konsorten) ein wenig schlank reimplementiert, wie ich das gerne (ebmedded angehaucht) tue, geht da so viel drüber wie die Hardware gerade noch erlaubt. Und sicher viel viel viel mehr als printf überhaupt packen kann. cout muss nicht zur Laufzeit nach Typen schauen.



  • versionsnummer schrieb:

    verteilt, parallelisiert und asynchron geht bei großen Projekten nur mit OOP? Das ist ja interessant.

    Wirtschaftlich betrachtet - ja genau. Theoretisch bekommt man es natürlich auch prozedural hin, aber frag nicht nach dem Aufwand. Ich hatte Mitte der 90'er viel mit so was zu tun. Solche Programme waren voll von Fehlern, schwer zu warten und suboptimal obendrein.

    versionsnummer schrieb:

    "viel Optimierungspotential" bedeutet aber, daß es anfangs weit vom Optimum entfernt ist.

    Genau - einfaches Beispiel:

    allocate ganz viel Speicher;
        readFile große Datei in den Speicher;
        parse mit superschnellen Parser über die Bytes;
    

    Diese Konstruktion ist bereits weit vom Optimum entfernt, da der Prozessor im mittleren Teil ' readFile große Datei in den Speicher ' kaum was zu tun hat. In dieser Zeit könnte man doch schon mal über die bereits gelesenen Bytes parsen ...

    versionsnummer schrieb:

    Mit auf Seiteneffektarmut hin optimierten funktionalen Routinen kann man manche Problemstellung von Anfang an recht nahe am Optimum platzieren, so der verwendete Grundalgorithmus gute Parallelisierbarkeit aufweist.

    ..?? kannst Du mal ein Beispiel geben.

    Gruß
    Werner


  • Mod

    volkard schrieb:

    Und sicher viel viel viel mehr als printf überhaupt packen kann. cout muss nicht zur Laufzeit nach Typen schauen.

    Das. ( s ) printf hat den theoretischen Nachteil, dass der Formatstring jedes mal neu interpretiert werden muss (wenn wir von Schleifen reden, auch in jedem Durchlauf). Dank Templates können wir eine saubere Syntax ohne Performance Defizite, aber dafür mit Typsicherheit genießen.

    Das Ganze gilt noch einmal fürs Extrahieren. Insofern verstehe ich nicht, was an C I/O grundsätzlich schnell oder überhaupt gut sein soll - nur weil IOStreams ein übertriebenes Design haben?



  • swapper schrieb:

    hustbaer schrieb:

    HansKlaus schrieb:

    Aber alles, was mit IO zu tun hat, ist von sich aus schon so langsam, dass es dabei gar nicht auf die Geschwindigkeit ankommt.

    Ganz schlimmer Quatsch.

    I/O ist definitiv sehr oft ein flaschenhals. in der realität jedenfalls.

    Es geht hier ums lineare Schreiben. Mit Pufferung. cout halt. Natürlich kann auch hier IO der Flaschenhals sein, aber dazu muss man sich schon gewaltig anstrengen. Zumindest wenn man mit entsprechender Hardware arbeitet. Und wenn man nicht mit entsprechender Hardware arbeitet, dann würde ich sagen dass die Hardware der Falschenhals ist, nicht allgemein "I/O".

    Um dagegen die Iostreams zum Flaschenhals zu machen muss man sich gar nicht anstrengen. In der Realität jedenfalls 🙄

    Dass im Allgemeinen - also nicht auf cout bezogen - IO oft der Flaschenhals ist, ist richtig. Es bringt aber nichts diese "Erkenntnis" blind auf jedes Problem "anzwenden". Weil halt oft != immer.



  • BTW: Kennt jemand eine C++ Library mit der man ähnliche Dinge wie mit den Iostreams machen kann, die richtig gut auf Performance optimiert ist?

    Ich hab' mir schon 2-3x sowas selbst gebastelt, immer auf das jeweilige Problem zurechtgeschnitten. Aber das geht ja wohl auch allgemein.
    Natürlich müsste man dabei nen Tradeoff machen zwischen
    * Flexibilität
    * Geschwindigkeit
    * Einfachkeit in der Anwendung

    Aber ich denke das sollte halbwegs gut gehen. Gibt es da was fertiges, brauchbares?


Log in to reply