Delphi zum Numbercrunching geeignet?

[Hagen Reddmann]

Hm, soviel ich aber weiß nutzt der JIT Compiler für mathematische Berechnungen aber einen spezielen Expressionparser und dieser arbeitet dynamisch. Zudem, die function Power() ist in Delphi nicht optimal programmiert, irgendwo (ESB Consulting o.ä.) habe ich einen Ersatz für Power gesehen, der ca. 200 mal schneller sein soll.

Gruß Hagen

PS: sollte übrigens keine Kritik an Dir sein
Alleine schon das Sqrt(1 - Sqr(Sin)) schneller ist als Cos(X) ist schon Grund genug zu zweifeln, da das Wurzelziehen eigentlich langsammer sein sollte

[Jürgen Hofmann]

Delphi zum Numbercrunching geeignet?

Da verstehe einer noch die Welt!!!???? Folgendes kleines Testprogramm habe ich in Delphi5, C++Builder5 und in JBuilder3.5 umgesetzt:

procedure TForm1.Button1Click(Sender: TObject); var i, j: longint; z, z2, z3, summe: extended; begin summe := 0.0; for j:=1 to 400 do begin for i:= 1 to 10000 do begin z := 0.0001*i; z2 := sin(z)*power(1.0001,z); z3 := cos(z)*power(z,z2); z := sin(z)*sin(z) + cos(z2)*cos(z2) + z3*z3; summe := summe +z; end; end; Summe := Summe/i; StaticText2.Caption := IntToStr(i); StaticText1.Caption := IntToStr(j); StaticText3.Caption := FloatToStr(Summe); end;

Auf einem 233MHz Pentium 3 mit 128 MB brauchte das Programm unter Delphi 27.2 Sekunden, mit dem C++-Builder 26.2 Sekunden und dem JBuilder sage und schreibe 16 Sekunden!!!! Das verstehe wer will: wird doch allgemein behauptet C++ sei für Rechnereien das Größte, dann Delphi (muss ja wohl ungefähr das Gleiche rauskommen, da die gleiche Bibliothek verwendet wird) und JAVA sei lahmer als lahm, weil Pseudocode und VM usw. Trotz JIT-Compiler sollte es immer noch wesentlich langsamer sein! Das Gegenteil scheint der Fall zu sein. Hat Borland bei Delphi und C++ geschludert oder wie ist das Ergebnis zu verstehen?

[Hagen Reddmann]

Hi

Ich weiß nicht wast Du hast ?

<pre>
var
Z, Z2, S, ZS, ZQ, ZP: Extended;
begin
S := 0.0;
Z := 0.0;
for i := 1 to 10000 do
begin
Z := Z + 0.0001;
ZS := Sin(Z);
Z2 := ZS * Power(1.0001, Z);
S := S + Sqr(ZS) + Sqr(Cos(Z2)) + Sqr(Cos(Z) * Power(Z, Z2));
end;
S := S * 400 / I;
end;

</pre>

Der JIT "Compiler" arbeitet wie ein Interpreter. Da Interpreter sehr langsam sind optimieren diese im bersonderen Berechnungsschleifen und speichern viele Resultate zwischen. In Deinem Fall hat der JIT-Compiler mehr Intelligenz bewiesen die äußere Schleife zu entfernen und die einmal gebildete Summe der inneren Schleife einfach mit 400 zu multiplizieren. Ein echter Compiler optimiert aber NICHT den eigentlichen Algorithmus (zeigt ja das C und PASCAL identisch schnell waren). Das ist schon DEINE Aufgabe.

Nun, test it and see what happend. Nach dieser "kleinen" Änderung sollte sich einiges tun

Gruß Hage

[Hagen Reddmann]

Un noch mehr..

<pre>
Z, Z2, S, ZS, ZQ, ZP: Extended;
begin
T := PerfCounter;
S := 0.0;
Z := 0.0;
for i := 1 to 10000 do
begin
Z := Z + 0.0001;
ZS := Sin(Z);
ZQ := Sqrt(1 - Sqr(ZS)); // Cos(Z) aus Sin(Z)
Z2 := ZS * Power(1.0001, Z);
S := S + Sqr(ZS) + Sqr(Cos(Z2)) + Sqr(ZQ * Power(Z, Z2));
end;
S := S * 400 / I;
end;
</pre>

