D vs. C++

[Zeus]

Apfelbirne schrieb:

AFAIK ist Haiku & BeOS in C++ programmiert.

Nein intern mit C, nur dass diese OSen eine C++API anbietet.

[Apfelbirne]

Steffo schrieb:

Apfelbirne schrieb:

Aber Java werde ich dafür niemals verwenden, bei Java ist es sogar nichtmal erlaubt, dies für ein AKW zu nutzen.

Weshalb nicht? Selbst die NASA setzt das für einen Marsroboter ein!

Für welchen Marsroboter?
Quelle?

Mir ist kein Marsroboter bekannt, für den Java benutzt wird.
Macht auch wenig sinn, da Weltraumgeräte gegen Strahlung robust sein müssen und man daher auch bevorzugt neben hardend CPUs auch lahme CPUs in großer Fertigungstechnik verwendet, womit kein Platz für viel Leistung oder viel Speicherplatz da ist, was ein Java Programm aber mitsam VM benötigen würde.

Ich würde sagen, deine Behauptung ist eine Urban Legend.
Und eventuell verwechselst du das mit normalen Desktopanwendungen die die NASA durchaus für diverse Weltraumprojekte verwendet, aber diese Anwendungen laufen auf normalen Computern und nicht auf Weltraumgerät.

[volkard]

Naja, man kann's auch gant pragmatisch angehen.

public class OrbitalShip
{
  public static void main(String[] args)
  {
    while(true)
    {
      try
      {
         work();
      }
      catch(RadiationProblemHardwareException e)
      {
        Housten.out.print("We had a little Problem!");
      }		
    }
  }
}

[Zeus]

Apfelbirne schrieb:

Olaf Alaf schrieb:

:
Dir ist schon bewusst, dass man mit ein paar entsprechenden Handgriffen theoretisch in jeder Sprache Betriebssysteme bauen kann wenn man will? Und wo ziehst du die Grenze wie viele Handgriffe erlaubt sind? Du ziehst die Grenze genau da, wo D noch zu Systemsprachen gehört und Java nicht mehr. Völliger Unsinn.

Nö, siehe auch die zuvor erwähnten Punkte echte Echtzeitfähigkeit & vollständig bewiesene Fehlerfreiheit.

Äh, wo steht das, auf welche Programmiersprachen trifft solche Eigenschaft zu ?

[Apfelbirne]

Zeus schrieb:

Apfelbirne schrieb:

Olaf Alaf schrieb:

:
Dir ist schon bewusst, dass man mit ein paar entsprechenden Handgriffen theoretisch in jeder Sprache Betriebssysteme bauen kann wenn man will? Und wo ziehst du die Grenze wie viele Handgriffe erlaubt sind? Du ziehst die Grenze genau da, wo D noch zu Systemsprachen gehört und Java nicht mehr. Völliger Unsinn.

Nö, siehe auch die zuvor erwähnten Punkte echte Echtzeitfähigkeit & vollständig bewiesene Fehlerfreiheit.

Äh, wo steht das, auf welche Programmiersprachen trifft solche Eigenschaft zu ?

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.

[volkard]

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.

[Apfelbirne]

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]

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.

[Apfelbirne]

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.

[Apfelbirne]

Korrektur, es sollte heißen

Apfelbirne schrieb:

Bei Assembler geht das,

[volkard]

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.

[Apfelbirne]

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.

[Apfelbirne]

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?

[thread-leser]

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.

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

[Braunstein]

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

Ausschnitt:

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.

[muemmel]

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

[thread-leser]

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

[Apfelbirne]

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.

[Apfelbirne]

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

Ausschnitt:

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.