D vs. C++
-
Apfelbirne schrieb:
Das sind Eigenschaften des zu entwickelten Programms, allerdings muß die Programmiersprache dies ermöglichen können, was mit Java wegen der JVM, Garbage Collector & Co nicht geht, mit C, D oder C++ aber sehr wohl.
Reitest Du auf der Echtzeitfähigkeit herum? Erstmal lesen, was das ist…
Ah, einfach nur rechtzeitig antworten können. Da sind VM und GC keine technischen Gegenargumente. Im Gegenteil: GC-Allokationen sind in O(1) und die Deallokationen sind dann normal (und zur Zeit lahm), können aber recht frei vorgeblendet und verzögert werden, verzögern also den Nachrichtenbehandler nicht!! Die Anwendung muß auf Allokationen warten. Auf Deallokationen nicht. Sogesehen ist Java auf schmalbrüstiger Hardware prinzipiell besser geeignet, engere Grenzen der "Quasi-Echtzeit" zu gewährleisten. Und mehr tun wir eh nicht. Echte Echtzeit kannste in Büchern lesen, aber kaumn noch erleben. Außer, wegen anderer Gründe, wie der Strahlungsfestigkeit millimeter breiter Leiter, ist die echte Echtzeit noch zufällig da. Dann wird sie natürlich groß angepriesen.
-
volkard schrieb:
Da sind VM und GC keine technischen Gegenargumente. Im Gegenteil: GC-Allokationen sind in O(1) und die Deallokationen sind dann normal (und zur Zeit lahm), können aber recht frei vorgeblendet und verzögert werden, verzögern also den Nachrichtenbehandler nicht!!
Es wäre mir neu, daß man beim GC von Java kontrollieren könnte, wann auf den Ausführungsbefehl genau er unnötige Daten löschen soll.
Bei C++ hat man hier dank Destruktur der voll in der Kontrolle des Programmieres liegt, sicher eine deutlich bessere Kontrolle.
Und die VM ist ein Gegenargument, weil die praktisch wie ne Blackbox ist und man keine Kontrolle über sie hat, was sie gerade tut oder zu tun hat.
Damit schaffst du vielleicht semi bis pseudo Echtzeitfähigkeit, aber eben nicht harte Echtzeitfähigkeit die gut genug ist, um z.B. auf physikalische Prozesse am LHC & Co im Nanosekundenbereich zu reagieren.
Zumal Java auch keine Zeitauflösung bietet die besser als 1 ms ist.
Und mehr tun wir eh nicht.
Tut ihr nicht.
Aber das Anwendungsgebiet der Systemprogrammierung ist groß, so daß es auch vorkommen kann, daß Semi/Pseudo-Echtzeitfähigkeit oder wie du es nennst, Quasi-Echtzeitfähigkeit nicht genügt.Echte Echtzeit kannste in Büchern lesen, aber kaumn noch erleben.
Wird trotzdem noch benötigt.
-
Apfelbirne schrieb:
Und die VM ist ein Gegenargument, weil die praktisch wie ne Blackbox ist und man keine Kontrolle über sie hat, was sie gerade tut oder zu tun hat.
Und noch etwas.
Bei der VM kommt dann auch noch das Problem der Garantie der bestmöglichen Fehlerfreiheit dazu.
Bei Assembler das, mit C ist es schwieriger aber nicht unmöglich.
Gleiches gilt für C++ oder D.Aber Java ist für AKWs nicht zugelassen, die VM ist ne Blackbox über die du keine Kontrolle hast, da können tausende Bugs drin sein.
Das ist also unzureichend für die Anforderungen.
-
Und noch etwas.
Umso schwächer die Hardware, was bei HW unter Strahlungsbedingungen arbeitende HW aus obigen Gründen aufgrund der Auslegung der Fall ist, umso wichtiger wird echte Echtzeitfähigkeit.
Denn da hast du keinen hochgezüchteten Zig GHz Prozessor, dessen Taktrate hoch genug ist, um ein paar Taktzyklen Däumchen zu drehen.
Da kommt es noch wirklich auf die Software an.Das Shuttle wird z.B. von 8086 CPUs betrieben, sie arbeiten bei ca. 4-10 MHz.
Moderne strahlungsresistente CPUs die man inzwischen für neue Sachen verwendet können ein klein bischen mehr, aber da wird man auch aus Stromversorgungsgründen, der weiterhin notwendigen großen Fertigungstechnik aus Strahlungsgründen und den daraus resultierenden hohen Stromverbrauch auch weiterhin kaum schneller als 33 MHz takten.
-
Korrektur, es sollte heißen
Apfelbirne schrieb:
Bei Assembler geht das,
-
Apfelbirne schrieb:
, aber eben nicht harte Echtzeitfähigkeit die gut genug ist, um z.B. auf physikalische Prozesse am LHC & Co im Nanosekundenbereich zu reagieren.
Du bist am Erkenntnisgewinn im Dialog doch gar nicht interessiert, sondern willst nur recht behalten.
-
Noch etwas zur Fehlerfreiheit.
Im Fall von Marsrobotern und Co muß die Software über Monate bis Jahre fehlerfrei ohne einen einzigen Absturz laufen, das kannst du mit einer VM im Hintergrund niemals garantieren.Die Voyagersonden arbeiten schon seit über 35 Jahren, weil man da die Hardware noch mit Assembler programmiert hat.
35 Jahre ist ne lange Zeit, für eine Java VM würde ich nicht die Hand ins Feuer legen, daß sie so lange ohne Absturz funktioniert.
-
volkard schrieb:
Apfelbirne schrieb:
, aber eben nicht harte Echtzeitfähigkeit die gut genug ist, um z.B. auf physikalische Prozesse am LHC & Co im Nanosekundenbereich zu reagieren.
Du bist am Erkenntnisgewinn im Dialog doch gar nicht interessiert, sondern willst nur recht behalten.
Mir geht es nicht ums Recht behalten, sondern darum euch zu informieren und auch zu belehren.
Schau dir das mit den 35 Jahren und der VM an, glaubst du ernsthaft, daß das funktionieren würde und du als Entwickler diese Laufzeit garantieren kannst?
-
Apfelbirne schrieb:
Schau dir das mit den 35 Jahren und der VM an, glaubst du ernsthaft, daß das funktionieren würde und du als Entwickler diese Laufzeit garantieren kannst?
Klar, nicht weniger als bei Assembler. Die Java-VM ist natürlich relativ komplex, aber wie wäre es mit einer kleinen überschaubaren VM für eine kleine, überschaubare Sprache? Die VM dabei geschrieben in Assembler. Merkste was?
Apfelbirne schrieb:
Mir geht es nicht ums Recht behalten, sondern darum euch zu informieren und auch zu belehren.
Naja, du fischst dir ständig semiwahre Behauptungen und leere Argumente aus dem Nichts, nur um dir nicht einzugestehen, dass du falsch liegst.
-
Apfelbirne schrieb:
Mir geht es nicht ums Recht behalten, sondern darum euch zu informieren und auch zu belehren.
Du willst uns Scheiße belehren, redest von Zeug vom dem du keine Ahnung hast.
-
Hallo,
Bei den aktuell auf dem Mars aktiven Rovern war kein Java im Spiel.
Quelle: http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/37499/1/05-0539.pdfAusschnitt:
The Flight Software is coded primarily in ANSI C, with some targeted assembly code and some C++. The size of the system, in source lines of code (SLOC), is [300K] but this value does not include the operating system.
Although many aspects of the design are objected-oriented, the features of the language incorporating inheritance and polymorphism are not exploited. We have found that when implemented to their fullest extent in C++, these constructs result in detrimental code size and add the potential for non-deterministic behavior. These costs, especially in time and effort to achieve a robust implementation, outweigh the benefits.
-
Hi,
rein von der Sache her ist vieles möglich, Wirth hat auch demonstriert, dass man ein Betriebssystem in Modula2 Schreiben kann. Soll angeblich sogar fehlersicher gewesen sein. Aber obs einen Sinn ergibt, das ist immer die andere Frage.
Einen über Jahrezehnte gehenden Betrieb kann man auch dadurch erreichen, dass man einen Hardware-Timer hat, der jeweils nach einer Vorwarnung (Zustand speichern wenn noch möglich) alle n Zeiteinheiten einen Hardware-Reset auslöst.
Auch könnte man sämtliche Funktionsaufrufe (oder zumindest die wichtigsten) in einem hardwareunterstützten Array mit hardwareunterstützter Zeitüberwachung anordnen, das bei nicht erfolgtem Rücksprung innerhalb einer vorgegebenen Maximalzeit einen Zwangsrücksprung auslöst.
All das sind aber sehr tiefe Eingriffe in die eigentliche Programmklogik, die um so problematischer werden, je komplexer die verwendete Programmiersprache und Laufzeitumgebung ist.
Auch ist bei einer Raumsonde kein allzu großer Verarbeitungsaufwand nötig, da man sich da auf das wirklich notwendige beschränkt. Es gibt also eigentlihc nichts, was mehr als ASM und C erfordert oder rechtfertigt.
Gruß Mümmel
-
muemmel schrieb:
Es gibt also eigentlihc nichts, was mehr als ASM und C erfordert oder rechtfertigt.
Bei 300k LOC (ohne OS) könnte man schon drüber nachdenken..
-
thread-leser schrieb:
Apfelbirne schrieb:
Schau dir das mit den 35 Jahren und der VM an, glaubst du ernsthaft, daß das funktionieren würde und du als Entwickler diese Laufzeit garantieren kannst?
Klar, nicht weniger als bei Assembler. Die Java-VM ist natürlich relativ komplex, aber wie wäre es mit einer kleinen überschaubaren VM für eine kleine, überschaubare Sprache? Die VM dabei geschrieben in Assembler. Merkste was?
Wir sind hier nicht beim Thema Neuerfindung einer Sprache um dafür dann erst eine VM in Assembler zu programmieren.
Das macht auch keinen Sinn, da es Schwachsinn ist.Denn anstatt die VM zu programmieren kannst du gleich damit anfangen die eigentliche Software in Assembler für das Weltraumdings der ESA/NASA usw. zu schreiben.
-
Braunstein schrieb:
Hallo,
Bei den aktuell auf dem Mars aktiven Rovern war kein Java im Spiel.
Quelle: http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/37499/1/05-0539.pdfAusschnitt:
The Flight Software is coded primarily in ANSI C, with some targeted assembly code and some C++. The size of the system, in source lines of code (SLOC), is [300K] but this value does not include the operating system.
Although many aspects of the design are objected-oriented, the features of the language incorporating inheritance and polymorphism are not exploited. We have found that when implemented to their fullest extent in C++, these constructs result in detrimental code size and add the potential for non-deterministic behavior. These costs, especially in time and effort to achieve a robust implementation, outweigh the benefits.Das sage ich doch schon die ganze Zeit.
[quote="Zeus"]
Apfelbirne schrieb:
Mir geht es nicht ums Recht behalten, sondern darum euch zu informieren und auch zu belehren.
Du willst uns Scheiße belehren, redest von Zeug vom dem du keine Ahnung hast.
Ich gebe nur wieder wie es bei der NASA und ESA gesehen wird, wenn du also weiterhin glaubst es besser zu wissen, dann kannst du ja die NASA und ESA vollscheißen und versuchen da dein Javading durchzudrücken.
Ich aber sage dir, daß du dort gehörig auf Widerstand treffen wirst, manche werden dich auch für besonders doof halten oder dich nicht mehr ernst nehmen und ignorieren.
Ihr glaubt allen ernstes es besser zu wissen als ich, schön, aber habt ihr schonmal darüber nachgedacht, warum die NASA und ESA Java bei solchen Sachen nicht nutzt?
Recherchiert mal, dann werdet ihr auf all die Dinge stoßen, die ich hier schon mehrfach genannt habe.
-
Was haben Spezialanwendungen aus Luft- und Raumfahrt jetzt eigentlich genau mit der Frage zu tun was eine Systemprogrammiersprache ist und was nicht
-
Weisst du überhaupt noch, wofür du eigentlich argumentierst? Du meintest, dass es eine strikte Trennung für Systemprogrammiersprachen gibt und darüber diskutieren wir. Keiner von uns will die Steuereinheit in den ICEs mit PHP programmiert sehen.
Deine Argumente:
- Laut Definition keine VM oder APIs => Ist aber deine eigene Definition
- Man muss den AVX-Befehlssatz einbetten können => Da gibt C/C++/D auch nichts vor
- Vollständig bewiesene Fehlerfreiheit muss möglich sein => Kann man für alle "deterministischen" Sprachen oder für keine
- Harte Echtzeitfähigkeit => Wenn für C möglich, dann auch für C, das in einer VM, die in C geschrieben ist, läuft
- 35 Jahre Laufzeitgarantie lassen sich mit Assembler aber nicht mit VM garantieren => Wenn du die VM in selber Qualität in Assembler programmierst und die Anwendungslogik in irgendeiner Skriptsprache mit selbiger Codequalität, nimmt sich das nichts
Dann diskutierst du manchmal von einem versuchten wissenschaftlichen Standpunkt und manchmal ziehst du de facto-Beispiele heran. Und dass du dich hier von Braunstein bestätigt fühlst, zeigt nur wie wenig du überhaupt unsere Posts verstanden hast.
-
Und was das "Beweisen der Fehlerfreiheit" angeht ist C/C++ unbrauchbar. Das war zumindest die Take Home Message unserer Echtzeitsysteme Vorlesung...aber das nur am Rande, hat ja auch nichts mit dem Thema zu tun...
-
Hi,
selbst wenn man die Fehlerfreiheit von C beweisen kann, so ists doch noch was anderes auch die Fehlerfreiheit des Compilers zu beweisen, und der ist immer bei jeder Übersetzung (selbst bei Assembler) mit im Boot.
Alternativ kann man aber das ganze in C (oder sonst einer Sprache) schreiben und nicht automatisch übersetzen, sondern ein Mensch mit ausreichender Erfahrung und Sorgfalt setzt sich hin und spielt selbst Compiler.
Gruß Mümmel
-
Bewiesen fehlerfreies Programm? Soll das heißen, daß es tut, was die Spezifikation verlangt? Dann muß ja die Spezifikation bereits in einer exakten Sprache niedergeschrieben werden. Und wer sagt uns dann, daß die so niedergeschriebene Spezifikation das ist, was wir eigentlich haben wollen? Irgendwo bleibt da immer eine Lücke, die bisher nur denkende Menschen ausfüllen können.