Gruß Hagen

PS: Willst'e Deinen Test trotzdem mit äußerer Schleife durchführen solltest Du

<pre>
Summe := 0.0
for J := 1 to 400 do
begin
Summe := Summe * J
for I := 1 to 1000 do....
end;

</pre>

schreiben

[Jürgen Hofmann]

Hallo, Hagen,
Du weißt in der Tat nicht, was ich habe: so einfach ist die Sache leider nicht. Ich bin lange genug im Geschäft, um den Unterschied zwischen einem Interpreter und einem Compiler zu kennen. Nimm z.B. das folgende Codefragment:

var
i, iloop: longint;
z, z1, z2, z3, summe: double;
begin
summe := 0.0;
iloop := 2000000;
begin
for i:= 1 to iloop do
begin
z1 := 0.0001*i*cos(0.00001*i)*exp(i/iloop);
z2 := sin(z1)* cos(z1)*power(1.0001,z1)*z1;
z3 := sin(z2)* cos(z2)*power(1.0001,z2)*z2;
z := (sin(z3)* cos(z3)*power(1.0001,z3)/z1/z2/z3)*tan(z1*z2*z3);
summe := summe +z;
end;
end;

Hier hat kein Interpreter der Welt die Möglichkeit der Elimination von sog. Common Expressions (hier muss ich Dir übrigens nochmal widersprechen: ein guter Compiler sollte dazu auch in der Lage sein!).
Mit Delphi5 und C++Builder5 braucht das Ganze ca. 22 Sekunden mit dem JBuilder3.5 etwa genau so lang!
Übrigens, wenn ich bei meinem ursprübglichen Beispiel den j-Schleifenindex auf 200 setze, braucht das Programm nur halb so lang, d.h. Deine Behauptung, der JAVA-Interpreter würde das Resultat der inneren Schleife nur mit 400 multiplizieren, kann allein schon deswegen nicht stimmen (so clever ist er wohl nicht, dass er die Laufzeit noch anpasst, um mir eins vorzumachen!).

Also leider sehe ich nicht, was Deine Argumente an meinem Statement ändern. Ich bleibe dabei: Delphi und C++Builder sind keineswegs um einen Faktor 20 schneller als JAVA (was angeblich ja doch nur auf der VM läuft). Kurz: irgendwie passt das alles nicht! Übrigens nur am Rande: der Jbuilder ist eine unglaublicher Ressourcenfresser: selbst mit 128 MB RAM (allerdings nur mit 233 MHZ)kann man während der einzelnen Arbeitsschritte noch Kaffee trinken gehen

[Jürgen Hofmann]

Prima, Hagen, wir sind uns also einig, dass da was nicht ganz stimmt!
Vielleicht könnte man sich ja gemeinsam mal um die Performance unserer Werkzeuge kümmern (ich vermute, es gibt eine ganze Menge Leute, die Delphi und den C++Builder für Rechnereien einsetzen).
Übrigens: als Kritik habe ich Dein Statement nicht verstanden, wir ziehen als Entwickler doch wohl alle am gleichen Strang ;-)

[Robert Marquardt]

Zieht doch mal die Jedi Code Library in Betracht. JclMath enthaelt allerlei Mathematikfunktionen. Wenn ihr damit ein paar Tests macht, dann erhalten wir davon richtige Performancewerte. Bitte sendet eure Ergebnisse an [email protected].
Die JCL koennt ihr von www.delphi-jedi.org herunterladen

[Fred Ziebell]

Hallo.

Vielleicht liege ich ja falsch...aber...

ich erinnere mich dunkel, daß vor einigen Jahren, als JAVA ins Gespräch kam, zuerst eine ziemliche Ablehnung gegen eine neue interpretierende Sprache aufkam. Man verglich damals JAVA mit so einer Art GW-Basic-Zeileninterpreter(kennt wahrscheinlich keiner mehr) mit aufgesetzter OOP.

