Warum programmiert ihr in C?

It0101 schrieb:

trolldetector schrieb:

Wer in seinen C++ Code C einbaut, hat einfach keine Ahnung. Das sind dann auch die Leute, die printf() fuer ueberlegener halten als Streams.

Von printf ist hier nicht die Rede... es geht um Performance.
Bei Dateizugriffen und Textausgaben nutze ich auch nur streams...

Dann nenn mir mal ein Beispiel, wo C gegenueber C++ schneller ist.

It0101

Zum Beispiel benötigte ich vor längerer Zeit mal eine sehr spezielle Liste. Eine Spezialanwendung sozusagen.

Das von mir selbst programmierte maßgeschneiderte Template mit C-Code war 2% schneller als der dafür am besten geeignete STL-Container...

Manche STL-Container und Klassen sind einfach zu oversized, so dass eine C-Implementierung für Spezialfälle dann durchaus Sinn macht.

Nur als Beispiel... Es gibt sicher in anderen Bereichen noch mehr Beispiele dafür, die nicht mal unbedingt Spezialanwendungen sein müssen.

Michael E.

Inwiefern war das C-Code und inwiefern war er schneller als entsprechender C++-Code? Kann man in C++ nicht mehr eigene Container schreiben?

It0101 schrieb:

Zum Beispiel benötigte ich vor längerer Zeit mal eine sehr spezielle Liste. Eine Spezialanwendung sozusagen.

Das von mir selbst programmierte maßgeschneiderte Template mit C-Code war 2% schneller als der dafür am besten geeignete STL-Container...

Manche STL-Container und Klassen sind einfach zu oversized, so dass eine C-Implementierung für Spezialfälle dann durchaus Sinn macht.

LOL. Und was hat das jetzt mit C++ zu tun? Du vergleichst gerade C mit der STL. Merkst was?
Wenn ein STL Container nicht passt, dann schreibt man sich halt einen. Nur deshalb gleich auf das unkomfortable C umsteigen, macht Null Sinn.

Wieder einmal zeigen die Cler, dass sie einfach keine Ahnung haben und nicht mal wissen, dass C++ einfach eine Obermenge ist. Wenn ich gleichwertigen Code habe, dann ist der in C++ mindestens genauso schnell und wenn ich C++ spezifische Konstrukte habe, dann ist der Nachbau in C MAXIMAL gleich schnell.

It0101

Erklär das hier mal den Fanboys... Für die meisten ist hier C++ untrennbar mit der STL verbunden Und selbst deine Ansicht, sich selbst nen Container zu schreiben wird hier nicht von vielen unterstützt. Das is praktisch Blasphemie

Es gibt sogar Fälle wo man mit C++ Standardmitteln über 30x langsamer als mit C-Mitteln ist. Komfort kostet halt meist Performance und die STL ist bei weitem nicht das Allheilmitteln als das es hier oft angepriesen wird.

Das Optimum aus Performance und Komfort bekommt man wenn man C mit Klassen schreibt und die ganze STL weg lässt.

Ach wie schnell und sparsam wären unsere Systeme wenn alles in sauberen C geschrieben wäre. Dann würde die System auch mit schnellerer Hardware schneller werden und nicht immer langsamer.

Michael E.

It0101 schrieb:

Erklär das hier mal den Fanboys... Für die meisten ist hier C++ untrennbar mit der STL verbunden Und selbst deine Ansicht, sich selbst nen Container zu schreiben wird hier nicht von vielen unterstützt. Das is praktisch Blasphemie

Blödsinn. Wenns auf 2% Performance ankommt, kannst du dir ruhig ne eigene Liste schreiben. Du musst mir mal einen zeigen, der dir da widerspricht.

amuesierter schrieb:

It0101 schrieb:

Zum Beispiel benötigte ich vor längerer Zeit mal eine sehr spezielle Liste. Eine Spezialanwendung sozusagen.

Das von mir selbst programmierte maßgeschneiderte Template mit C-Code war 2% schneller als der dafür am besten geeignete STL-Container...

