The "C is Efficient" Language Fallacy

[u_ser-l]

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.

[C++ Forumbot]

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.

[knivil]

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.

[Bashar]

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

[maximAL]

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.

[rüdiger]

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.

[Gast]

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.

[aufmerksamer_leser]

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++

[+fricky]

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.

[Bashar]

+fricky schrieb:

scheint

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

[Gast]

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?

[+fricky]

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.

[Bashar]

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

[+fricky]

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.

[Bashar]

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

[rüdiger]

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

[maximAL]

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.

[+fricky]

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

[Shade Of Mine]

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.

[Dravere]

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.

Hmmm, kenne mich zwar nicht so gut aus, aber wenn ich nach dem Wikipedia Artikel gehe, dann steht als Beispiel dies hier:

void foo(int* lhs, int* rhs, int* val)
{
  *lhs += *val;
  *rhs += *val;
}

Problem ist ja, dass lhs und val auf das gleiche Verweisen können. Also muss der Wert von val neu geladen werden, bevor die nächste Rechnung durchgeführt werden kann.

Bei Java sieht dies allerdings etwas anders aus:

public void foo(int lhs, int rhs, int val)
{
  lhs += val;
  rhs += val;
}

val wird hier unverändert bleiben, egal wie man die Funktion aufruft.

Würde das aber gerne noch bestätigt bekommen, bin mir nicht sicher, ob ich es ganz getroffen habe

Grüssli