Irgendwann war dann mal zu lesen, daß JAVA´s Bytecode einem Pre-Run-Compiling unterzogen wird(oder werden kann!). Sobald der Bytecode geladen ist, sorgt die VM für eine Umsetzung auf die jeweilige Maschiene VOR! der Ausführung.

Ich habe das damals und im Ablauf der Zeit weder überprüft noch weiter verfolgt. Allerdings würde sich damit das hurtige benehmen(wahrscheinlich nur in Teilbereichen) von JAVA erklären.

Jetzt kenne ich natürlich weder die Objektcodes der Compiler noch wie sie selbigen erzeugen und ich werde mich beherrschen sie mittels Disassembler nackig zumachen, aber ich glaube, daß man JAVA und CBUILDER/DELPHI Objektcodeseitig nicht mittels einiger Berechnungen miteinander vergleichen kann.

Wenn schon, dann sollten komplette funktionsidentische Anwendungen miteinander verglichen werden. Was nützt es, wenn der eine Compiler superschnelle Float-Routinen zur Verfügung stellt und bei der Stringverarbeitung versagt. Es sind mittlerweile einfach zuviele Komponenten, die eine wesentliche Rolle bei der Definition von "Ablaufgeschwindigkeit einer Anwendung" eine Rolle spielen.

Vielleicht, sieht Jürgens Ergebnis auf einem AMD oder Cyrix Prozessor statt einem Intelprozessor ganz anders aus oder steht in einem anderem Verhältnis. Ich selber kann das jeden Tag an meinem Heim-Pc erleben. Nach dem Austausch des Prozessors von PI-233MMX nach AMD-K6-III/400 liefen viele Programme sichtbar schneller und einige merkbar langsamer(Warum ist mir durchaus klar).

Und die letzte Bermerkung: Wenn JAVA ein in einigen Bereichen sindaktisches und funktionell vereinfachtes C++ darstellt hat der Compiler/Interpreter möglicher Weise -Aufgrund geringerem geparstem Ballast- weniger Mühe in gewissen Teilbereichen schnelleren Code zu erzeugen/auszuführen(No Compiler is Perfect).

...by the way...das alte Powerbasic unter DOS!(Ihr könnt ruhig grinsen) läßt auch heute noch jedes Delphi, Cbuilder oder JAVA in puncto Codeerzeugung locker in der Ecke stehen. Ein effektiverer Code ist auch von Hand in Assembler kaum möglich. Wo Windowsprogramme in Millisekunden "denken", ist es bei Powerbasic Mikrosekunden. 2-3 Zehnerpotenzen Unterschied sagen wohl alles...aber wer will schon "back to the roots" :-))

Ach ja, der Watcom-C-Compiler soll unter Windows den schnellsten Code erzeugen!?(Habe es nie getestet).

UUUPPSS......das war jetzt zu lang....sorry!

Gruß Fred Ziebel

[Jürgen Hofmann]

Robert:
Also mit der JCL klappts leider auch nicht: sie ist bei den angesprochenen Routinen um ca. 20 % langsamer als das, was in Delphi eingebaut ist.

Fred:
ist alles schön und gut: ich will ja zunächst auch nur mal die paar Mathematikroutinen vergleichen (Strings interessieren mich im Moment nicht). Im übrigen habe ich die JAVA, C++Builder und Delphi-Programme auf dem gleichen 233 MHz Intel Pentium laufen lassen, also sind die Werte vergleichbar. Dass auf einem Athlon was anderes rauskommt, bestreitet sicher niemand. Dass DOS-Programme (und dann noch im Powerbasic) beim Numbercrunchen schneller sind, bestreite ich allerdings (denn bei dem oben beschriebenen Miniprogramm spielt das Windows-Overhead überhaupt keine Rolle)! Just for Fun: wenn man das Programm als DOS-Applikation in Visual C++ 6.0 umsetzt, braucht es deutlich länger als in Delphi, in Visual Basic 6.0 (kompiliert!) sogar doppelt so lang

[Hagen Reddmann]

Hi