Manche STL-Container und Klassen sind einfach zu oversized, so dass eine C-Implementierung für Spezialfälle dann durchaus Sinn macht.

LOL. Und was hat das jetzt mit C++ zu tun? Du vergleichst gerade C mit der STL. Merkst was?
Wenn ein STL Container nicht passt, dann schreibt man sich halt einen. Nur deshalb gleich auf das unkomfortable C umsteigen, macht Null Sinn.

Wieder einmal zeigen die Cler, dass sie einfach keine Ahnung haben und nicht mal wissen, dass C++ einfach eine Obermenge ist. Wenn ich gleichwertigen Code habe, dann ist der in C++ mindestens genauso schnell und wenn ich C++ spezifische Konstrukte habe, dann ist der Nachbau in C MAXIMAL gleich schnell.

träum weiter

It0101 schrieb:

Erklär das hier mal den Fanboys... Für die meisten ist hier C++ untrennbar mit der STL verbunden Und selbst deine Ansicht, sich selbst nen Container zu schreiben wird hier nicht von vielen unterstützt. Das is praktisch Blasphemie

Red dich hier nicht raus. DU vermischst hier einfach total verschiedene Sachen. Bei deinem Verstaendnis wette ich, dass du die 2% einfach willkuerlich genannt hast, oder falsch gemessen hast.

Sag doch mal, was das fuer eine "Spezialliste" gewesen sein soll. Und am besten zeig mal deinen Code mit der Messung.

Michael E.

g56zh5433 schrieb:

Es gibt sogar Fälle wo man mit C++ Standardmitteln über 30x langsamer als mit C-Mitteln ist.

Hier hat schonmal jemand vom Faktor 36 geredet. Ich hätte mal gerne ein Beispiel, bei dem auch nur der Faktor 10 rauskommt.

Das Optimum aus Performance und Komfort bekommt man wenn man C mit Klassen schreibt und die ganze STL weg lässt.

Weil generische Programmierung sooo langsam ist Auch hier: Beispiel.

It0101

int FindC( char *cText, char c )
{
    char *p = cText;
    while ( *p )
        if ( *p++ == c )
            return p - cText - 1;
    return -1;
}

Diese Funktion sucht nach einem Character in einem String.
Diese Funktion ist z.B. ca. 30% schneller als die STL-Variante mit std::string::find( .. )!

Kann ja jetzt jeder selber ausprobieren.
std::string ist ja sicherlich das bevorzugte Mittel der C++-Fanboys

(bei mir getestet mit MSVC-Compiler - für gcc war ich zu faul ^^ )

It0101

Michael E. schrieb:

g56zh5433 schrieb:

Es gibt sogar Fälle wo man mit C++ Standardmitteln über 30x langsamer als mit C-Mitteln ist.

Hier hat schonmal jemand vom Faktor 36 geredet. Ich hätte mal gerne ein Beispiel, bei dem auch nur der Faktor 10 rauskommt.

Das Optimum aus Performance und Komfort bekommt man wenn man C mit Klassen schreibt und die ganze STL weg lässt.

Weil generische Programmierung sooo langsam ist Auch hier: Beispiel.

Also Faktor 10 oder gar 36 halte ich für totalen Schwachsinn... Meistens sind beide Lösungen gleichermaßen schnell.

Michael E.

It0101 schrieb:

int FindC( char *cText, char c )
{
    char *p = cText;
    while ( *p )
        if ( *p++ == c )
            return p - cText - 1;
    return -1;
}
Diese Funktion sucht nach einem Character in einem String.
Diese Funktion ist z.B. ca. 30% schneller als die STL-Variante mit std::string::find( .. )!

Das ist ja schon fast ein Armutszeugnis. Gefordert war Faktor 30, als Antwort kamen angebliche 30%, aber in der Realität ist std::string schneller

#include <iostream>
#include <string>
#include <boost/date_time/posix_time/posix_time_types.hpp>
using namespace std;
using namespace boost::posix_time;

int FindC( const char* const cText, const char c )
{
    const char* p = cText;
    while ( *p )
        if ( *p++ == c )
            return p - cText - 1;
    return -1;
} 

