Mathem. Parser: Endlich "fertig"

[dizzy]

Summdidummdidumm, habe heute mal meinen Parser "releasefertig" gemacht (hoff ich :)).

Im Anhang ein Archiv dass 2 Versionen enthält: Die "normale" Version als Delphi-Source, und die DLL-Version. Beide mit nem klitze kleinen Beispielprogramm, und ausführlichen readme's.

Ich betrachte das Teil jetzt als für "fertig genug" um es als Päckchen zu verschnüren und es als Freeware hier einzustellen.

Viel Spaß damit, und wenn Fragen sind... dafür sind wir ja hier ;)


MfG,
dizzy

[NicoDE]

Die Integration der DLL in andere Sprachen ist IMHO unnötig schwierig (wer gibt den Speicher bei komplexen Strukturen als Rückgabewert wieder frei? etc.). Hab es bei mir in out-Parameter geändert (und ShortString in PAnsiChar) und es so in einem Watcom-Projekt verwendet.

Gruss Nico

[dizzy]

:thuimb:
Hab noch nie zuvor eine DLL gebastelt. Danke für die Tipps - upgedatete Version im ersten Beitrag.

btw: Hast du ihn jetzt "richtig" im Einsatz, oder nur testweise? Wäre natürlich klasse, wenn das Teil tatsächlich jemand gebrauchen könnte... :stupid:

[NicoDE]

Zitat:

Zitat von dizzy

Hast du ihn jetzt "richtig" im Einsatz, oder nur testweise?

Hab im Moment keine Verwendung dafür und es nur mit Open Watcom C/C++ getestet (brauchte ich gerade für eine 16-Bit DLL), da mich das Projekt interessiert...

Hast Du in dem anderen Thread gesehen, dass die Bestimmnung der Zeitdauer im Performance-Test unter Windows XP x64 (amd64) merkwürdige Werte liefert?
(ich vermute mal es liegt an den Berechnungen mit den RDTSC-Werten)


Gruss Nico

[dizzy]

Zitat:

Zitat von NicoDE

Hast Du in dem anderen Thread gesehen, dass die Bestimmnung der Zeitdauer im Performance-Test unter Windows XP x64 (amd64) merkwürdige Werte liefert?
(ich vermute mal es liegt an den Berechnungen mit den RDTSC-Werten)

Ach ja, ganz vergessen da zu antworten :oops:. Auf der ersten Seite in diesem Thread hatte auch jemand so interessante Ergebnisse. Wieder besseren Wissens hab ich auch das damals auf die Messmethode geschoben, und ich tu's wieder :)
Ich nehme mal an, dass beide OSs auf ein und der selben Maschine laufen? Dann wäre der "Übeltäter" nämlich offensichtlich. Dann haben wir nen Bug in der Debugversion ;)

Danke nochmals für's Testen, insbesondere mit C. Da bin ich aber froh, dass das hin haut! (btw: Bei diesem Test sah man ja recht deutlich, dass ein 64-Bitter mit nem 32-Bit OS so überhaupt gar keine Vorteile bringt. Sollten die Messwerte unter Win64 tatsächlich so stimmen, so muss ich sagen, dass die Dinger mit dem richtigen OS aber mal gut abgehen :mrgreen:)


gruss,
dizzy

[NicoDE]

Zitat:

Zitat von dizzy

Dann wäre der "Übeltäter" nämlich offensichtlich. Dann haben wir nen Bug in der Debugversion ;)

Werd's mir bei Gelegenheit mal im Detail ansehen (sieht aus wie die Mess-Methode von Hagen).

Zitat:

Zitat von dizzy

(btw: Bei diesem Test sah man ja recht deutlich, dass ein 64-Bitter mit nem 32-Bit OS so überhaupt gar keine Vorteile bringt.

Ich finde es schon erstaunlich, dass man mit einem Core-Takt von 1800MHz die Performace eines P4 mit 2800MHz erreicht.
Ansonsten bringt es keine Vorteile, wie auch :D

Zitat:

Zitat von dizzy

Sollten die Messwerte unter Win64 tatsächlich so stimmen, so muss ich sagen, dass die Dinger mit dem richtigen OS aber mal gut abgehen :mrgreen:)

Unter x86-64 ist die Daten-/Code-Ausrichtung wichtig (ist bei ia64 noch schlimmer) da es sonst andauernd zu internen Alignment-Exceptions kommt (bekommt das Programm nichts von mit). Dadurch kann die Performance auf etwa 50% runter gehen.


Gruss Nico

[dizzy]

Zitat:

Zitat von NicoDE

(sieht aus wie die Mess-Methode von Hagen)

Ist sie auch :)

Zitat:

Zitat von NicoDE

Ich finde es schon erstaunlich, dass man mit einem Core-Takt von 1800MHz die Performace eines P4 mit 2800MHz erreicht.

Nuja, aber die 64-Bit spielen da aber scheinbar keine so große Rolle. Mein 2500+ @~3131+ (2.16 GHz real) macht da ja bessere Werte als der neue... Ich stehe was den Desktopeinsatz angeht den 64ern skeptisch gegenüber. Aber das ist nen völlig anderes Thema.

Zitat:

Zitat von NicoDE

Unter x86-64 ist die Daten-/Code-Ausrichtung wichtig (ist bei ia64 noch schlimmer) da es sonst andauernd zu internen Alignment-Exceptions kommt (bekommt das Programm nichts von mit). Dadurch kann die Performance auf etwa 50% runter gehen.

Okay, ich versteh knapp die Hälfte. Aber klingt gut! :lol: (Ich mutmaße mal das hat was mit der "Superskalarität" (was ein Wort) zu tun? *insblauerat*)


n8i,
dizzy

[NicoDE]

Zitat:

Zitat von dizzy

Okay, ich versteh knapp die Hälfte.

x86-64 ist die Architekturbezeichnung (bei Microsoft auch kurz x64 ;)).
(i386, p4 = x86 und amd64 = x86-64)

Der Prozessor löst eine Exception aus, wenn auf nicht ausgerichtete Adressen zugegriffen wird (gibt's beim x86 nicht - siehe SetErrorMode).
Beispiel: Lesen eines Word-Wertes von einer ungeraden Adresse (x86 = zwei Lesezugriffe, x86-64 = Exception).

[SirThornberry]

Find den Parser supi. Am Beispielprogramm stört mich nur das Position = poDesktopCenter ist. Wenn man 2 Bildschirme hat landet das programm zur Hälfte auf dem einen und die andere Hälfte auf dem zweiten bildschirm. Besser wäre da poScreenCenter..

[shmia]

Könnte man nicht die 8 Variablen auf beliebig viele erweitern, in dem man eine Callback-Methode verwendet um die Variablen aufzulösen ?
Also anstatt maximal 8 Variablen von Aussen der Klasse TCQParser reinzugegeben, ruft TCQParser
das Event OnGetVariable auf wenn eine Variable in einen nummerischen Wert verwandelt werden soll.
Leider kann mein D5 den Sourcecode wegen einigen fehlenden Funktionen (Sign, SameValue, Sec, SecH, ...) nicht kompilieren. :cry: