Avatar von Daelach
  • Daelach

mehr als 1000 Beiträge seit 11.05.2004

Re: Man kann solche Fehler auch ohne Runtime-Overhead und - Errors ausschließen

MetaCircularEvaluator schrieb am 20.03.2017 01:39:

Will man aber z.B. so etwas "einfaches" wie Sicherheit vor Null Pointer Dereferenzierungen wird es in C artigen Sprachen schon sehr aufwendig.

Nullpointer kriegt man doch eigentlich nur in wenigen Fällen: wenn man den Pointer noch nicht belegt hat (deswegen initialisiert man den bei der Deklaration auf NULL), oder wenn eine Ressourcen-Allokation gescheitert ist. In letzterem Falle muß man sowieso prüfen, ob das geklappt hat, weil man sonst die gewünschte Aktion nicht tun sollte.

Wenn man dann auch z.B. irgendwelche Garantien bezüglich Multiprocessing haben will, wird es sogar noch komplizierter.

Ja, race conditions können da ziemlich eklig werden.

Ich würde nicht sagen dass so ein Benchmark fair ist. Es wird eine ganze Dimension von Anforderungen nicht abgedeckt, nämlich: Der Aufwand überhaupt ein Programm zu erstellen und dann dessen langfristige Maintainability.

Doch, gleich beides. Jeder Tag, den der Lowlevel-Programmierer mit dem Debuggen irgendeiner Pointerproblematik verbringt, hat der FP-Programmierer für inhaltliche Dinge gewonnen. Und Programme wie Crafty sind schon sehr alt und werden immer noch weiterentwickelt.

Gegeben das die Code Mengen im typischen Businessbereich wirklich sehr groß sind (tausende male die Größe einer Schach Engine)

Wenn man mit FP sehr große, schwierige Dinge lösen kann, sollte man erst recht vergleichsweise kleine und einfache lösen können. Also das kann es nicht sein. Zudem ist Minimax von der Grundidee her ohnehin schon ein funktionales Konzept. Außerdem ist die Information vollständig bekannt, und es gibt ein recht übersichtliches Regelset. Dennoch ist FP in dem Bereich praktisch nicht vorhanden.

Selbst sagen wir mal ein Faktor 4 langsamere Ausführung als C wäre kein Problem, weil das selbst bei ansonsten identischem Algorithmus nur 100 ELO weniger wären. Aber die Aufgabe lautet ja auch nicht, soviele Knoten wie möglich zu rechnen, sondern den besten Zug zu finden.

Zweitens glaube ich, dass man eine "unschlagbar gute" Schach-Engine z.B. auch im schnarchlangsamen Python bauen könnte, wenn sie den einfach mithilfe von irgendeinen Frameworks verteilt auf der Google Compute Engine oder auf Amazon AWS in der Cloud laufen könnte.

Eher nicht, weil Schach nicht besonders gut parallelisierbar ist. Das kommt daher, daß dann Teilbäume gerechnet werden, die bei Singlethread gar nicht erst gerechnet worden wären. Zudem wird der Kommunikationsoverhead auch immer schlimmer, je mehr daran rechnen.

Interessant hieran ist, daß man imperativ dabei (aus FP-Sicht) vom Regen in die Traufe gesprungen ist: die einzelnen Threads "kommunizieren" über die gemeinsame Hashtabelle auf einem Mehrkernrechner. Es ist also nicht nur mutable state, sondern auch noch shared mutable state. Schlimmer geht's nimmer, auf funktionaler Sicht.

Das zeigt aber auch eine grundsätzliche Schwäche im Konzept des immutable state: denn der Preis für die so einfach erzielbare Threadsicherheit lautet "stale data". Das spielt nur dann keine Rolle, wenn die Daten ohnehin voneinander unabhängig sind. Also in Aufgabenstellungen, die offensichtlich gut parallelisierbar sind, weil sie es von vornherein sind. Ericsson mit Erlang ist da ein Beispiel.

Nur heute ist die bisschen schlechtere Performance im Vergleich zu handoptimiertem C kein Totschlag Argument mehr.

In jeder Dekade hatte man die Rechenpower, von der es eine Dekade vorher noch geheißen hatte, ja wenn wir die nur hätten.

In Zeiten in denen Leute ihre IoT Microcontroller Projekte auch in JS Programmieren, zieht das "Raw-Performance" Argument in immer mehr Fällen einfach nicht mehr.

