Warum programmiert ihr in C?

volkard

Realistisch schrieb:

welcher jedes Semester neu an einer Uni implementiert wird und hier zeugt sich das wenig überraschende Bild das C am schnellsten ist gefolgt von C++

Laß echte Fachleute ran und C++ ist schneller als C.

Es gibt ja auch in Wirklichkeit kein richtiges C++, das ist alles ein abgewandeltes C mit Zusatzkram. C++ läßt sich somit nicht vollständig ohne C programmieren.

It0101

Hab ich ja jetzt auch mit nem besseren Compiler gemessen.
- MinGW
- VS2008

#include <windows.h>

#include <iostream> 
#include <string> 
using namespace std; 

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 FindC2( const char* const cText, const char c , int iLen)
{
   const char *p = (const char *)memchr(cText, c, iLen);
   if(p)
      return p - cText;

   return -1;
}

int main() 
{
   const char* const foo = "aaaaaa";
//   const char* const foo = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
   int iLen = strlen(foo);
   string bar = foo;
   int runs = 10000000;

   for(unsigned u=0; u<12; u++)
   {
      int c = 0;
      DWORD dwStart = GetTickCount();

      switch(u % 3)
      {
         case 0: for(int i = 0; i < runs; ++i) c = bar.find('w'); break;
         case 1: for(int i = 0; i < runs; ++i) c = FindC(foo, 'w'); break;
         case 2: for(int i = 0; i < runs; ++i) c = FindC2(foo, 'w', iLen); break;
      }
      DWORD dwDuration = GetTickCount() - dwStart;
      switch(u % 3)
      {
         case 0: cout << "string: (" << c << ") " << dwDuration << " ms" << endl; break;
         case 1: cout << "FindC : (" << c << ") " << dwDuration << " ms" << endl; break;
         case 2: cout << "FindC2: (" << c << ") " << dwDuration << " ms" << endl; break;
      }
   }
}

Wer Lust hat kann das ja mal mit VS2008 messen und dabei unterschiedlich lange Strings verwenden. Die Variante FindC2 ist hier eine Imitation der STL-Implementierung von std::string::find(...). Der verwenden nämlich memchr(...) und das is relativ fix bei langen strings, aber nicht so schnell bei sehr kurzen strings. Scheint also bissel Overhead zu haben.

Hier mal noch die Messungen mit MinGW:

1.Langer String
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

std::string::find - 297ms
FindC - 343ms
FindC2 - 219ms

2.Kurzer String
aaaaaa

std::string::find - 172ms
FindC - 47ms
FindC2 - 94ms

Wer Lust und Laune hat, kann sich ja auch mal den ASM-Code für die zwei FindC-Funktionen anschauen.

-lowbyte- 0

Finde zwar nichts was bestätigen würde, dass einige Teile von der STL in Assembler programmiert sind, doch ich vermute es zumindest.

Klar ist C schneller als C++, in manchen Gebieten, dass wissen wir beide!

@It0101

Du musst das Zeug's mehrfach messen und dan den Schnitt nehmen !

It0101

Hab ich natürlich gemacht. Das sind Durchschnittswerte von mehreren Messungen für jede der drei Funktionen. Schon allein um irgendwelche Seiteneffekte auszuschließen.

Aber Aussage ist ja eigentlich, dass derartige Diskussionen mehr als müßig sind und nicht nur von Compiler oder Prozessor abhängen sondern auch vom Anwendungsfall wie man hier beim Vergleich der kurzen und langen Strings deutlich sieht.

volkard

-lowbyte- schrieb:

Finde zwar nichts was bestätigen würde, dass einige Teile von der STL in Assembler programmiert sind, doch ich vermute es zumindest.

Soweit ich weiß, ist alles in der stl ist normal programmiert. Aber mir scheint, bei MS kennt der Optimierer manche Funktionen wie std::swap sehr genau und zaubert dort.

Klar ist C schneller als C++, in manchen Gebieten, dass wissen wir beide!

Hoffen wir, daß wir auch beide wissen, daß C++ in manchen Gebieten schneller ist.

Du musst das Zeug's mehrfach messen und dan den Schnitt nehmen !

Unfug. Man muß den kleinsten Wert nehmen.

-lowbyte- 0

Okey klar ! Aber kannste nicht garantieren dass sie wirklich immer so schnell ist.

volkard

-lowbyte- schrieb:

Warum ? Das heisst nach deiner Meinung, dass ich nicht sicher sein kann dass sie ihre Leistung erbringt ! Wenn du vom Tiefsten Wert ausgehst ...

Die Zeitungenauigkeiten kommen, wenn Windows Dir den Prozess wiedermal für 10ms wegnimmt, die exe-Datei noch nicht ganz im RAM war, und so Sachen. Deswegen machst Du so viele Messungen, bis mal zufällig keine Fremdverlangsamung vorlag.
Was bei dieser Messung am schnellsten war, ist dann auch durchschnittlich am schnellsten.
Bei Meßzeiten im Minutenbereich bekommt man beim Minimummessen fünf stabile Stellen. Diese Kleinigkeit sollte auf den Takt genau ausmessbar sein.

It0101

Also bei den Messungen gab es nur Unterschiede von 1-2ms, also nicht der Rede wert und macht in dem Fall auch keinen Unterschied ob man den kleinsten Wert oder den Durchschnitt nimmt.

Zumindest hatte ich so mal ein wenig Antrieb hinter die Fassade der STL zu schauen und hab dabei sogar noch eine tolle Funktion entdeckt ( memchr )
Die STL kocht also auch nur mit Wasser... Kein Grund zur Panik

-lowbyte- 0

volkard schrieb:

