Aristoteles hat folgendes geschrieben:

Wenn man da keine krassen Optimierungen durchführt kann auf einem 2500+ die Darstellung von sin(x)*x durchaus eine halbe Sekunde dauern, und sowas sieht man. Von daher kann ich die Beobachtung vom Harald durchaus nachvollziehen.

Also hier[tm] mache ich 10 Millionen Berechnungen von sin(x)*x mit x = Schleifeniterator 0.7s. Mit Lächerlichen 1280 Iterationen für übliche Bildschirmauflösungen befinde ich mich außerhalb der Messbarkeit mit time. Ich glaube dir gern, daß man bei Grafikdarstellng viel falsch machen kann, aber wenn man es richti macht, schaut man nur in den seltensten Fällen einem Graphen beim Zeichnen zu. Und das Berechnen der einzelnen y-Werte ist mit Sicherheit nicht das Problem.

tommie-lie hat folgendes geschrieben:

Also hier[tm] mache ich 10 Millionen Berechnungen von sin(x)*x mit x = Schleifeniterator 0.7s. Mit Lächerlichen 1280 Iterationen für übliche Bildschirmauflösungen befinde ich mich außerhalb der Messbarkeit mit time. Ich glaube dir gern, daß man bei Grafikdarstellng viel falsch machen kann, aber wenn man es richti macht, schaut man nur in den seltensten Fällen einem Graphen beim Zeichnen zu. Und das Berechnen der einzelnen y-Werte ist mit Sicherheit nicht das Problem.

Doch, ist es! Gerade das Berechnen der y-Werte verschlingt die meiste Zeit.

Es macht natürlich einen Unterschied, ob du die Funktion "sin(x)*x" in eine for-Schleife setzt, oder ob du ein Programm schreibst, in dem man eine beliebige Funktion (auch beliebig verschachtelt) eingeben kann, und das diese Funktion zeichnet.

Mit lächerlicher Iteration kommst du da nicht weit, und das ist dann auch kein Einzeiler.

Für sin(x)*x braucht mein Programm 0,05 sek. Aber daran habe ich hart gearbeitet, der Wert von sin(x^2) lag, wenn ich mich richtig erinnere, mal bei 0,6 sek.

Wenn man mal noch normale Anforderungen stellt. Also nicht so gut zu sein wie Mathematica dann kann man solche Spielereien wie Polstellen, Frequenzanalyse etc sein lassen und x-Bildschirmauflösung mal iterieren.
Wenn du 0,6 s brauchst dann ist dein Parser schlecht.

Meine allerersten Versuche in diese Richtung arbeiteten mit strings Für jeden x-Punkt wurde neu geparst und sinx etc war in Software (Taylorreihen) emuliert ohne hardware (unit math) und es hat nicht so lange gedauert. Also irgendetwas machst du falsch.

kannst ja mal in nem neuen Topic deinen Source posten, denn abgesehen von unterschiedlichen Compilern kann man meistens am Source das meiste drehen.

Allesquarks hat folgendes geschrieben:

Wenn du 0,6 s brauchst dann ist dein Parser schlecht.

Wenn ich mich recht entsinne, lag die Dauer in dieser Größenordnung. Da hatte er auch jede Zeile neu geparst, weil das das Einfachste war. Mittlerweile macht er das nicht mehr und die Zeiten liegen bei solchen Funktionen im Bereich von 0,05 sek. Wenig komplexere Funktionen habe ich ja im Eingangsbeitrag hier reingeschrieben. Insgesamt kann das Programm Funktionen, die beliebig aus 34 Operatoren und Funktionen zusammengesetzt sind, zeichnen; mit der Zeit gebe ich mich da zufrieden.

Mit den 0,6 sek wollte ich ausdrücken, dass ich dem Harald seine Aussage durchaus glaube, bei der Funktion sin(x)*x beim Zeichnen zusehen zu können, da ich schonmal die selbe Erfahrung gemacht habe.

Aristoteles hat folgendes geschrieben:

Mit den 0,6 sek wollte ich ausdrücken, dass ich dem Harald seine Aussage durchaus glaube, bei der Funktion sin(x)*x beim Zeichnen zusehen zu können, da ich schonmal die selbe Erfahrung gemacht habe.

Ja, klar, wenn ich nur Schrott programmiere kann ich dir die gleiche Funktion auch in drei Wochen plotten lassen.
Kleiner Bleistift mit gnuplot: sin(x)*x mit x € [-10000;10000] wird bei mir in wenigen Millisekunden geplottet, und mit "wenigen" meine ich nicht 500, das Fenster mit dem Graph erscheint instantan. Ich weiß auch nicht, ob dir die Bedeutung der Aussage ganz bewusst ist. Sie würde bedeuten, daß kein CAD-Programm in der Lage wäre, kubische Splines ohne Verzögerung zu zeichnen, was zumindest auf meinem Core Duo 1,83GHz nicht stimmt.
Es mag durchaus sein, daß man es hinkriegt, daß das Berechnen von einigen tausend Werten in der Größenordnung von Sekunden gemessen werden kann, aber meine Aussage, daß man dann irgendwas falsch macht, bleibt dennoch gültig, denn Gegenbeispiele gibt es bei freier und nicht-freier Software genug, und die Leute, die das programmieren, können auch n icht zaubern.

tommie: unsere Aussagen unterscheiden sich nur in der Behauptung

Zitat:

Wenn man unter Windows dem Zeichnen eines Graphen zuschauen kann, hat man irgendwas falsch gemacht

Ich bin eher der Meinung, dass man solche Schlüsse erst nach einer Nutzen-Bilanz machen kann.

Mal ne andere Frage: Aus wievielen Splines besteht denn dein Modell? Außerdem ist kubisch in diesem Fall (da es sich um ein CAD-Programm handelt) mehrdeutig, daher die Frage: Meinst du den Grad der Splines? Oder meinst du die Dimension des Darstellungsraums?

