Warum programmiert ihr in C?

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!

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

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

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.

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

-lowbyte- 0

Causlacher schrieb:

lowbyte_ schrieb:
Und in der STL ist sowiso das Zeitkritische in Assembler geschrieben.

Schwachsinn.

Beweise mir dass dies Schwachsinn ist !

knivil

STL bedeutet Standard Template Library.

Und bei mir:
C -> 674 ms
C++ -> 396 ms

Aufruf: g++ main.cpp -O3

das ohne die C++ - Ausnahmen gar nicht erst kompilierbar war

Ich kann -fno-rtti -fno-exceptions (musste den boost-Kram rausschmeissen) angeben und compilieren. Hatte aber keine Auswirkungen.

Bashar

Es ist möglich, dass einzelne Spezialisierungen in Assembler geschrieben sind. Glaub ich aber nicht, bevor ich es sehe.