PowerBasic kann in diesem Fall nicht schneller sein,das ist auch einleuchtend da ja hauptsächlich FPU Befehle ausgeführt werden. Aber genau in diesem Bereich der FPU Programmierung kann man einiges beschleunigen, z.B. NICHT nach jeden Befehl einen WAIT einzuprogrammieren. Allerdings betrifft das IMMER die Assemblerprogrammierung. Zudem lassen sich einige FPU Befehle durch schnellere MMX etc. Routinen austauschen. Ich vermute das der JIT Compiler/Interpreter den Source NICHT 1 zu 1 übersetzt, sondern verschiedene Optimierungen vornimmt. Z.b. Zusammenfassung eines FPU Rechenblockes und somit verzicht auf WAIT/FWAIT Mnemonics.
Genau da muss aber der Pascal/C Compiler versagen, da z.B. die Power function STATISCH als Laufzeitbibliothek vorliegt !
Die einzelnen math. Funktionen aufzulösen und in EINE einzigste Funktion zu programmieren dürfte eine erhebliche Leistungssteigerung bewirken. Allerdings hast'e dann eine hochspezialisierte Funktion und eben keine allg. Laufzeitbibliothek.
Als Beispiel: ALLE Parameter zu math. Functionen wie Sin(), Cos(), Power() müssen auf den Programstack gelegt werden. Die Parameter werden als Floats übergeben und in der entsprechenden Funktion wieder in den FPU-Stack geladen. Nach Beendigung der math. Funktion werden aus dem FPU-Stack die Resultate auf den Programstack verschoben. Beide Operationen sind langsam, da sie meistens auch noch eine Scalierung vornehmen. Wird nun eine einzigste Funktion programmiert, fallen wesentlich weniger Programstack->FPU-Stack->Programstack Verschiebungen an. Nun, wenn der JIT Compiler aus den einzelnen math. Anweisungen einen FPU-Codeblock erzeugt, dann MUSS er schnelleren Code erzeugen.

Gruß Hage

[Robert Marquardt]

Zu Hagens Ausfuehrungen: Unter anderem deshalb ist der Macintosh mit seiner PowerPC CPU so viel schneller. Das die FPU registerorientiert ist, kann der C Compiler Registervariablen in der FPU anlegen und das Laden und Entladen der Daten in die Variable entfaellt

[Fred Ziebell]

Hallo,

Jürgen: Du hast mich falsch verstanden. Ich meinte: Wenn du deine Testprogramme jeweils mit JAVA + DELPHI + CBUILDER auf einem INTEL-System und jeweils auf einem AMD-System laufen läßt, bekommt du unterschiedliche Verhältnisse in den Ergebnissen, da beide Prozessoren eine unterschiedliche Gewichtung in der Optimierung ihrer Befehlszyklen haben. Wo die eine CPU bspw. 3 Zyklen für ein 'ADD BX,3' benötigt, ist die andere mit 2 Zyklen dabei dafür benötigt erstere für ein MOV AX,2c0h vielleicht 2 Zyklen statt einem. In der Praxis bedeutet das, daß dein Testprogramm unter JAVA auf einem INTEL-PC vielleicht 30% schneller als unter dem CBUILDER läuft. Auf einem AMD-PC jedoch -möglicher Weise- nur 10% schneller oder sogar 20% langsamer. Deshalb sind sogar prof. Benchmarkprogramme nur ungefähr Aussagekräftig, weil jede neue Anwendung eine völlig neue Situation darstellt.

Nicht umsonst werden CPU´s, Mainboards, Compiler usw. in der CT´ mit unterschiedlichsten Programmen und Hardware getestet. Ein Test in der Größenordnung zB. die Compilierung des LINUX-Kernels ist mit Sicherheit sehr Aussagekräftig, weil so ziemlich alle Komponenten angesprochen werden. die math. Funktionen sind ja nur ein Bruchstück des Leistungsumfanges von JAVA. Ich wage zu bezweifeln, daß dein gemessener Geschwindigkeitsvorteil für JAVA über das gesamte Funktionsspektrum Bestand hätte.

