Entwickler-Ecke :: Thema anzeigen - Optimiert FreePascal deutlich besser als Delphi?

Aristoteles - So 24.09.06 19:16
Titel: Optimiert FreePascal deutlich besser als Delphi?

Hallo Leute!

Den Titel habe ich bewusst als Frage formuliert, da mir meine Messresultate ein wenig seltsam vorkommen. Nun:

Ich habe ein Projekt, an dem ich arbeite, von Delphi auf Lazarus portiert. Es handelt sich dabei um einen Funktionen-Plotter mit eingebauter numerischer Integration. Standardmäßig ist in dem Projekt eine Laufzeitmessung integriert. D.h., wenn er eine Funktion zeichnet, spuckt er in einem Feld aus, wie lange er dafür gebraucht hat. Genauso bei der numerischen Integration.

Bei der portierung auf Lazarus wurde der Code 1-zu-1 übertragen. Nun kam mir der Plottvorgang der Funktionen in dem von dem FreePascal-Compiler (Lazarus) kompilierten Programm wesentlich schneller vor, als in dem von Delphi kompilierten Programm. Das veranlasste mich zur Aufzeichnung der Laufzeiten:

1. Die Funktion sin(x^2+0,2):

Die Darstellung der Funktion:
_Delphi-Kompiliert: 145 ms
_FCP-Kompiliert: 70 ms

Die numerische Integration von 0 bis 10 mit 5000 Intervallen:
_Delphi-Kompiliert: 669 ms
_FPC-Kompiliert: 320 ms

1. Die Funktion (x+1)^2*sin(1/x):

Die Darstellung der Funktion:
_Delphi-Kompiliert: 227 ms
_FCP-Kompiliert: 130ms

Die numerische Integration von 0 bis 10 mit 5000 Intervallen:
_Delphi-Kompiliert: 1095 ms
_FPC-Kompiliert: 550 ms

Ergebnis: Die FreePascal-Kompilierten Programme waren stets etwa doppelt so schnell wie die Delphi-Kompilierten.

Noch ein paar Informationen:
1.Der Source-Code ist in beiden Fällen exakt gleich
2.Ich habe sowohl in Delphi als auch in Lazarus die Optimierung eingeschalten. Mir ist aber aufgefallen, dass des FPC-Programm unoptimiert schneller läuft, als der Delphi-Programm optimiert.
3. Die Ergebnisse der numerischen Integration stimmten überein, beide Programme zeichneten die Funktionen korrekt.
4. Delphi 7 Pers, Lazarus 0.9.16 mit FPC 2.0.2
5. Die Programme wurden nicht von der Entwicklungsumgebung aus aufgerufen, sondern aus dem Explorer.
Des weiteren wurde als Betriebssystem WinXP Home verwendet.

Nun meine Frage an Euch:
Hat jemand ähnliche Erfahrungen gemacht?
Generell: Kennt jemand die Gründe?

Würde mich mal interessieren. Weil mich das doch stutzig macht, dass die Unterschiede derart groß sind. Hätte eher gedacht, dass mögliche Unterschiede im 1%-Bereich liegen.

Viele Grüße, Aristoteles

Horst_H - Fr 06.10.06 15:03

Hallo,

wie sieht es es denn disassembliert aus.
Wenn man Delphi 7 und 2005 bei Funktionen wie round vergleicht sind dort schon grosse Unterschiede bei mir gewesen. Insbesonders war 2005 eheblich langsamer, da bei jedem Aufruf erst die Steuerregister der FPU speziell gesetzt wurden.Dies liegt wahrscheinlich an der Rundungskompilatibiltaet zur Sprache C mit ihrer Rundungsvorschrift, die nicht Standart bei der FPU ist (wann kam der 8087 heraus, vor 25 Jahren? ).
Zudem soll der FPC Compiler auch statt ausschliesslich ST(0) auch ST(1) benutzen koennen , was natuerlch schneller sein kann. Falls nun auch noch immer mit extended gerechnet wird, ist die Leistung eh im Keller.
Ach da war mal was: http://www.bernd-leitenberger.de/benchmark.shtml

Gruss Horst

Quake User - Fr 06.10.06 18:12
Titel: Re: Optimiert FreePascal deutlich besser als Delphi?

Aristoteles hat folgendes geschrieben:

Hallo Leute!
...
Ich habe ein Projekt, an dem ich arbeite, von Delphi auf Lazarus portiert. Es handelt sich dabei um einen Funktionen-Plotter mit eingebauter numerischer Integration. Standardmäßig ist in dem Projekt eine Laufzeitmessung integriert. D.h., wenn er eine Funktion zeichnet, spuckt er in einem Feld aus, wie lange er dafür gebraucht hat. Genauso bei der numerischen Integration.
...
Viele Grüße, Aristoteles

Diese Fragen sollte Borland beantworten. Hast Du es mal bei Borland versucht?
Wenn mein Auto zu langsam fährt, frage ich beim Hersteller nach.

Horst_H - Di 10.10.06 12:39

Hallo,

