[Vienna-pm] anmerkungen ..

[gooly at gmx.at]

Am Montag, 28. Mai 2007 schrieb Bernd Petrovitsch:
> On Mon, 2007-05-28 at 19:56 +0200, gooly at gmx.at wrote:
> > Am Montag, 28. Mai 2007 schrieb Peter J. Holzer:
>
> [...]
>
> > > Wenn Du ein hartes Echtzeitsystem brauchst, solltest Du
> > > wahrscheinlich sowohl um General-Purpose-Betriebssysteme (Linux,
> > > Windows, ...) als auch um Perl einen großen Bogen machen.
> >
> > Warum Linux nicht, warum Perl nicht? Laut einer Untersuchung (aus
> > dem
>
> Weil es keine Garantien über Rechtzeitigkeit gibt, d.h. Garantien daß
> bestimmte Funktionen/Subsysteme/... maximale Ausführungszeiten haben.
Aber das kann (muss) man dann doch so programmieren - egal in welcher 
Sprache, auch in Perl, oder?
Gut, denkbar sind Systeme, die so schnell sein müssen, dass man zum 
Maschinencode greift, aber das ist eine andere Geschichte, und für mich 
nicht notewendig. Aber ich sehe keinen Nachteil Perls gegenüber anderen 
Sprachen, im Gegenteil, es ist sogar schneller als mach andere moderne 
Hoichsprache, wie zB Java.
>
> > Netz) aus Deutschland ist Perl (auch Python und so) viel schneller
> > programierbar als zB C oder C++ ist aber parktisch genauso schnell
> > in der Ausführung wie C (später kann man ja dann noch C erzeugen,
> > wenn man möchte). In C muss man aber jeden Kleinkram selber machen
> > und C++ und Java sind etwas für Romaschreiber - nix für Faule ;)
>
> Das hat alles mit "Echtzeitfähigkeit" nach akademischer Definition
> (und damit der wahren) nichts zu tun.
> Das Problem, daß die Welt mit dem Begriff "Echtzeit" hat ist, daß er
> in den letzten Jahren von diversen Ahnungslosen und/oder Ignoranten
> als Marketing/Sales-Buzzword für "sofort", "möglichst schnell",
> "unverzüglich", u.ä. technisch wenig sinnvolle Adjektive vergewaltigt
> wurde.
Das ist klar! Hat aber nicht mit der Programier-Sprachwahl zu tun?
>
> Tatsächlich bedeutet Echtzeitfähigkeit, daß eine gegebene
> Aufgabe/Algorithmus/Problem nicht nur Ergebnis-mäßig korrekt gelöst
> wird, sondern auch zusätzlich noch Zeitvorgaben einhält. Und es ist
> völlig irrelevant, welche Dimension die Zeitangabe hat. Z.B. könnte
> eine Bank definieren, daß sie am 4. Jänner 00:00 Uhr die
> Jahresabrechnung des letzten Jahres fertig haben will. Voila, wir
> haben einen festen Termin in der Spezifikation und damit ein
> Echtzeitsystem.
Deshalb kommen meine beiden zeitkritischen Teile in eigene Threads, auch 
deshalb notwendig, weil sie zeitlich ganz unterschiedlich (re-)agieren 
müssen und die Server-Cleint Struktur macht es leicht daraus 
ein 'distributet system' zu machen oder es so nach Belieben mit 
Hardware zu bewerfen ;)

Und wie bei jeder technischen Spezifikation kann man nie einen genauen 
Zielwert angeben, sondern immer nur einen zusammen mit einer zu 
erreichenden Tolleranz! Auch das ist in Perl erreichbar: Je nach 
Schnelligkeitsanforderung muss man halt auf das Gesamsystem schauen, 
oder wie Du sagt Hardware bewerfen :).

Und wenn Perl dann nicht schnell genug ist, ist wahrscheinlich auch C 
nicht schnell genug - auf diesem System.
Und wie gesagt, Perl ist praktisch so schnell wir C. Das Problem wäre 
also so nicht Perl.
>
> Und dann unterscheidet man noch zwischen "soft realtime" und "hard
> realtime":
> soft: Wenn man die Zeitvorgaben nicht einhält, dann ist der Verlust
> im wesentlichen der entgangene Nutzen.
>       Z.B. gibt es für den Verbindungsaufbau im ISDN eine maximale
> Dauer (20µs oder so). Wenn das bei einem normalen Telefonanruf mal
> länger dauert, wird nicht viel passieren ....
> hard: Der Schaden ist signifikant größer.
>       Typische Bsp. sind Flugzeug- und/oder Eisenbahnsteuerungen,
>       diverse Maschinensteuerungen. Wenn da was zu langsam
>       geregelt/gesteuert wird, dann kracht es idR ordentlich.
>
> [...]
>
> > bearbeiten und jeder Ansatz sollte selbständig sein. Mir ist lieber
> > mehrere kleine Programme die definierte kleine Aufgaben erledigen,
> > als ein Riesending für alles.
>
> Tja, der Hund bei Echtzeitsystemen als solchen ist, daß Du nur das
> gesamte System dann und nur dann echtzeitfähig bekommst, wenn Du ganz
> unten damit anfängst.
> Wenn nicht, dann muß du mit dem Restrisiko leben. Das mag größer oder
> kleiner sein und Du kannst es mit Hardware bewerfen, aber Du wirst es
> mit Hardware nicht erschlagen können.
Naja, es ist erschlagen, wenn Du Toleranzen definierts und innerhalb 
derer bleibst..

> Für mehr kann man z.B.
> http://ti.tuwien.ac.at/rts/teaching/courses/ezs besuchen ......
Interessante Slides, Danke.

Calli