Wozu ich ganz besonders Stellung nehmen muß, ist zu der Aussage, daß bei deinem Testprogramm das immerhin über 20 Sekunden läuft, die Windowsumgebung keine! Rolle spielt. Innerhalb von 20 Sekunden unterläuft deine Routine ca. 1000 Taskswitchs und Pseudo-parallel werden hunderte oder tausende von Routinen/Funktionen ausgeführt, die auch! ständig unterbrochen werden oder wer aktualisiert bei deinem Rechner pseudo-multitasking-mäßig die Mausposition, aktualisiert den Timer, checked den Medienchange, verwaltet den Smartdrv(Cache), kommuniziert mit 8048 in deinem Keyboard, läßt den Cursorblinken usw. usw. Ich schätze 99,9% aller User haben nur eine! CPU im System, die sich um alles kümmern muß. Das Ergebnis: Pseudo-Multitasking, Pseudo-Multithreading, Pseudo-Parallel. Hardware und Software NMI´s Soft-IRQ´s usw. sind in dieser Überlegung noch nicht mal enthalten.

Und jetzt erzählst du mir, die Windowsumgebung spielt keine Rolle ???? Sie spielt immer DIE! Rolle. Sogar wirkliche Multiprozessor-Systeme ala XEON oder PENTIUM PRO mit 2 oder mehr Prozessoren können diese Problematik auch bei entsprechend modifiziertem Code(Software-Piplines und dergleichen) kaum merkbar verbessern(2 x CPU sind nicht 200% Leistung sondern vielleicht 130% Leistung). Unter keinem! Betriebssystem, kann es frei laufende Software mit maximaler Performance geben -liegt in der Natur der Sache.

Zum Powerbasic: Ich will das Thema nicht mehr ausweiten. Es gehört nicht hierher und interessiert ohnehin niemanden mehr. Aber ein Schlußwort dazu sei mir erlaubt.

Ihr habt euch offensichtlich nie oder wenig damit beschäftigt. In Powerbasic sind zb. TSR Programme möglich die einen derart effizienten Code erzeugen, daß sie als Device-Treiber, Realtimescanner usw. eingesetzt werden können. Nur ein Beispiel: Eine 3D Fräse sollte um den Faktor 80% beschleunigt werden. 2 64bit-I/O-ISA-Karten dienten unter Windows 3.11/95 als Schnittstelle. Die Aufgabe: 5 Schrittmotoren ansteuern, HPGL emulieren bzw. umwandeln in entsprechende 32bit-Muster, ca. 20 Taster Schalter abfragen, Laufzeiten optimieren, über rs232 und rs485 kommunizieren und das alles mit möglichst wenig externer Hardware. Software(Prof. und extrem Teuer) unter Windows war damals völlig überfordert und versagte Steuerungsmäßig im unteren Mikrosekunden bzw. oberen Nanosekundenbereich(PC´s mit ca. 100-200Mhz).

Wir haben damals nicht alles aber den wichtigsten Teil in Powerbasic V3.2 erledigt. Das Verhältnis zwischen BASIC und eingebundenem Assembler-Code lag bei 90%:10%. Der Urquelltext wurde übrigens von Turbo-Pascal umgeschrieben.

Hagen: Der

[Fred Ziebell]

Ic wollte noch sagen:

Hagen: Der Powerbasiccompiler unterstützt eine FPU direkt! MMX bzw. 3d/Now kennt er allerdings nicht. So, uns jetzt Schluß mit BASIC-Thema !? :-)

Gruß Fred Ziebel

[Hagen Reddmann]

Hi Fred

Ja, sag ich doch, und genau deshalb KANN er ja nicht schneller sein, da die FPU Befehle egal ob Basic/Delphi/C immer gleich sind. NUR in der Anwendung dieser Befehle gibt es Unterschiede und die können ENTSCHEIDEND sein

Gruß Hage

[Fred Ziebell]

Hallo,

Hach....ich will nicht darauf rumreiten aber....wer an ultimativen Powercoding mit Maxspeed interessiert ist und keinen Bock auf Assemblerarien hat, der sollte sich mal den PowerBasic DLL/Compiler V6.0 ansehen. Die Dll´s laßen sich beliebig in VB, VC++, CBUILDER und ich denke auch Delphi einbinden. http://www.powerbasic.com

Gruß
Fred Ziebel