Warum programmiert ihr in C?

[volkard]

Rudías schrieb:

bool <T>::operator==(<T>) ist ja auch bestimmt keine Vergleichsfunktion.

Natürlich war eine gemeint, die nicht inline ist.

//C
#include <stdlib.h>
#include <stdio.h>
#include <time.h>

#define SIZE (1024*1024*64)

int comp(const void* a,const void* b){
	return *(unsigned int*)a-*(unsigned int*)b;
}

int main(){
	unsigned int* arr=malloc(SIZE*sizeof(unsigned int));
	int i;
	unsigned int hash=0;
	clock_t start,end;
	for(i=0;i<SIZE;i++)
		arr[i]=rand();
	start=clock();
	qsort(arr,SIZE,sizeof(unsigned int),comp);
	end=clock();
	for(i=0;i<SIZE;i++){
//		printf("%8x\n",arr[i]);
		hash+=3*hash+arr[i];
	}
	printf("hash: %8x\n",hash);
	printf("%f secs",(end-start)/(double)CLOCKS_PER_SEC);
	return 0;
}

//C++
#include <cstdlib>
#include <cstdio>
#include <ctime>
#include <algorithm>
using namespace std;

#define SIZE (1024*1024*64)

struct comp{
	bool operator()(unsigned int const& a,unsigned int const& b){
		return a<b;
	}
};

int main(){
	unsigned int* arr=(unsigned int*)malloc(SIZE*sizeof(unsigned int));
	int i;
	unsigned int hash=0;
	clock_t start,end;
	for(i=0;i<SIZE;i++)
		arr[i]=rand();
	start=clock();
	sort(arr,arr+SIZE,comp());
	end=clock();
	for(i=0;i<SIZE;i++){
//		printf("%8x\n",arr[i]);
		hash+=3*hash+arr[i];
	}
	printf("hash: %8x\n",hash);
	printf("%f secs",(end-start)/(double)CLOCKS_PER_SEC);
	return 0;
}

//C++-func
#include <cstdlib>
#include <cstdio>
#include <ctime>
#include <algorithm>
using namespace std;

#define SIZE (1024*1024*64)

/*struct comp{
	bool operator()(unsigned int const& a,unsigned int const& b){
		return a<b;
	}
};*/
bool comp(unsigned int const& a,unsigned int const& b){
	return a<b;
}

int main(){
	unsigned int* arr=(unsigned int*)malloc(SIZE*sizeof(unsigned int));
	int i;
	unsigned int hash=0;
	clock_t start,end;
	for(i=0;i<SIZE;i++)
		arr[i]=rand();
	start=clock();
	sort(arr,arr+SIZE,comp);
	end=clock();
	for(i=0;i<SIZE;i++){
//		printf("%8x\n",arr[i]);
		hash+=3*hash+arr[i];
	}
	printf("hash: %8x\n",hash);
	printf("%f secs",(end-start)/(double)CLOCKS_PER_SEC);
	return 0;
}

Zugegeben, der Test ist gemein und künstlich. Er soll nur den Effekt der Komparator-Klasse als Template-Argument darstellen.

Bei mir kommt übrigens raus, aber nicht stabil, weil ich so viel Mist nebenher laufen habe.
qsort: 19.8s
std::sort mit Funktionszeiger: 16.8s
std::sort mit Komparatorklasse: 8.6s

[volkard]

Cönner schrieb:

std::sort schlagen, meinst du mit qsort?

Nein, qsort hatte ich eigentlich als Kandidaten gar nicht in Erwägung gezogen wegen der Funktionsaufrufe. Ich meinte mit allen zur Verfügung stehenden Mitteln, solange Dein Verfahren auf Vergleichen basiert.

std::sort ist normalerweise so schnell, daß ich es nicht schneller hinkriege (vergleichsbasierend). Ich will nicht ausschließen, daß Du es schaffst. Aber vermutlich brauchst Du schon ein paar Tage dafür, wenn nicht mehr. Aber dann würdest auch Du sagen, daß std::sort verflixt schnell ist.

[__--]

@volkard

okay also vergleichen wir jetzt eine sort funktion mit geinlineter vergleichsfunktion (was dann auch pro zu sortierendem datentyp eine eigene funktion erfordert) vs. normaler vergleichsfunktion

derart ungleiche vergleiche sehe ich besonders gerne... evtl. erklärst uns nächstes mal den unterschied zwischen einem segelflieger und nem a380

[volkard]

__-- schrieb:

@volkard
okay also vergleichen wir jetzt eine sort funktion mit geinlineter vergleichsfunktion (was dann auch pro zu sortierendem datentyp eine eigene funktion erfordert) vs. normaler vergleichsfunktion

Ja, klar. Als noch ausstehende Klarstellung zu

Cönner schrieb:

Ups, das erste Zitat (Performanz von qsort) habe ich gar nicht beantwortet.
Also ja, es muss jedesmal eine Funktion ausgeführt werden, die Sortierung ist aber `arbitrary' (für Standardtypen gibts natürlich ne andere).
Und in C++ muss auch immer ein Funktionsobjekt aufgerufen werden (im Notfall kann es mit __force_inline ein ganz kleines bisschen schneller sein als mein qsort)

nebst

volkard schrieb:

Zugegeben, der Test ist gemein und künstlich. Er soll nur den Effekt der Komparator-Klasse als Template-Argument darstellen.

(Damit ist gemeint, daß wir jetzt eine sort funktion mit geinlineter vergleichsfunktion (was dann auch pro zu sortierendem datentyp eine eigene funktion erfordert) vs. normaler vergleichsfunktion vergleichen tun, um mal zu schauen, was das Inlinen hier bringen bewirken könnte. Das ist doch auch für C-Leute ein wichtiges Ergebnis. Es heißt, daß man gelegentlich es nicht bei qsort bewenden lassen darf, sondern in die #define-#include-Trickkiste greifen muß, und speziell angepaßte Sortierfunktionen instanziieren. Freu Dich doch darüber, daß ich Dir so spannendes Wissen vor die Füße lege.)

[__--]

ja gebe zu, der vergleich hat mich schon ein bischen überrascht. ändert aber nichts daran, dass nicht die sprache (c) sondern die umsetzung/implementation langsam ist

[volkard]

__-- schrieb:

ja gebe zu, der vergleich hat mich schon ein bischen überrascht. ändert aber nichts daran, dass nicht die sprache (c) sondern die umsetzung/implementation langsam ist

~(Genau das sage ich über cout und Konsorten. )~
Diesbezüglich sind wir ganz einer Meinung. Deswegen legte ich auch Wert darauf, in der Auswertung
qsort
std::sort mit Funktionszeiger
std::sort mit Komparatorklasse
zu schreiben und nicht C, C++-func und C++, wie ich die Dateien genannt hatte.

[cuser123]

Ich programmiere in C weil ich damit die meiste Kontrolle über mein Programm habe und man schnell zum Ziel kommt.

[lowbyte-]

Mann könnte ja auch einfach sagen, dass die C++ troller keine Ahnung haben wie man in C richtig Software implementiert!

Nichts gegen C++.

Beide Sprachen haben ihre stärken und schwächen. Deshalb könnt ihr langsam ein close darunter setzen.

[knivil]

rotf-äh schrieb:

siehste, hat c mehr Kante als c++ bzw. c--

C-- -> http://www.cminusminus.org/ wird als Zwischensprache beim Kompilieren von Haskell benutzt und hat wenig mit dem Thema zu tun.

__-- schrieb:

ja gebe zu, der vergleich hat mich schon ein bischen überrascht. ändert aber nichts daran, dass nicht die sprache (c) sondern die umsetzung/implementation langsam ist

Ach? Haben aber nicht alle wegen Performance auf der Sprache herumgehackt? Die Sprache an sich hat selten was Geschwindigkeit zu tun, sie ist eben nur eine Sprache definiert in irgendeinem Textdokument.

Irgendwie verstehe ich die ganzen Argumente nicht mehr. Um was gehts eigentlich?

[mngbd]

volkard schrieb:

Damit ist gemeint, daß wir jetzt eine sort funktion mit geinlineter vergleichsfunktion (was dann auch pro zu sortierendem datentyp eine eigene funktion erfordert) vs. normaler vergleichsfunktion vergleichen tun, um mal zu schauen, was das Inlinen hier bringen bewirken könnte. Das ist doch auch für C-Leute ein wichtiges Ergebnis.

Zumindest ich wüsste das gerne. Gibt es da verlässliche Vergleichsdaten?

[__--]

knivil schrieb:

Ach? Haben aber nicht alle wegen Performance auf der Sprache herumgehackt?

kann auch sein das sich bei anderen eingabedaten/array größen andere werte ergeben. worüber sich die c'ler aufregen ist nicht die umsetzung eines sort... es ist das paket, der overhead usw... das muß deswegen auch nicht langsamer sein.

und dann gibt es auch einfach noch einen aspekt den man nicht wegdiskutieren kann und das ist geschmack :p

[totalerstuss]

Lasst euch doch von den Dumpfbacken hier nicht erzählen man bekommt in C nicht einen schnellere Implementierung eines qsort hin als in C++, das ist totaler Quatsch.

Wenn du willst ist dein C Programm IMMER schneller als ein C++ Programm, das mag vielleicht nicht immer der große Faktor sein aber hier zu behaupten C++ ist schneller als C ist der größte Humbug den ich seit langem gelesen habe. Vielleicht mag das noch für irgendwelche Standardimplementierungen manchmal hinhauen aber nicht wenn man selbst implementiert und optimiert, da ist C naturbedingt näher an der Maschine dran als C++.

[Michael E.]

totalerstuss schrieb:

Vielleicht mag das noch für irgendwelche Standardimplementierungen manchmal hinhauen aber nicht wenn man selbst implementiert und optimiert, da ist C naturbedingt näher an der Maschine dran als C++.

[knivil]

Ich liebe doppelte Verneinungen. Und Mikrooptimierungen mache ich auch immer selbst. Die Compiler koennen das nie richtig.

[qwertzztrewq]

knivil schrieb:

Ich liebe doppelte Verneinungen. Und Mikrooptimierungen mache ich auch immer selbst. Die Compiler koennen das nie richtig.

OMG

[Cönner]

volkard schrieb:

Freu Dich doch darüber, daß ich Dir so spannendes Wissen vor die Füße lege.

Dass C++' STL toll ist, bestreite ich nicht und dass es so viel schneller ist hätte ich nicht gedacht.
Dass sort in dieser Geschwindigkeit in C nicht möglich ist, stimmt nicht. Es ist ein bisschen schwieriger, da reicht die Standardbibliothek nicht aus, dafür gibt es unzählige alternative Bibliotheken.

Apropo Standardbibliothek in C: In C++ scheint die auch nicht so toll zu sein.
Der C++-Compiler kann mitunter ein identisches Programm etwas schneller machen als der C-Compiler, aber ein Asm/C/C++-Gemisch nenn ich dann nicht mehr C++.
Vielleicht geht es mit C++, durch die Exceptions auf einfache Weise das Programm so zu optimieren, wie es in C nur sehr umständlich hinzukriegen ist, aber vermutlich ist mit der Verwendung von Makros mit Assemblercode das gleiche in C mit sehr viel mehr Aufwand möglich.
Solche theoretischen Szenarien mit einem maximal ausgereizten C++-Compiler den C-Compiler auszustechen sind mit der Einbindung von Assemblercode wieder hinfällig, rein theoretisch kann man in C++ wie in C reinen Assembler schreiben, es gilt C=C++=Assembler.

Jedes, in der Praxis geschriebene Programm in C++ ist etwas langsamer als ein C-Programm mit der gleichen Funktionalität und das liegt an erster Linie an RAII (insbesondere wenn später erneut initialisiert wird), an falscher Nutzung von Sprachfeatures und an bestimmten Teilen der Standardbibliothek.

volkard schrieb:

Genau das sage ich über cout und Konsorten.

Ausserdem ist jedes C++ Programm grösser als das in C.

Aus reinem Interesse (ich programmiere manchmal auch in C++): Was verwendest du an der Stelle von den Standard-Streams (boost::iostreams kanns ja nicht sein)?

[overheadwithtail]

In C++ hat man immer einen Overhead z.B. durch RTTI, Exceptions(die kann man wenigstens ausschalten, obwohl dann nutzlos) und lahme C++ Laufzeitumgebung wie unter Linux.

Funktionen die durch in Assembler implementiert sind als Vergleich heranzuziehen ist dann wohl dann auch mehr als ärmlich, gelle? Macht mal den QSorttest unter einem System welches eine weniger Assemblerlastige C++ Implementierung hat und schon sieht alles wieder anders aus. Was ich damit sagen will? Wer Geschwindigkeitsvergleiche wie hier aufgezeigt ernst nimmt hat nicht viel von der Technik hinter einer Programmiersprache verstanden.

[Michael E.]

Ich sehe kein Assembler Aber ich benutz ja auch nur nen unbekannten Compiler von Microsoft.

[Scheppertreiber]

overheadwithtail schrieb:

In C++ hat man immer einen Overhead z.B. durch RTTI, Exceptions(die kann man wenigstens ausschalten, obwohl dann nutzlos) und lahme C++ Laufzeitumgebung wie unter Linux.

Funktionen die durch in Assembler implementiert sind als Vergleich heranzuziehen ist dann wohl dann auch mehr als ärmlich, gelle? Macht mal den QSorttest unter einem System welches eine weniger Assemblerlastige C++ Implementierung hat und schon sieht alles wieder anders aus. Was ich damit sagen will? Wer Geschwindigkeitsvergleiche wie hier aufgezeigt ernst nimmt hat nicht viel von der Technik hinter einer Programmiersprache verstanden.

= Jeder der eine andere Meinung hat hat es nicht verstanden. Erbärmlich.

[gnomerulez]

Leute ist doch ganz einfach. Alle Theorie und Mikrobenchmark sind doch von Arsch. Vergleicht einfach mal ein GTK+/C Programm mit einem Qt/C++ Programm und ihr seht wie Ressourcensparend man sehr ähnliche Programme in C realisieren kann und darum mag ich die Sprache so, auch wenn sie nicht mehr modern ist und jeder meint mir OOP an die Backe quatschen zu müssen.

Übrigens glaube ich auch unter Windows das hier die WinAPI/C Programme am besten die Ressourcen nutzen. Von der Wirtschaftlichkeit rede ich hier nicht, aber darum geht es in diesem Thread ja auch nicht.