int main()
{
	const char* const foo = "Dies ist mein supertoller String, in dem was gesucht werden muss";
	string bar = foo;
	int runs = 10000000;
	unsigned long counter = 0;

	ptime start = microsec_clock::local_time();
	for(int i = 0; i < runs; ++i)
	{
		counter += FindC(foo, 'w');
		//counter += (bar.find('w'));
	}
	time_duration duration = microsec_clock::local_time() - start;
	cout << counter << endl;
	cout << duration.total_milliseconds() << " ms";
}

mit FindC ca. 518ms, mit string::find ca. 410ms.

VS 2008 /Ox /I "D:\boost\boost_1_42" /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /FD /EHsc /MT /Fo"Release\" /Fd"Release\vc90.pdb" /W3 /nologo /c /Wp64 /Zi /TP /errorReport:prompt

It0101

Das sagt uns wiederum, dass es vom Compiler abhängig ist...

Meiner ist von 1998. Ich werds nachher doch mal mit gcc bauen...

Michael E.

It0101 schrieb:

Das sagt uns wiederum, dass es vom Compiler abhängig ist...

Meiner ist von 1998. Ich werds nachher doch mal mit gcc bauen...

LOL, bist du mim VC6 angetreten? Wahrscheinlich noch im Debug-Mode

Shade Of Mine

It0101 schrieb:

Das sagt uns wiederum, dass es vom Compiler abhängig ist...

Natuerlich ist es vom Compiler abhaengig.
Und daher kommt auch der Mythos dass C schneller sei. Denn C Compiler sind so viel einfacher zu implementieren als C++ Compiler. Somit bleibt mehr Zeit den Optimizer zu verbessern.

Der Vorteil von C ist die Einfachheit der Tools - Compiler, IDE, Debugger,... ist alles mit C einfacher als wenn man auch C++ bedenken muss.

Michael E.

Shade Of Mine schrieb:

It0101 schrieb:

Das sagt uns wiederum, dass es vom Compiler abhängig ist...

Natuerlich ist es vom Compiler abhaengig.
Und daher kommt auch der Mythos dass C schneller sei. Denn C Compiler sind so viel einfacher zu implementieren als C++ Compiler. Somit bleibt mehr Zeit den Optimizer zu verbessern.

Gibts da heute noch nen merklichen Unterschied? Dass Compiler aus Prästandardzeiten nicht gut optimieren, sollte nicht verwundern, hat aber nichts mit modernen Compilern zu tun.

Shade Of Mine

Michael E. schrieb:

Gibts da heute noch nen merklichen Unterschied? Dass Compiler aus Prästandardzeiten nicht gut optimieren, sollte nicht verwundern, hat aber nichts mit modernen Compilern zu tun.

Am Desktop nicht wirklich, da alle Compiler ja C und C++ koennen und somit ja den selben Optimizer verwenden.

Wo es aber relevant ist, ist der Embedded Bereich.

It0101

Michael E. schrieb:

It0101 schrieb:

Das sagt uns wiederum, dass es vom Compiler abhängig ist...

Meiner ist von 1998. Ich werds nachher doch mal mit gcc bauen...

LOL, bist du mim VC6 angetreten? Wahrscheinlich noch im Debug-Mode

Sehr lustig.. türlich nich...

Mir stellt sich eher die Frage, wie die std::string::find funktion implementiert ist, dass sie bei dir schneller ist als die C-Lösung die ja nun wirklich fast optimal ist. Dass es bei mir sicherlich an einer veralteten Implementierung der STL liegt erscheint mir logisch...

Michael E.

It0101 schrieb:

Mir stellt sich eher die Frage, wie die std::string::find funktion implementiert ist, dass sie bei dir schneller ist als die C-Lösung die ja nun wirklich fast optimal ist

Man glaubt es kaum, aber an der Standardbibliothekimplementierung haben viele Leute, die die Interna des Compilers und systemabhängige Tricks deutlich besser kennen als wir, viel Zeit investiert, um die Implementierungen schneller zu bekommen, als wir es in zwei Minuten hinbekommen.