Try..except beschleunigen

[magonline]

Hallo

Mir ist aufgefallen, dass bei häufigem einlaufen in die Fehlerbehandlungen von Try..except Blöcken, die Prozessorauslastung deutlich sinkt und somit die Gesamtzeit, zur Ausführung von z.B. Berechnungen, zunimmt. Es scheint so, als ob eine einfache Exception Behandlung eine Art sleep- Funktion integriert hat.

Hat vielleicht jemand eine Ideee, wie man solche Exception-Blöcke beschleunigen kann ?

[Sherlock]

Also ich bin generell der Meinung, daß man solche Konstrukte eher zurückhaltend einsetzen sollte, wenn man weiß, daß an einer bestimmten stelle etwas schief gehen kann, dann sollte man die Beteiligten Objekte halt selber prüfen und gar nicht erst in die Falle hineinlaufen (einfachstes Beispiel Division durch 0). Manchmal lässt es sich nicht vermeiden, aber bei Berechnungen sollte man die Dinger wirklich alle wegbekommen.

Edit: Willkommen bei der :dp:

Sherlock

[Laufi]

Hallo

Du weisst schon das exceptions übersetzt Ausnahmen heisst und deshalb nur selten vorkommen also spielt es keine rolle wie schnell sie sind! :lol:

Liebe grüsse
Laufi

[Sherlock]

Ich denke, er meint, daß die Anweisungen, die im Try-Teil einer Exception ausgeführt werden langsamer laufen. Und die werden immerhin immer ausgeführt, bis es halt knallt ;)

Sherlock

[RavenIV]

Ich bin der selben Meinung wie Sherlock.
try..except hat seine Berechtigung, sollte aber nur sparsam eingesetzt werden.

Bei Berechnungen, Typumwandlungen (z.B. StrToInt), DB-Abfragen, usw. kann man vorher prüfen, ob alles OK ist.

Darüber hab ich mich schon öfters hier ausgelassen.
Somit verweise ich auf die Suchfunktion zur weiteren Begründung...

[Luckie]

Ein try-except Block erfordert immer eine erhebliche Belastung der CPU durch den zusätzlichen Code, der ausgeführt werden muss, um eine Exception sicher abfangen zu können.

[Sherlock]

Ich gebe hier mal ein Extrembeispiel (dafür wie man es nicht machen sollte), einer meiner Kollegen hat vor Jahren mal in die dpr ein try...except um alles gepackt. :lol:

Sherlock

[magonline]

Leider ist es nicht möglich, auf diese try..except Blöcke zu verzichten, da sie meinen Formelparser "Nan" und "DivZero" tauglich machen. Was mir halt nicht einleuchten will ist, dass die Prozessorauslastung, bei häufigen Ausnahmebahandlungen, herunter geht und nicht ansteigt.

[Sherlock]

Bist Du sicher, daß Du die Prüfung auf "DivZero" nicht selber vornehmen kannst?

Sherlock

[magonline]

Es geht weniger um das Können, als vielmehr darum, dass ich einen großen Haufen von dynamischen Parser-Funktionen umschreiben müsste.

[Laufi]

hallo!

Ich habs schonmal gesagt :) Wenn man probleme hat mit division durch 0 muss man nur Set8087CW($133f); schreiben dann kommen die fehler nicht mehr sondern der wert wird von alleine unendlich und so.

Liebe Grüsse
Laufi

[magonline]

Das scheint tatsächlich zu funktionieren. Gibts irgendwo eine detailierte Beschreibung der FPU Funktionen/Befehle ?

[smudo]

Schade, dass immer mehr über das "warum machst du denn das so" als über die eigentliche Frage diskutiert wird...
Try - Except - Blöcke sind m.E. nach unvermeidlich, wenn man mit Transactions arbeitet. Und das können schon mal ziemlich große Blöcke werden. Die Beantwortung der eigentlichen Frage wäre also schon sehr wertvoll ;)

[FAlter]

Hi,

Zitat:

Zitat von magonline

Das scheint tatsächlich zu funktionieren. Gibts irgendwo eine detailierte Beschreibung der FPU Funktionen/Befehle ?

Schnell mal aus nem Code rauskopiert:

Delphi-Quellcode:

//FPU CW setzen... siehe z. B. unter
//http://www.website.masmforum.com/tutorials/fptute/fpuchap1.htm#cword