Allgemein lässt sich sagen, dass Splines in Sachen Plotten wesentlich einfacher zu handhaben sind, als komplexe Funktionen. Splines bestehen ja bloß aus Polynomen...

EDIT:
Habe bei meinem Programm jetzt interessehalber nochmal genau gemessen: Es braucht für sin(x)*x mit x in [-10000, +10000] 62 ms: Ziemlich genau 32 ms für das Zeichenen des Koordinatensystems und der Funktion, 30 ms für das Berechnen der Funktionswerte. Aber wie gesagt, es ist einigermaßen optimiert. Dadurch hatte sich der Quelltext verdreifacht. Ist halt die Frage, wieviel Arbeit man sich machen will.

Aristoteles hat folgendes geschrieben:

Aus wievielen Splines besteht denn dein Modell?

In der regel wird ein Spline gezeichnet. Die Anzahl der Splines ist aber uninteressant, da eine Berechnung unabhängig von den effektiven Parametern immer genauso lange dauert.

Aristoteles hat folgendes geschrieben:

Außerdem ist kubisch in diesem Fall (da es sich um ein CAD-Programm handelt) mehrdeutig, daher die Frage: Meinst du den Grad der Splines? Oder meinst du die Dimension des Darstellungsraums?

Der Begriff "kubische Splines" bezeichnet im Allgemeinen ganzrationale Funktionen dritten Grades, egal ob es sich um CAD oder Schulmathematik handelt. Ich dachte an einen zweidimensionalen Projektionsraum, Splines im dreidimensionalen machen wenig Sinn, weil es dann Ebenen wären.

Aristoteles hat folgendes geschrieben:

Allgemein lässt sich sagen, dass Splines in Sachen Plotten wesentlich einfacher zu handhaben sind, als komplexe Funktionen. Splines bestehen ja bloß aus Polynomen...

Ob man jetzt sin(x) oder x^42 berechnet, ist für die FPU relativ egal. sin(x)*x besteht aber aus deutlich weniger Aufrufen an die FPU als a_1*x^3+a_2*x^2+a_3*x+a_4.
Ich möchte dich übrigens bitten, einmal Tests mit einigne hunderttausend Berechnungen durchzuführen, bevor du Aussagen machst wie "bestehen ja bloß aus Polynomen".

Robert_G hat folgendes geschrieben:

Kann ich nicht wirklich nachvollziehen. Bisher sind noch alle Binaries, die ich mit TurboDelphi kompostiert habe, merklich schneller gewesen als D7 Binaries mit gleichem Source code.

Schon mal in D7 FastMM eingebunden? Dieser wird nämlich auch in BDS 2006 verwendet. Und je nach Programmart rennt das Programm danach wie geölt.

Robert_G hat folgendes geschrieben:

Da ab BD2006 so schnieke Neuerungen wie statische class methods oder sealed overrides dabei sind lässt sich mit leicht verändertem Code nochmal einiges rausholen.

OK. Aber ob das die Welt ausmacht ...

Robert_G hat folgendes geschrieben:

Deine Vermutung á la "seit D5 nix mehr für neue CPUs gemacht" ist eigentlich falsch. IMO, generiert Delphi Code, der auf 486'ern läuft.

Und wer hat heute noch eine 486er laufen? Selbst zu D5-Zeiten waren diese PC's schon Oldtimer.

Aber ich denke ich werde morgen mal unser Programm mal mit BDS 2006 kompileren lassen (ist schon soweit vorbereitet) und mal einen kleinen Performancetest fahren lassen. Muß nur etwas finden das nicht primär durch den Persistenzlayer (DB-Anwendung) gebremst wird. Evtl. kann ich ja mal mit AQTime einen kleinen Vergleich fahren.

tommie-lie hat folgendes geschrieben:

Der Begriff "kubische Splines" bezeichnet im Allgemeinen ganzrationale Funktionen dritten Grades [...] Ich möchte dich übrigens bitten, einmal Tests mit einigne hunderttausend Berechnungen durchzuführen, bevor du Aussagen machst wie "bestehen ja bloß aus Polynomen".

Bei Verwendung von Splines, insbesondere wenn ausschließlich Polynome 3. Grades drin vorkommen, lässt sich die Berechnung ähnlich mit einer For-Schleife automatisieren wie du es oben bei der Funktion sin(x)*x gemacht hast. Es müssen bloß die Koeffizienten variiert werden, der Term an sich hat immer die selbe Struktur. Es gibt schnelle, iterative Lösungen.
Daher mein Kommentar. Ein Programm, das auf die Berechnung von Polynomen spezialisiert ist, ist daher nicht vergleichbar mit einem Programm, das Funktionswerte beliebig verschachtelter Funktionen berechnen kann. Das ist eine ganz andere Problematik.

Aristoteles hat folgendes geschrieben:

Ein Programm, das auf die Berechnung von Polynomen spezialisiert ist, ist daher nicht vergleichbar mit einem Programm, das Funktionswerte beliebig verschachtelter Funktionen berechnen kann. Das ist eine ganz andere Problematik.

Bissl stimmts schon, dass spezialisierte Programme schneller laufen. Aber auch allgemeine Funktionsplotter sind ohne große Optimierung sehr schnell, d.h. man sieht kein flackern. Und da muss man nicht schon 5 Jahren programmieren können - nein 1 1/2 Jahre reichen locker. Da macht man es sogar mit links, es flackerfrei ohne Optimierung zu bauen.

Hallo,

wenn der Parser zu langsam parst, hat delphifan doch etwas tolles komponiert:
www.delphi-forum.de/viewtopic.php?t=36946

Gruss Horst