Ressourcenbedarf Programmiersprachen/Implementierungen
-
,,,, schrieb:
Ich verstehe gar nicht, warum ihr dieses Zitat alle so unterstützt? Dieses Zitat ist eine einzige Verallgemeinerung.
Es ist aber auch eine gute Faustregel. Selbst innerhalb einer Sprache gibt es zig Wege die Implementierung zu vermasseln, von daher macht es Sinn, dass man sich zunächst auf abstrakterer Ebene mit dem Problem befasst. In der Regel ist es dann schon 'schnell genug'. Wer noch etwas optimieren möchte, der kann dann die Stellen finden, an denen es hakt und gezielt optimieren. Oft ist die langsame Implementierung auf Unerfahrenheit mit den Sprachkonzepten zurückzuführen, nicht auf die Sprache an sich. Und wenn man dann wirklich noch den letzten Faktor rausbekommen will, dann kann man sich Gedanken um die Sprache machen und zumindest die kritischen Teile in was schnellerem implementieren. Natürlich macht es aber auch schon vorher Sinn sich Gedanken über die Sprache zu machen. Wissenschaftliches Rechnen (z.B. FEM) mit Java z.B. macht so gut wie keiner. Das scheint wohl die falsche Sprache für so etwas zu sein, wenn es schwer ist wenigstens halb so schnell wie C-Code zu werden. Wenn ich also eh große Teile in was anderem schreiben werde, dann kann ich auch gleich was anderes nehmen. Was ich bisher von Python gesehen habe, gefällt mir da im Ansatz ganz gut, da es einem wirklich einfach gemacht wird kritische Teile in C-Codes auszulagern. In meinem Bereich gibt es für C++ die besseren Bibliotheken, von daher wird mir die Sprachwahl ziemlich einfach gemacht ;).
-
Ich denke darüber diskutiert, wann Optimierungen eine Rolle spielen, haben wir bereits in anderen Threads genug. Genauso weiß auch Jeder, dass es entscheidend ist, was der Programmierer mit der Sprache anfängt. Was mich interessieren würde, sind Spracheigenschaften, die generell einen Overhead produzieren und nur schwer oder sogar gar nicht vom Programmierer oder dem Compiler/Interpreter umgangen werden können. Natürlich sind auch die technischen Details sowie der Sinn hinter diesen Spracheigenschaften und Alternativen dazu interessant.
Es geht mir dabei auch nicht ausschließlich um "schnell", sondern ebenfalls um Größe im Hauptspeicher. Und es geht ganz und gar nicht um "schnell genug oder nicht schnell genug".
-
Ich glaube das führt zu nichts.
Spracheigenschaften führen doch nicht zu Overheads. Eine Sprache hat im eigentlichen Sinne zunächst nichts mit Computern zu tun, sondern ist nur eine Menge von Wörtern, die weder schnell, noch langsam sein kann.Du interessierst dich hier eher für die Implementierungen einer Sprache. Die Sprache gibt nicht vor, wie etwas in Maschinencode umgesetzt werden soll, sondern nur, was als Ergebnis passieren soll. Und egal welche Sprache du nimmst, unterm Strich arbeiten sie mit Pointern, Speicherbereichen, Interupten, Subroutinen, den Speicherbereichen etc.
In den Sprachen findest du m.M.n. nicht die "Quelle der Langsamkeit".Was spricht dagegen, Java als Maschinen-Sprache ohne VM zu implementieren?
-
Nichts, aber trotzdem kann ja Overhead bleiben.
Eine Programmiersprache ist eine Sprache, die nicht das Ergebnis, sondern den Programmablauf beschreibt. Zumindest gilt das für imperative Programmiersprachen. Ein Compiler, der sich an das hält, was der Programmierer geschrieben hat, so dass der Programmierer sich auch darauf verlassen kann, dass das passiert, was er erwartet, besitzt nun einmal Einschränkungen. Um tatsächlich in zwei völlig unterschiedlichen Sprachen den exakt gleichen und optimalen Maschinencode zu erhalten, müsste der Compiler genau wissen, wie das Ergebnis aussehen soll. Das kann er nicht. Er setzt das um, was der Quelltext ihm vorsetzt.
Natürlich kann er theoretisch beliebig weit optimieren und ein optimales Ergebnis liefern. Aber das tun derzeitige Implementierungen doch nicht mal annähernd.
Nehmen wir doch mal mit Forth ein einfaches Beispiel. Ein Forth-Programm besteht ausschließlich aus der Aneinanderreihung von Anweisungen. Der Compiler sieht also Anweisungen. Diese Anweisungen führen zu einem Ergebnis, einer Software. Glaubst du wirklich, irgendein Compiler ist, oder wird in absehbarer Zukunft, so intelligent sein, dass er aus einer Million dieser Anweisungen den Sinn, Zweck und das Ziel des Programms versteht um daraus optimalen Maschinencode zu erstellen? Theoretisch ist das Möglich, da im Programm beschrieben wird, was als Ergebnis passieren soll, aber das ist doch für den Compiler absolut nicht greifbar.
-
Die Compiler-Optimierungen sind schon längst ziemlich genial. Man sehe das mal so: Overhead kommt durch schlechte/redundante Maschinenbefehle, die wiederrum kommen aus dem Compiler. Eine Programmiersprache ist nicht an den Maschinencode gebunden, den der Compiler aus der Sprache macht. Die Sprache folgt einer wohl definierten Grammatik, die der Compiler über Parsebäume auflöst und dabei den Code generiert. Was er da generiert hat nichts mit der Sprache zu tun.
Am Ende ist es also die Fähigkeit des Compilerbauers und des Programmierers. Sprachen machen es hierbei nur schwerer o. einfacher, sie performant in Maschinencode um zu setzten. Jedenfalls denke ich, dass es einfacher ist, C++ Code zu optimieren als z.B. Erlang-Code, der in der Theorie der Maschine weiter entfernt ist.
-
Ad aCTa schrieb:
Ich glaube das führt zu nichts.
Spracheigenschaften führen doch nicht zu Overheads. Eine Sprache hat im eigentlichen Sinne zunächst nichts mit Computern zu tun, sondern ist nur eine Menge von Wörtern, die weder schnell, noch langsam sein kann.Du interessierst dich hier eher für die Implementierungen einer Sprache. Die Sprache gibt nicht vor, wie etwas in Maschinencode umgesetzt werden soll, sondern nur, was als Ergebnis passieren soll. Und egal welche Sprache du nimmst, unterm Strich arbeiten sie mit Pointern, Speicherbereichen, Interupten, Subroutinen, den Speicherbereichen etc.
In den Sprachen findest du m.M.n. nicht die "Quelle der Langsamkeit".Was spricht dagegen, Java als Maschinen-Sprache ohne VM zu implementieren?
Nichts, aber wir bewegen uns leider in der Realität, und da rechnen wir mit Implementierungen und nicht mit Gedankenkonstrukten.
-
Stimmt, gewisse Dinge machen nur im Zusammenhang begutachtet Sinn. Manche Sprachen lassen sich leicher lernen und verstehen, und man kann auf diese Weise effizienteren Code hinbekommen. Man braucht hier und da weniger Texte oder Zeit, um leistungsfähige Programme zu schreiben, muss nicht so lange nach bestimmten Lösungen suchen, es gibt opensource und Beliebtheit etc.
Manche Sprachen kosten Geld, um sie auszuprobieren, andere gibt es fast geschenkt.
Manche Sprache stiften viel Verwirrung und kosten Zeit, andere weniger.
Man kann dieses Thema nicht sinnvoll diskutieren, ohne sich über Betriebsystem und dessen Schnittstellen und Entwicklungstools Gedanken machen.
Man kann dieses Thema nicht sinnvoll diskutieren, ohne sich über die Hardware und Hardwarestrukturen Gedanken zu machen, und über aktuelle Bedürfnisse und Marktmechanismen (und "Treiber").
Basic und Assembler sind aus dem Mainstream verschwunden, weil es kaum noch Schnittstellenförderung in diesem Sinne gab, schlechte komplizierte Programmiersprachen waren sie nicht, fast jeder konnte auf Anhieb (mit Hilfe der Manuals damals) mit Basic und Assembler spielen.
Man bräuchte eigentlich in Windows gar keine Programmiersprache mehr, ein gut geschriebener, Maus- und Tastaturfreundlicher Wizard, der auf optimierte Routinen zurückgreifen kann, bestimmte Dinge aus dem Internet nachladen kann (etwa bestimmte Algorithmen, Grafiken oder Sounds)(usw) würde vollkommen reichen.
-
Ad aCTa schrieb:
Die Compiler-Optimierungen sind schon längst ziemlich genial. Man sehe das mal so: Overhead kommt durch schlechte/redundante Maschinenbefehle, die wiederrum kommen aus dem Compiler. Eine Programmiersprache ist nicht an den Maschinencode gebunden, den der Compiler aus der Sprache macht. Die Sprache folgt einer wohl definierten Grammatik, die der Compiler über Parsebäume auflöst und dabei den Code generiert. Was er da generiert hat nichts mit der Sprache zu tun.
Am Ende ist es also die Fähigkeit des Compilerbauers und des Programmierers. Sprachen machen es hierbei nur schwerer o. einfacher, sie performant in Maschinencode um zu setzten. Jedenfalls denke ich, dass es einfacher ist, C++ Code zu optimieren als z.B. Erlang-Code, der in der Theorie der Maschine weiter entfernt ist.
Sprachen machen es schwerer oder leichter, aber wie sieht es denn mit Sprachkonstrukten aus, die es beinahe unmöglich machen? Wie schon als Beispiel genannt: Wenn ich einen Rohdatenbedarf habe, sagen wir mal 20.000 Integer, benötige jetzt aber für dynamische Typisierung oder Reflection oder einfach garantiertes RTTI noch Typinformationen für jeden dieser Integer, muss mir deren Zustand im Speicher merken für Garbage Collection und habe die Integer, von der Sprache garantiert, als Referenzen auf dem Heap angelegt. Dies Alles wird dir garantiert von der Sprache, also darf die Implementierung absolut nicht diese Garantien brechen, solange sie sich nicht absolut sicher sein kann, dass sich kein einziger Teil der Software auf diese Daten verlässt. Das wird spätestens bei der Berücksichtigung von Reflection ziemlich kompliziert. Kann ein moderner Compiler, nicht nur theoretisch sondern auch praktisch, diese Dinge ausbügeln?
Wenn ein Compiler beinahe beliebig aus dem von der Sprache und Quelltext gegebenen Bedingungen perfekten Code generieren kann, wieso spielt dann Performanz durch die Wahl des falschen Algorithmus noch eine Rolle? Er müsste doch auch hier die Auswirkung des Algorithmus erkennen und optimierten Maschinencode ausspucken.
Wieso spielt Mikrooptimierung überhaupt noch eine Rolle?
http://en.wikibooks.org/wiki/Ada_Style_Guide/Improving_PerformanceIch kann mir gut vorstellen, dass moderne Compiler bereits sehr guten Code generieren und sehr intensive Optimierungen durchführen können. Aber absolut vom eigentlichen Quelltext und von der Sprache unabhängig die Software als Ganzes erkennen?
Theoretisch sicher möglich, aber wenn es praktisch ebenso möglich ist, wieso wird es denn nicht getan?
-
Irgendwie hab ich das Gefühl du hast dir kurz etwas angelesen, jetzt machst du dir gedanken und lässt uns deine Gedanken entsorgen. O.o
-
Der Herr Sprachprogrammierer hat wohl nicht wirklich viel Ahnung von der Materie. Riecht sehr stark nach Pseudo-Informatiker der gerade mal ein Ubuntu installiert bekommt dann aber über IPTables diskutieren will.
-
Zeus schrieb:
Irgendwie hab ich das Gefühl du hast dir kurz etwas angelesen, jetzt machst du dir gedanken und lässt uns deine Gedanken entsorgen. O.o
So ähnlich, ja. Eigentlich wollte ich mich hier über das Thema informieren. Von Compilerbau oder Sprachdesign habe ich selbst nicht viel Ahnung.
Die eine Hälfte sagt bisher, "natürlich spielt die Sprache eine große Rolle", die andere sagt Compiler wären so weit entwickelt, dass die Sprache selbst keine Rolle spielt.
-
Und beide haben Sie recht!
Weil die Ausprägung einer Programmiersprache abhänig von ihre Konzept ist. Zu jeden Konzept kann ich unterschiedliche Syntaxen designen, aber im Konzept wesenliche Entscheidungen zur effenzient,... getroffen wurden sind.