{  Binär: XXXX0011XXXXXXXX (X - unverändert)
             ^             Unterscheidung zw. +INF und -INF auf alten FPUs
              ^^           Rundung: nach normalen Rundungsregeln auf-/ab
                ^^         Genauigkeit: Extended (auf manschen Systemen
                                                   komischerweise auf Double
                                                   gestellt)
                    ^^^^^^ versch. Gleitkommaexceptions
}
Set8087CW((Get8087CW and $F3FF) or $0300);

In dem Kommentar ist erklärt, was danach getan wurde.

Mfg
FAlter

[magonline]

Meine angezeigte Prozessorauslastung beträgt nun über 50% (statt zuvor 20%).

Wird die Auslastung der FPU im Taskmanager angezeigt ?

Also, kann es sein dass die FPU ausgelastet ist und die CPU so lange in Idle geht ?

[mkinzler]

Die FPU ist doch Teil der CPU (neben ALU)

[sirius]

Zitat:

Zitat von Sherlock

Ich gebe hier mal ein Extrembeispiel (dafür wie man es nicht machen sollte), einer meiner Kollegen hat vor Jahren mal in die dpr ein try...except um alles gepackt. :lol:

Sherlock

Da ist dein Kollege nicht alleine. Windows hat sogar einen Unhandled-Exceptionhandler vorgesehen :zwinker:



Zum Thema:
ein einfacher try-Except oder try-finally-Block bremst dein Programm nicht aus. Erst, wenn wirklich eine Exception auftritt, geht es los. Dies apssiert aber auch, wenn kein Except-Block existiert. Bei letzterem stürzt der Thread oder das Programm ab.
Um jede Ereignisbehandlung hat die VCL einen try-Except-Block gelegt.

was passiert nun bei try:
Es gibt für jeden Thread einen Thread-Context. Der befindet sich im Segement fs. Und dort an erster Stelle. Wenn irgendwo eine Exception auftritt, schaut windows an die Adresse fs:[0]. Und dort steht ein Pointer auf einen Record. Der Record besteht aus 3 Teilen und wird beim Befehl try angelegt:
-Register EBP
-Adresse des Except (finally) Blocks (man sagt auch Adresse des "save Place")
-Adresse des des bisherigen ExceptionRecords (es wird also eine Liste der Records aufgebaut
So, jetzt kommt ein Satz Halbwissen:
Der Record muss zwingend auf dem Stack liegen, dadurch ist auch klar, welchen Wert ESP zum Zeitpunkt des try hatte.

Was passiert also bei einem try genau? Es werden 3 Befehle ausgeführt:

Delphi-Quellcode:

asm
  push ebp
  push @Exceptblock
  push fs:[0]
  mov fs:[0], esp
end;

Von Prozessorauslastung kann dabei keine Rede sein. Denn jetzt kommt ganz normal der Code hinter dem try, egal ob diese 4 Befehle davor stehen.
Und hinterher (wenn keine Exception auftrat) muss natürlich der Stack wieder aufgeräumt werden und der Wert an fs:[0] zurückgesetzt:

Delphi-Quellcode:

asm
  //Beispiel
  pop fs:[0]
  pop edx
  pop edx
end;

Fertig.

Im Übrigen setzt Delphi um jede Funktion, die dynamische Arrays oder strings oder Variants verwendet, einen try-finally Block

[3_of_8]

Zitat:

Zitat von Laufi

Wenn man probleme hat mit division durch 0 muss man nur Set8087CW($133f); schreiben dann kommen die fehler nicht mehr sondern der wert wird von alleine unendlich und so.

Das ist nicht portabel. Und außerdem mathematisch falsch. 1/0 ist undefiniert und nicht unendlich. Von einem Matheparser würde ich erwarten, dass er bei so einer Berechnung eine Fehlermeldung bringt bzw. die 1/0-Stelle überspringt.

[Laufi]

Hallo!

Ja 1/0 ist schon undefiniert aber 1 durch eine ganz kleine zahl gibt eine sehr grosse zahl also kann sagen 1/0 ist sowas wie unendlich wenn es doch schon ein unendlich gibt! für was sonst :) man kann es sich auch besser vorstellen wenn man die berechnung zeichnen will anstatt einfach eine exception :roll:

liebe Grüsse
Laufi

[3_of_8]

1/x ist als sgn(x)*unendlich definirt, wenn x gegen 0 geht. (Grenzwertrechnung)
Aber 1/0 ist undefiniert, und von einem mathmatischen Parser würde ich erwarten, dass er mathematisch korrekt arbeitet.

[sirius]

Zitat:

Zitat von 3_of_8

