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

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

Objektorientierung ist generell langsamer

Soso

Objektorientierung ist generell langsamer

Soso - generell

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.

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.

Objektorientierung ist generell langsamer

objektorientierung ist ein konzept. konzepte haben keine geschwindigkeit

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.

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

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.

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.

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

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

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?

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.

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?

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

Flexibilität und Performance sind i.A. schwer unter einen Hut zu bringen.

Bjarne Stroustrup sagt dazu:

Designing and implementing a general input/output facility for a programming language is notoriously difficult

Die Firma Thinkcell hat Firmen intern so eine Library, die sie in den eigenen Produkten einsetzt. Sie wurde vor etlichen Monaten in der Müncher C++-Gruppe vorgestellt. In wie weit diese öffentlich verfügbar ist, kann ich nicht sagen. Du kannst ja mal locker anfragen. Zumindest haben sie dafür Werbung gemacht.

Gruß
Werner

FastFormat war immer sehr schnell - (noch gepflegt?)
http://www.fastformat.org/

https://github.com/fmtlib/fmt

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.

eine for-Schleife, die als einzigen Seiteneffekt ein Array hat, auf das alle Schleifendurchläufe arbeiten. So etwas läßt sich funktional im einfachsten Fall sogar automatisch parallelisieren (openmp), wobei jeder Thread einen Abschnitt der for-Schleife bearbeitet.