Die Zeitungenauigkeiten kommen, wenn Windows Dir den Prozess wiedermal für 10ms wegnimmt, die exe-Datei noch nicht ganz im RAM war, und so Sachen. Deswegen machst Du so viele Messungen, bis mal zufällig keine Fremdverlangsamung vorlag.
Was bei dieser Messung am schnellsten war, ist dann auch durchschnittlich am schnellsten.
Bei Meßzeiten im Minutenbereich bekommt man beim Minimummessen fünf stabile Stellen. Diese Kleinigkeit sollte auf den Takt genau ausmessbar sein.

Ist mir schon klar! Meinte es irgendwie auch anders. Eben Praktisch.
Haste natürlich recht.

It0101 schrieb:

An aversion towards using C++ standard library functions and especially data containers because the C-hacker feels that he is not "in control".

Ein für mich absolut nachvollziehbarer Grund. Man weiß schlicht und ergreifend nicht, was hinter den den STL-Containern steckt. Wenn man sich aber genauer mit Containern beschäftigt, weiß man das irgendwann.

Viele nutzen die STL aber, ohne zu hinterfragen, und das ist das Problem. Irgendwer sagt: Jawoll, Container XY ist gut und alle nutzen es, ohne sich überhaupt ne Platte zu machen. Da ist mir lieber, wenn sich einer selbst hinsetzt, einen Container selber austüftelt ( wenn es Sinn macht, auch in C ) und verbessert und dabei mehr lernt, als wenn er irgendwelches vorgefertigtes Zeug unreflektiert verwendet.

Meine Worte.

@ anmerkung
Du bist doch nur neidisch auf mich.

Also ich finde, die C++ ler sollten erstmal ein Betriebssystem in C++ schreiben, dann sehen wir weiter.

C regiert jedenfalls die Welt.

lowbyte_ schrieb:

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

D.h. C++ ler betrügen und vertrauen nicht mal auf ihr eigenes STL.

Vielleicht solltet ihr das also mal auf einer Plattform messen, bei der die STL nicht zu 90 % aus Assemblercode besteht.

knivil schrieb:

STL bedeutet Standard Template Library.

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

Aufruf: g++ main.cpp -O3

Tja, da siehst man mal wieder.

Würdet du mal bitte gcc anstatt g++ zum compilieren nehmen?

gcc ist der C Compiler, nicht g++!

Michael E.

C Fan schrieb:

Vielleicht solltet ihr das also mal auf einer Plattform messen, bei der die STL nicht zu 90 % aus Assemblercode besteht.

Zu offensichtlich solltest du nicht trollen :p

Realistisch schrieb:

Da C und C++ hier fast das gleiche machen wundert es nicht dass das Ergebnis ähnlich ist. Hier hat mal jemand was über Raytracer geschrieben, welcher jedes Semester neu an einer Uni implementiert wird und hier zeugt sich das wenig überraschende Bild das C am schnellsten ist gefolgt von C++ und etwas die 4fache Zeit benötigt Java.

Schneller wie in C geht es nur mit Assembler alles andere ist großer Humbug.

Die Uni sollte mal D probieren.

It0101

Wie man hier im Thread sieht wissen selbst viele STL-Fanboys teilweise nicht, was sich hinter der STL verbirgt. Getreu dem Motto: "da haben sich mal welche bestimmt Gedanken gemacht" ...

Also mir is das zu wenig...

C-Code ist C-Code ist C-Code ( und wenn man es ordentlich macht, kommt sogar ganz passabler Assembler-Code raus )

-lowbyte- 0

Also ich würde niemanden hier (fast niemand) ein STL Fan-boy bezeichnen. Die Herren wissen schon von was sie sprechen. Von Volkard weis ich dies zumindest.
Ich schreibe fast ohne STL und habe sie auch nicht bis ins letzte Detail studiert, darum kann ich nix dazu sagen, da ich eben hauptsächlich C schreibe mit Assembler.

Aber ich würde behaupten dass doch sicher die eine oder ander Sache in ASM
programmiert ist.

Ich hab es einfach gern, wenn ich sehe was da passiert. Das ist einfach bei STL nur mit reversing machbar. Na gut lass das mal. Ist ja auch kein Problem. Für alles hat man einfach keine Zeit. Doch werde sicher mal zeit finden mal die STL voneinander zu nehmen. Bin gespannt...

Und wer sagt C sei hässlicher Code.... Ich finde C ist wenn man einen guten Style hat eine der schönsten Sprachen die es gibt.

Michael E.

It0101 schrieb:

Wie man hier im Thread sieht wissen selbst viele STL-Fanboys teilweise nicht, was sich hinter der STL verbirgt. Getreu dem Motto: "da haben sich mal welche bestimmt Gedanken gemacht" ...

Also mir is das zu wenig...

Es ist klar, dass du einen Tick schneller bist, wenn du die StdLib-Implementierung nimmst und den Overhead (und Stringlängenberechnung, du Schelm ) auslagerst. Ich habe auch nie behauptet, dass man mit einer speziellen Implementierung nicht schneller sein kann als die STL. Wir sind aber noch Meilen entfernt von einem Faktor 10 oder gar 30, der hier so gerne genannt wird.

Ich finde die Philosophie übrigens befremdlich, dass man alles selbstbauen muss, um nach ner Woche was Fehleranfälligeres, aber vielleicht um 20% Schnelleres gebaut zu haben. Dabei merkt man den Performanceunterschied in den allermeisten Fällen gar nicht.

So ziemlich jeder C Fanboy hat sich in diesem Thread jetzt blamiert. Koennen wir eigentlich mal langsam schliessen, oder?