Und außerdem mathematisch falsch. 1/0 ist undefiniert und nicht unendlich.

Wer sagt das?
1/0 ist sehr wohl unendlich und wird auch von der Natur bewiesen (bzw. brauch man um die Natur zu beschreiben). Und die gängigen Mathematikprogramme bringen auch richtigerweise genau dieses Ergebnis.

[Neutral General]

3_of_8 hat Recht: Wiki

[Tyrael Y.]

Zitat:

Zitat von sirius

Zitat:

Zitat von 3_of_8

Und außerdem mathematisch falsch. 1/0 ist undefiniert und nicht unendlich.

Wer sagt das?
1/0 ist sehr wohl unendlich und wird auch von der Natur bewiesen (bzw. brauch man um die Natur zu beschreiben). Und die gängigen Mathematikprogramme bringen auch richtigerweise genau dieses Ergebnis.

Ich werf mal auch meinen Senf dazu.

In der Mathematik wird 1/0 in einem Therm als unendlich angenommen, da davon ausgegangen wird, daß wenn der Teiler kleiner wird der Gesamtausdruck größer werden muss. Dabei ist die Annahme das 0 nicht exakt 0 ist sondern fast 0 ist. Genau unter dieser Annahme ist die Deutung richtig zu sagen, daß 1/0 = unendlich ist.

Falls man aber davon ausgeht, dass man von exakt 0 redet, ist dieser Ausdruck undefiniert.
Nehmen wir das einfache Beispiel aus der Grundschule.
Ich habe einen Apfel und teile es durch niemanden, wieviele Äpfel hat jeder bekommen?
Es gibt keinen "jeder"...daher bleibt es undefiniert.

So gesehen habe beide Recht.

[dominikkv]

Zitat:

Zitat von Tyrael Y.

So gesehen habe beide Recht.

Nein

1/0 = Undefiniert
1/(fastnull) = Definiert

Punkt

[3_of_8]

Anzunehmen, dass 1/0 irgendeinen festen Wert hat ist einfach mathematisch nicht haltbar, weil es sich selbst widerspricht.

[sirius]

Mir fehlt grad die Motivation die Bedeutung hinter x/0 zu erklären, die übrigens in der Physik (elektrische Felder) auch tatsächlich existiert (im Gegensatz zu dem Apfelbeispiel kann man sich das da auch vorstellen). Es mag sein (es ist hin und wieder so), dass die Mathematik da in ihren Definitionen an ihre Grenzen stößt. Selbst bei Wiki steht ja, dass man sich da mit dem Limes behilft. Man kann eben das Problem mit x/0 nicht einfach ausschließen und als nicht existent ansehen. Hier ist ein schönes Java-Applet zu der bekannten Tatsache, dass eine Gerade auch nur ein Kreis mit dem Radius=unendlich ist. Und genau dieser Radius entsteht nämlich in einer Berechnung mit einem Nenner=0. Wer sich weiter dafür interessiert kann mal für 2 Kugelladungen (oder 2D Kreisladungen) mit gleicher Ladung unterschiedlicher Vorzeichen die Äquipotenzialflächen (bzw. Linien) ausrechnen.
Und genau hier sind wir an einem Unterschied zwischen Theorie und Praxis. In der Theorie kann man da gerne eine Grenzwertbetrachtung machen. In der PRaxis (und damit zurück zum Thema hier) will man einfach, dass der Rechner bei x/0 unendlich ausgibt. Fertig.

Ein ähnliuches Beispiel ist die imaginäre Einheit i. Die ist definiert mit i^2=-1, aber nicht mit sqrt(-1)=i. Kann man so akzeptieren. Aber beim Lösen einer quadratischen Gleichung, schaut sich jeder nur den Nenner an und stellt fest, wenn dieser <0 ist kommt etwas Komplexes bei raus.

Und woran hat sich nun der Rechner zu halten? Bei IEEE (Standard for Binary Floating-Point Arithmetic) hat man beides in Betracht gezogen. Da gibt es einen extra Unterpunkt (7.2.) für "Division by Zero". Wenn der Divisor 0 ist und der Divident eine endliche Zahl ungleich 0, dann soll das Ergebnis unendlich (vorzeichenrichtig) sein und das Exception Flag gesetzt werden. Da kann sich dann jeder raussuchen, was er braucht.

Edit:
Vielleicht noch etwas schönes, was zwar jeder kennt, aber in dem Zusammenhang noch einmal erwähnt werden kann:
Man betrachte die geometrische Methode Fall2.