The "C is Efficient" Language Fallacy



  • Hallo,

    Wanda Firebaugh schrieb:

    Wie würde ich in C++ dieses Problem umgehen? Geht das überhaupt?

    mögt ihr bitte beim Thema bleiben? Wie schreibe ich mein Programm so, das der Compiler Speicherzugriffe besser optimieren kann? Kann ich nicht in einer Funktion f(x[100], y[100]) restricted-Pointer verwenden, um auf x und y zuzugreifen, und in die Spezifikation schreiben, dass x und y sich nicht überlappen dürfen, ansonsten undefined behaviour? (Das ist in vielen Fällen sowieso implementationstechnisch der Fall)



  • in einer Programmiersprache mit uneingeschränkten Zeigern kann man so ziemlich jede Eingriffsmöglichkeit des Compilers unterminieren, sei es Speicherzugriffs-Schutz, sei es Zugriffsoptimierung, sei es Typprüfung, whatever.

    Daß eine Sprache wie Java mit eingebauter Speicherverwaltung oder gar von Spezialisten designten garbage-collection-Routinen bei gewissen Aufgaben schneller sein kann als C/C++ mit einer vom Nicht-Spezialisten handgestrickten Speicherverwaltung, die für jedes Programm vom Programmierer neu konzipiert werden muß, kann man sich schon vorstellen.



  • Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Themen rund um den PC in das Forum Rund um die Programmierung verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • C and C++ suck rocks as languages for numerical computing. They are not the fastest, not by a longshot. In fact, the fundamental design of them makes it pretty much impossible to make really good, efficient code in C/C++.

    Jaja, impossible ...

    C and C++ are strongly pointer-based languages.

    Java mit seinen Referencen ist auch nicht besser.

    CMU CommonLisp can beat C/C++ on numeric code.

    Jeha, jeder kann scheisse programmieren, auch in C++.

    Mit einem Beispielalgorithmus in einer Implementationsvariante wurde bewiesen dass C++ langsam ist. Seeeehr wissenschaftlich. Ich halte meist nichts von solchen Artikeln.



  • knivil schrieb:

    C and C++ are strongly pointer-based languages.

    Java mit seinen Referencen ist auch nicht besser.

    Da gibt es einen gewaltigen Unterschied, Referenzen können nur auf Objekte von Klassentypen und ganze Arrays zeigen, nicht auf beliebige primitive Typen oder in Arrays hinein, das ganze Alias-Problem ist also erheblich abgemildert.
    Aber da alle anderen schon auf den Artikel eingeprügelt haben und man sicherheitshalber einen Tag gewartet hat, ob noch was kommt, darf man ja unqualifiziert mit einstimmen 👎



  • Bashar schrieb:

    knivil schrieb:

    C and C++ are strongly pointer-based languages.

    Java mit seinen Referencen ist auch nicht besser.

    Da gibt es einen gewaltigen Unterschied, Referenzen können nur auf Objekte von Klassentypen und ganze Arrays zeigen, nicht auf beliebige primitive Typen oder in Arrays hinein, das ganze Alias-Problem ist also erheblich abgemildert.

    Allerdings wird in Java ja auf jeden nicht-primitiven Typen per Referenz zugegriffen, was das Problem gegenüber C++ wieder verstärkt.

    Dass funktionale Sprachen (wo es Aliasing Probleme schon grundsätzlich nicht gibt) theoretisch weit besser zu optimieren sind, wird hier wohl hoffentlich keiner bestreiten wollen.
    Dass die Compiler meistens trotzdem langsameren Code ausspucken aber wohl auch nicht.



  • maximAL schrieb:

    Allerdings wird in Java ja auf jeden nicht-primitiven Typen per Referenz zugegriffen, was das Problem gegenüber C++ wieder verstärkt.

    Das ist egal. Wichtig ist nur, dass der Compiler über die Referenzen viel strengere Annahmen treffen darf, als ein C- oder C++-Compiler über die Pointer/Referenzen. Die Situation wurde in C99 mit strict aliasing und restrict sicher verbessert. Aber nicht umsonst bezeichnet man C als portablen Assembler. Über viele Dinge kann der Compiler nur sehr wage Annahmen treffen und vieles liegt am Programmierer (zB restrict). Und in C++0x wird restrict leider noch nicht einmal aufgenommen.

    Aber im Endeffekt ist das optimieren von Highlevelcode eben ein schwieriges Problem, selbst mit der Möglichkeit gute Annahmen treffen zu können, wie man in den ganzen "Benchmarks" sieht.



  • rüdiger schrieb:

    Und in C++0x wird restrict leider noch nicht einmal aufgenommen.

    Warum eigentlich? Da hat man so viel eingebaut, aber solch eine elementare Geschichte nicht? Zumal viele Compilerbauer das wohl (dank C99) eh in petto hätten. Wundert mich schon ein wenig.



  • Tim schrieb:

    rüdiger schrieb:

    Und in C++0x wird restrict leider noch nicht einmal aufgenommen.

    Warum eigentlich? Da hat man so viel eingebaut, aber solch eine elementare Geschichte nicht? Zumal viele Compilerbauer das wohl (dank C99) eh in petto hätten. Wundert mich schon ein wenig.

    C != C++



  • Tim schrieb:

    Wundert mich schon ein wenig.

    die korrekte anwendung von 'restrict' liegt voll in der veantwortung des programmierers, sonst haste schnell undefiniertes verhalten. 'trust the programmer' scheint aber nicht so das ding von C++ zu sein, eher gefahrenqullen von vorn herein auszuschliessen.
    🙂



  • +fricky schrieb:

    scheint

    Wenn man keine Ahnung von C++ hat, dann "scheint" das so zu sein, ja.



  • aufmerksamer_leser schrieb:

    Tim schrieb:

    rüdiger schrieb:

    Und in C++0x wird restrict leider noch nicht einmal aufgenommen.

    Warum eigentlich? Da hat man so viel eingebaut, aber solch eine elementare Geschichte nicht? Zumal viele Compilerbauer das wohl (dank C99) eh in petto hätten. Wundert mich schon ein wenig.

    C != C++

    Und grün != braun. Was soll mir das in diesem Kontext sagen?



  • Basher schrieb:

    +fricky schrieb:

    scheint

    Wenn man keine Ahnung von C++ hat, dann "scheint" das so zu sein, ja.

    was wäre denn für dich ein plausibler grund?

    Basher schrieb:

    knivil schrieb:

    ...

    ...
    Aber da alle anderen schon auf den Artikel eingeprügelt haben und man sicherheitshalber einen Tag gewartet hat, ob noch was kommt, darf man ja unqualifiziert mit einstimmen

    übrigens machste deinem namen wieder mal alle ehre, lässt keine möglichkeit aus, jemanden dumm anzupöbeln.
    🙂



  • +fricky schrieb:

    was wäre denn für dich ein plausibler grund?

    Wenn dich C++ interessiert, informiere dich selbst. Ich werde das nicht für dich übernehmen.



  • Bashar schrieb:

    Wenn dich C++ interessiert, informiere dich selbst. Ich werde das nicht für dich übernehmen.

    sag doch gleich, dass du es nicht weisst.
    🙂



  • Es reicht doch, dass du es nicht weißt, aber trotzdem große Töne spuckst.



  • Tim schrieb:

    rüdiger schrieb:

    Und in C++0x wird restrict leider noch nicht einmal aufgenommen.

    Warum eigentlich? Da hat man so viel eingebaut, aber solch eine elementare Geschichte nicht? Zumal viele Compilerbauer das wohl (dank C99) eh in petto hätten. Wundert mich schon ein wenig.

    Ja, das wundert/enttäuscht mich auch. Einige Compiler bieten restrict ja schon in C++ an (GCC, Intel etc.).



  • rüdiger schrieb:

    maximAL schrieb:

    Allerdings wird in Java ja auf jeden nicht-primitiven Typen per Referenz zugegriffen, was das Problem gegenüber C++ wieder verstärkt.

    Das ist egal. Wichtig ist nur, dass der Compiler über die Referenzen viel strengere Annahmen treffen darf, als ein C- oder C++-Compiler über die Pointer/Referenzen.

    Begründung? In Java gibts zwar kein Aliasing mit unterschiedliche Typen, aber nichtsdestotrotz können durchaus mehrere Referenzen in einem Kontext auf das selbe Objekte verweisen, was die Arbeit für den Compiler erschwert.



  • maximAL schrieb:

    In Java gibts zwar kein Aliasing mit unterschiedliche Typen, aber nichtsdestotrotz können durchaus mehrere Referenzen in einem Kontext auf das selbe Objekte verweisen, was die Arbeit für den Compiler erschwert.

    einen grossteil der optimierung macht die java-VM zur laufzeit, nicht der compiler. damit hat Java natürlich sehr viel mehr optimiermöglichkeiten, als programmiersprachen, deren compiler starren maschinencode für bestimmte CPUs erzeugen müssen. http://en.wikipedia.org/wiki/Java_performance#Adaptive_optimization
    🙂



  • maximAL schrieb:

    Begründung? In Java gibts zwar kein Aliasing mit unterschiedliche Typen, aber nichtsdestotrotz können durchaus mehrere Referenzen in einem Kontext auf das selbe Objekte verweisen, was die Arbeit für den Compiler erschwert.

    Worum es geht ist, dass

    while(*a++=*b++);

    nicht parallelisierbar ist.

    das problem hast du in java nicht.


Anmelden zum Antworten