ich habe mal Lazarus mit FPC 2.04 instaliert und bin sehr erstaunt.
Mein Beispiel http://www.delphi-forum.de/viewtopic.php?t=65290 ohne Rechnerei, sondern Stringkopiererei laeuft unter Lazarus bei n=26/k=25 (Es sind 67.108.837 Rekursionsaufrufe) ohne Ausgabe(auskommentiert) in 00:00:18.006 Sekunden unter Delphi 7.0 mit FastMM4 in 00:00:27.359 sekunden, ohne FastMM4 in 00:01:08.508 Sekunden also erheblich langsamer.

Nun gut Lazarus kompiliert langsam, aber auch nicht 9 Sekunden.
Man muesste mal andere Anwendungen testen, die nicht so einseitig sind.

Gruss Horst

Robert_G - Mo 16.10.06 00:50

Bernhard Geyer hat folgendes geschrieben:

Schon mal probiert das FastCode-Project (http://www.fastcodeproject.org/) in dein Programm zu integrieren?

Borland hat schon seit D5 in dem Bereich Compiler-Optimierung für neuere CPU's nicht mehr viel gemacht. Der Verlustausflug Linux/Kylix und die große Portierung Richtung .NET sowie die Planlosigkeit des Borland-Management haben dafür keine Zeit und Ressourcen übrig gelasen.

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. 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.
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.
Der Compiler selbst optimiert sicherlich besser als der von FPC (wild guess), aber FPC lässt dich neuere CPU instruction sets nutzen. Deshalb sollte es nicht weiter verwundern wenn Berechnungen plötzlich nur noch einen Bruchteil dauern. ;)

Aristoteles - Di 31.10.06 11:18

Robert_G hat folgendes geschrieben:

Der Compiler selbst optimiert sicherlich besser als der von FPC (wild guess), aber FPC lässt dich neuere CPU instruction sets nutzen. Deshalb sollte es nicht weiter verwundern wenn Berechnungen plötzlich nur noch einen Bruchteil dauern. ;)

Guten Morgen!

Nun: Meine CPU kommt aus einer Zeit, in der Delphi 7 aktuell war. Von daher liegen die Gründe wahrscheinlich nicht im Instructionset.

Es kamen nun hunderte Antworten auf meinen Beitrag. Und weitere Fragen. Ich werde versuchen, die Schritt für Schritt zu beantworten:

>>Diese Fragen sollte Borland beantworten. Hast Du es mal bei Borland versucht?

Nein, Borland habe ich nicht angeschrieben. Ich habe es auch nicht vor, da mir im Grund egal ist, wie schnell Delphi ist. Bin seit der Portierung dieses Programms auf Lazarus umgestiegen. Es lockte vor allem die Plattformunabhängigkeit.

>>Hasst du mit Delphi auch ein BUILD gemacht mit optimierung?

Ich kenne den Begriff Build mit der Bedeutung "Versionsstand".
Dazu: Sowohl das Lazarus-Programm, als auch das von Delphi kompilierte haben ein und den selben Quelltext. Wenn ich mich recht erinnere, habe ich beide Programme über Projekt->Erstellen kompiliert...
Wie gesagt, FPC war ohne Optimierung schneller als Delphi mit Optimierung.

@Horst_H:
Das klingt ja so, als hättest du ähnliche Erfahrungen gesammelt, wie ich?
Vielleicht können weitere Programmierer von Euch über Erfahrungen in Verbindung mit Laufzeiten unter Delphi und Lazarus berichten?