Guck Dir mal an, was ein Raspi an Strom braucht und was ein Cortex-M4. Das sind Welten, und speziell mobil merkt man das auch. Zudem widerspricht das den Betrachtungen von oben: Bei Riesenprojekten ist FP stark, bei Schach-Engines schon nicht mehr, weil sie zu klein sind, aber bei noch kleineren Controllern dann doch wieder? Das finde ich nicht schlüssig.

Naja, ist schon ein kompliziertes Projekt. Falls Du es nicht kennst, ein Blick drauf ist wirklich empfehlenswert: https://sel4.systems/

Teil des Deals war es natürlich auch, das Projekt sehr klein zu halten, deswegen Microkernel, und im Grunde die Probleme nicht zu lösen, sondern zu verlagern. DMA oder Dateisysteme? Sind genauso wie vorher, werden jetzt aber als "nicht im Microkernel" definiert. Erinnert daran, wie ein Mathematiker Löwen fängt: indem er sich in einen Käfig setzt und sich als "draußen" definiert. ;-)

Unbeschränkte Rekursion ist da natürlich ein Problem.

Die ist klar ein Programmfehler analog zur Endlosschleife, aber das meinte ich nicht. Stacküberlauf passiert auch dann, wenn die Funktion terminiert. Außer man hat tail recursion, klar. Aber ansonsten gilt eben nicht die vollständige Induktion, denn während Fac(10) noch korrekt berechnet werden kann, kann Fac(70) einen Stack Overflow auslösen.

Deswegen läßt man embedded die Finger von Rekursion, direkter wie indirekter, ist im MISRA-Standard auch ausdrücklich so geregelt. Nicht wegen Endlosrekursion, da wäre die iterative Formulierung mit Endlosschleifen ja dasselbe, sondern wegen Stack.

Dann zu sagen: "aber diese tollen neuen Sprachen mit ihren tollen Features, dass sind ja nur akademische Spielereien" führt zu nichts. Das ist kein Argument.

Nunja, man muß halt schon sehen, daß zwar vieles aus der Praxis mal aus dem akademischen Umfeld kommt, aber der Umkehrschluß gilt nicht. Weil viel aus dem akademischen Umfeld auch dort bleibt und eben nicht praxistauglich wird. Letzteren Fall meint man üblicherweise, wenn man etwas als "akademisch" bezeichnet.

Mein Punkt ist, dass man die Vorschriften, die für diese Bereiche gelten graduell auf andere Bereiche mit Software ausdehnen sollte.

Dann wäre das nicht mehr bezahlbar. Ein Browser nach Luftfahrt-Standards ist allenfalls möglich, wenn man den Feature-Umfang bis zur Unbrauchbarkeit reduziert. Schon in der Autoindustrie gelten erheblich laxere Ansprüche, weil Autos ansonsten für Privatleute nicht bezahlbar wären.

Heute läuft es samt einem gigantischen Brimborium auf 30€ Handys.

Klar, wenn man nicht wirklich darin etwas berechnet, dann ist die Langsamkeit ja auch nicht weiter bemerkbar. ;-) Aber guck Dir nur mal Eclipse an, das ist in Java und zäh wie Urschlamm. Besonders, wenn man Notepad++ im Vergleich gewohnt ist (in C++).

Um dann "JS WebApps" im Browser auszuführen... ;-)

Und wie sagte es Hitler hier (https://www.youtube.com/watch?v=ihpjq5T7r9Q [ohne Ton anschauen, falls Du es noch ich kennst!]):

*LOL* "don't cry, you can run bash on Windows 10 now."

Das bisschen Performance weniger mit allen möglichen Sicherheits-Checks enabled, das aus so einer Maschinerie herauströpfelt, wäre wahrscheinlich nicht mal mehr messbar.

Was mich zu der Frage zurückbringt, wieso es dann nichtmal eine starke Schach-Engine in einer funktionalen Sprache gibt, obwohl man viel weniger Zeit mit Debugging wegen Pointerproblemen verplempern müßte. Irgendwas stimmt da nicht.

Oder es kommt daher, daß funktionale Programmierung für die Problemstellung "Schach-Engine" an sich ungeeignet ist, aber nicht wegen der Größe. Mir fällt aber auch nicht ein, was genau es denn sein sollte. Denkbar wär's, so wie prozedurale Programmierung für GUI-Programmierung ja auch ein Horror ist.

Bewerten
- +
Anzeige