The "C is Efficient" Language Fallacy



  • Hallo,

    http://scienceblogs.com/goodmath/2006/11/the_c_is_efficient_language_fa.php?

    Der Mensch sagt, dass uneingeschränkte Zeiger die Optimierungsmöglichkeiten des Compilers einschränken, und erwähnt ein Beispiel, wo selbst Java schneller ist als C++ und sogar C. Wie würde ich in C++ dieses Problem umgehen? Geht das überhaupt?



  • In C and C++, there's no such thing as an array - there's just pointers, which you can subscript

    ^^also das stimmt schon mal gar nicht.
    🙂



  • Theoretisch stimmt das, was er sagt, aber die Optimierungsphasen von Compilern werden auch immer besser. Gut wäre gewesen, wenn er seine Testprogramme gezeigt hätte. So ist das alles leider nicht viel wert.
    BTW, C99 hat das Schlüsselwort restrict für solche Dinge.



  • Dass ein 2006 erschienener Artikel die 1999 definierte C-Lösung des Zeigeraliasings (Schlüsselwort restrict ) nicht bespricht zeugt zumindest von nicht optimaler Recherche.



  • Bashar schrieb:

    Theoretisch stimmt das, was er sagt...

    besonders sein zehnter kommentar:

    `int x[1000]` in C or C++ doesn't have much meaning. It's semantically equivalent to declaring "x" as `int *x`. You can reassign X any time you want, to make it point to a different location.

    🙂



  • Tim schrieb:

    Dass ein 2006 erschienener Artikel die 1999 definierte C-Lösung des Zeigeraliasings (Schlüsselwort restrict ) nicht bespricht zeugt zumindest von nicht optimaler Recherche.

    Gibt es das auch für C++?



  • Wanda Firebaugh schrieb:

    Tim schrieb:

    Dass ein 2006 erschienener Artikel die 1999 definierte C-Lösung des Zeigeraliasings (Schlüsselwort restrict ) nicht bespricht zeugt zumindest von nicht optimaler Recherche.

    Gibt es das auch für C++?

    nö, c++ hat kein 'restrict'
    🙂



  • +fricky schrieb:

    besonders sein zehnter kommentar:

    `int x[1000]` in C or C++ doesn't have much meaning. It's semantically equivalent to declaring "x" as `int *x`. You can reassign X any time you want, to make it point to a different location.

    Ugh. Ich hab nur den Hauptartikel gelesen. Wenn du Arrays an Funktionen übergibst, gibt es tatsächlich nicht viel Handhabe für den Compiler.
    Naja mit dem Kommentar hat sich das Thema wohl erledigt, Fred klost 😉



  • 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?


Anmelden zum Antworten