>> Schon mal probiert das FastCode-Project (http://www.fastcodeproject.org/) in dein Programm zu integrieren?

Kannte ich noch nicht.

>> mir ist aufgefallen, dass unter Delphi standardmäßig die I/O-Laufzeitprüfung aktiviert ist (bei Lazarus nicht). Vielleicht liegt es daran?

Das werde ich überprüfen, sobald ich Windows das nächste mal benutze. Bin zwischenzeitlich auf Linux umgestiegen...
Aber mal eine Frage: I/O-Laufzeitprüfung hört sich so nach Ein-/Ausgabe-Prüfung an? Dazu kann ich dann doch was sagen:
Während der numerischen Integration gibt es weder Ein- noch Ausgaben. Die CPU ist ausschließlich damit beschäftigt, Funktionswerte der Funktion zu berechnen und die Ergebnisse dafür zu verwenden, über das Verfahren der "Obersumme" das Integral der Funktion numerisch zu berechnen.

>>Man muesste mal andere Anwendungen testen, die nicht so einseitig sind.
Wie berechnet mein Programm die Funktionswerte? - Über eine für meine Verhältnisse rießige rekursive Funktion, die die Terme nach und nach aufspaltet und dabei algebraische Regeln anwendet. Die Routinen beinhalten bei mir also vor allem String-Operationen und allgemeine Rechen-Operationen. Allzu einseitig ist das ja nicht;

Allesquarks - Di 31.10.06 16:43

Falls Delphi so compiliert, wie es im CPU-Window angezeigt wird, dann optimiert es gar nicht.
Dass freepascal schneller ist hätte ich erwartet und ist nun offenbar bestätigt. ich denke auch, dass das ein weitestgehend allgemeiner Effekt ist, der sich auf fast jeden Code ausdehnt.

"developers can freely use eax,ecx,edx but must preserve the other registers." So ungefähr stand es in der Delphi Hilfe. Das wahre Ausmaß dieser Katastrophe wurde mir aber erst später klar. Funktionen geben resultate normalerweise in eax zurück. Delphi speichert die dann gerne in ebx oder esi oder sonstwas, damit in der nächsten Codezeile, nur für den Fall, der recht selten ist, dass ich assembler verwende, eax,ecx, edx frei sind. Wenn ich nun Hochsprache schreibe wird das meistens dann wieder nach eax zurückkopiert, da die meisten Operationen damit ausgeführt werden.

Delphi <> Optimierung; nur logisches Variablen wegdenken.

harald mittermeier - Di 31.10.06 18:12

moin zusammen!

ich habe auch ein Programm für die Darstellung von Funktionen geschrieben
("Extended Math") und eine ähnliche Erfahrung gemacht.

Zuerst unter Delphi 2005 PE kompiliert, dann hab ich denselben Quelltext
(bis auf die Unit-Anpassungen) unter Lazarus 0.9.18 (läuft
bei mir unter Kubuntu 5.10 im Moment) geladen und kompiliert.

Und siehe da:
Während man die Win-Version bei einer relativ einfachen Sinus-Funktion (sin(x)*x)
den Graphen zeichnen sieht, ist der Graph der Linux-Version sofort da.

Ich vermute irgendwie, dass Linux ein anderes Handling von mathematischen
Funktionen hat oder dass Lazarus diese eben einfach effizienter in nativen
Linux-Code umsetzt; bei Borland's Delphi wird wohl einfach zuviel drin sein...

Außerdem ist meine Linux-Ver etwa 8 MB groß, während die Win-Ver 1 MB
ausmacht. Also liegt es nicht an der Größe der ausführbaren Datei.

Aristoteles - Di 31.10.06 18:38

harald mittermeier hat folgendes geschrieben:

Außerdem ist meine Linux-Ver etwa 8 MB groß, während die Win-Ver 1 MB
ausmacht. Also liegt es nicht an der Größe der ausführbaren Datei.

Da kann ich weiterhelfen:
In der aktuellen Version werden die Debug-Informationen nicht aus den Binärdateien gelöscht. Deshalb muss man das manuell nachträglich machen. Dazu gehst du einfach in die Konsole und gibst:

Quelltext

1:	strip --strip-all pfad/zur/datei/dateiname

ein. Dadurch werden die Debuginformationen entfernt, und das Programm schrumpft um ein Vielfaches.

tommie-lie - Mi 01.11.06 00:22

christian_u hat folgendes geschrieben:

harald mittermeier hat folgendes geschrieben:

Graphen zeichnen

Der Vergleich Linux/Windows hinkt ein bissle, der LInux kernel ist in allem ein stück schneller.

Der Vergleich hinkt prinzipbedingt, weil Grafik unter windows grundverschieden von Grafik unter Linux ist.

christian_u hat folgendes geschrieben:

Vergleich doch mal Lazarus mit Delphi unter Windows und Lazarus mit Lazarus unter Linux/Windows.

Auch damit wird man alles mögliche vergleichen, aber nicht die Geschwindigkeit der Berechnung "sin(x)*x" oder irgendeine spezielle Arithmetikgeschwindigkeit, die man in seinem Code zu messen versucht.
Wenn man unter Windows dem Zeichnen eines Graphen zuschauen kann, hat man irgendwas falsch gemacht oder die Formel ist weitaus komplexer als eine popelige Sinusberechnung.

Martok - Mi 01.11.06 00:40

tommie-lie hat folgendes geschrieben:

Ganz genau. Deshalb macht man Testprogramme für sowas auch als Konsolen-Apps: Damit die Grafik keine Rolle spielt. StdIn/StdOut ist eigentlich immer ähnlich schnell.
Außerdem sollte man mal versuchen, die Priorität auf Realtime zu setzen (kA, geht das bei Linux? Ich hab noch nicht unter Linux programmiert). Nur so kann man wirklich den Code vergleichen. Sonst sind immer Messfehler drin.

tommie-lie - Mi 01.11.06 13:49

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.

Aristoteles - Mi 01.11.06 16:54

tommie-lie hat folgendes geschrieben:

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.

Allesquarks - Mi 01.11.06 17:04

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.

Aristoteles - Mi 01.11.06 17:32

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.

tommie-lie - Mi 01.11.06 20:10

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.

Aristoteles - Mi 01.11.06 21:08

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.

tommie-lie - Mi 01.11.06 21:32

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".

Bernhard Geyer - Mi 01.11.06 22:12

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.

Aristoteles - Do 02.11.06 09:34

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.

Heiko - Do 02.11.06 21:17

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.

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2024 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!