Zitat:
Ich spiele mit dem Gedanken, eine
Unit für komplexe Zahlen zu schreiben und dafür ebenfalls Interfaces zu verwenden...
Wie siehts aus bezüglich Overhead? Also wenn man ganze Matrizen voll mit solchen Interfaced Numbers verwendet...
Gute Frage, die ich mir damals auch gestellt habe
Und jetzt weis ich die Antwort ganz genau.
Also im normalen Tagesgeschäft, rechnen mit sehr großen Zahlen, ist der Overhead minimal. Es ist sogar so, das ich NUR über die Interfaces auf einfachste Weise einen Speichermanager reinbauen konnte. Dieser ist optimiert auf die Bibliothek und bingt nun ca. 10% größerer Performance. Das heist die Interfaces beschleunigen sogar, weil mit ihnen mehr Features möglich sind
Wenn man aber 32-64Bit Rechnungen durchführt so wird dies meist langsammer sein als mit Int64 oder so. Das muß aber nicht immer so sein, zb. bestimmte Spezial-Algorithmen die in den IInteger enthalten sind wurden in mehere Implementierungen aufgeteilt. Dabei wird je nach Zahlengröße ein andere Algo. benutzt. Dieser Algo. ist dann spezialisiert auf Zahlen odedr Berechnungen m,it bestimmten Schranken. Das ist sehr oft der Fall. Nun, im DECMath sind einige 32-64 Bit Algortihmen drinnen die schneller sind als die
RTL.
Bei den Interfaces gibts noch eines anzumerken. Ich bezeichne meine IInteger als "forged Interfaces", weil sie in ihrer Implementierung nicht auf TObject/TINterfacedObject basieren. Meine Interfaces sind stinknormal Records und die wichtigsten Interface Funktionen sind in
ASM optimiert (Allozierung, FIFO Stack, Calculation Management).
Interfaces mit TInterfacedObject Implementierungen sind in ihren Aufrufkonventionen von Methoden ziemlich ineffizient.
In kurz: der Impakt der Interfaces ist sehr gering auf die Performance aber je nach Sprache und Funktionalität des Compilers eine weitreichende Entscheidung -> im DECMath eben Prozedurales Konzept mit überladenen Funktionen, sehr kurzen Funktionsnamen und sehr strikter Parametersignatur der Funktionen.
Gruß Hagen