Warum programmiert ihr in C?

[amuesierter]

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.

[It0101]

Michael E. schrieb:

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.

Ich komme nicht umhin, dir zuzustimmen
Ist halt doch was anderes, als wenn man mal schnell was zusammenfriemelt ^^

mein aktueller gcc bestätigt deine Zeitmessung auch noch... die Drecksau!

[loler]

Das sind also die C-Entwickler, die ja so viel Ahnung von den Details haben.

[It0101]

CodeBlocks mit mingw sagt jetzt wiederum, dass die C-Lösung schneller is... In ungefähr dem gleichen Prozentsatz wie der VC6...

optimiert mit -O3 ...

Der Compiler sollte relativ modern sein...

Wer hat denn nun eigentlich recht?

[Zeus]

It0101 schrieb:

CodeBlocks mit mingw sagt jetzt wiederum, dass die C-Lösung schneller is... In ungefähr dem gleichen Prozentsatz wie der VC6...

optimiert mit -O3 ...

Der Compiler sollte relativ modern sein...

Wer hat denn nun eigentlich recht?

Welche Mingw Version? Hast du das uralt Mingw 3.6.5? Dann kein wunder, dass ist ja fast genauso alt wie VC6 *hust* große Unschärfe.

Wie gesagt im Allgemeine und deswegen auch immer jeden Anfänger erzählt nehme die Sachen aus der STL, wenn du C++ Programmieren willst. Mikrooptimierung lohnen sich nicht. Erstens weil man viel Zeit investierten muss, welches mit einen relativen kleinen Leistungszuwachs belohnt wird. Zweitens die Komplexität einen Anfänger überfordert. Wenn du Experte bist, dann kannst du machen, wie du es für richtig hältst, aber dann wirst du in Regeln dein Code auch nicht hier mit Probleme posten

[lowbyte_]

Dies ist Compiler abhängig, verstehst du das immer noch nicht!?
Und in der STL ist sowiso das Zeitkritische in Assembler geschrieben.

[Causlacher]

lowbyte_ schrieb:

Dies ist Compiler abhängig, verstehst du das immer noch nicht!?
Und in der STL ist sowiso das Zeitkritische in Assembler geschrieben.

Schwachsinn.

[It0101]

lowbyte_ schrieb:

Dies ist Compiler abhängig, verstehst du das immer noch nicht!?
Und in der STL ist sowiso das Zeitkritische in Assembler geschrieben.

Ich versteh das schon. Was ich aber nicht erwarte ist, dass die Unterschiede derart enorm sind... Kleinere Unterschiede hätte ich erwartet aber nicht derart extreme...

Ist die STL nun eigentlich teilweise in ASM geschrieben oder nicht?
Das wäre ja zumindest ein plausibler Grund.

[Ausnahmeerscheinung]

@It0101
@MichaelE

Die Funktion von It0101 ist auch tatsächlich erheblich schneller als std::string::find(), wenn man sie richtig - und zwar als C-Code -
aber nicht als C++ - Code unter Visual Studio 2010 kompiliert (dort kann man das wahlweise einstellen).
Dann schaltet man natürlich auch noch die C++ - Ausnahmen ebenso bei den Compiler-Optionen ab, weil wir verwenden ja kein C++.
Ansonsten jeweils ein herkömmlicher Release-Build (mit den Standardvorgaben bei den Projekteinstellungen).
Und schon konnte man It0101's FindC in der gleichen Zeit doppelt so oft aufrufen wie std::string::find() (das ohne die C++ - Ausnahmen gar nicht erst kompilierbar war).
Was den C++ Code hauptsächlich so träge macht, ist die Runtime, die jederzeit vom DAU (C++ 'Programmierer') ausgehen muss und für jedes Unvermögen eine eingebaute Ausnahmebehandlung bereitzustellen hat (Wie es der 'Standard' eben so vorsieht).
Als C - Programmierer habe ich die Freiheit, von einer Funktion anzunehmen, dass sie einwandfrei funktioniert (bzw. weiß man im Voraus, dass die Anwender der Funktion keinen Schabernack damit treiben werden), dadurch spart man sich den Ausnahmen-Wildwuchs und Rückgabewerte-Prüfzwang auch ein und schöpft das volle Highspeed-Potential von C damit auch aus. Als C++ Programmierer kann man sich das nicht frei aussuchen und d'rum brauchts den Overhead mit den Exceptions.