Forum-Projekt: Quelltext-Optimierung ALIOTH

[mse]

Kannst du Quellen für deine Angaben angeben?

IRC #fpc

Ich nehme an, du sprichst hier über die Registererweiterung:
http://de.wikipedia.org/wiki/AMD64#Registererweiterung" onclick="window.open(this.href);return false;

Ja. Die Registeroptimierung ist scheinbar in FPC noch nicht ausgereizt. Da ich nichts vom Kompilerbau verstehe, kann ich nichts vernünftiges darüber schreiben.

[mschnell]

Doch, kann er.... Auch hier liegt es am Quelltext, da die entsprechenden Fähigkeiten nicht genutzt werden.

Alioth hat dies (explizite Threads) zumindest im Java-Quelltext der Mandelbrotmenge akzeptiert. Wiso nicht auch beim FPC?

Der FPC ist sehr performant, wenn man seine Fähigkeiten nur ausschöpft. Das wird bei den Alioth-Benchmarks mit nichten getan.

Wenn das so ist, dann 'mal los ! Wer fragt bei Alioth nach, ob wir besseren FPC-Code abliefern dürfen ?

-Michael

[theo]

Wenn ihr wirklich nichts besseres zu tun habt, als an diesem beknackten Test rumzuschrauben, lest wenigstens noch dies vorher:
http://wiki.freepascal.org/Improving_la ... ut_results" onclick="window.open(this.href);return false;

[mschnell]

Ich nehme an, du sprichst hier über die Registererweiterung:
http://de.wikipedia.org/wiki/AMD64#Registererweiterung" onclick="window.open(this.href);return false;

Den Artikel kann ich überhaupt nicht verstehen.

"Die Verdoppelung der Registerzahl des allgemeinen Rechenwerks ist im Befehlssatz unabhängig vom 64-Bit-Transfer vorhanden. " Und wie benutzt der Compiler die verdoppelten Register, wenn der Befehlssatz doch nur einen Registersatz kennt ? Im Englischen Wikipedia-Text finde ich davon auch nichts.

Die ABI ist nicht vom Prozessor-Hersteller vorgegeben sondern ausschließlich ein Ding des Compiler-Herstellers. Borland-Compiler benutzen seit den Turbo-Pascal Tagen eine Register-ABI und keine Stack-ABI (außer bei zu vielen Procedure-Parametern).

-Michael

[_Bernd]

Borland-Compiler benutzen seit den Turbo-Pascal Tagen eine Register-ABI und keine Stack-ABI (außer bei zu vielen Procedure-Parametern).

nö, das ist nicht korrekt. Die Parameter wurde immer über den Stack übergeben. Lediglich einfache Funktionsergebnisse wurden im ax-Register zurückgegeben. Hab' extra nochmal kurz den Debugger angeworfen

Gruß, Bernd.

[mschnell]

Danke für die Korrektur, dann ist das vielleicht doch erst seit Delphi (ich weiß aber nicht welche Version, ich habe nicht mit 1.0 angefangen).

In Delphi werden aber seit langem bei der Default-Definition für Prozeduren Parameter in Registern übergeben.

-Michael

[Euklid]

Wenn ihr wirklich nichts besseres zu tun habt, als an diesem beknackten Test rumzuschrauben, lest wenigstens noch dies vorher:
http://wiki.freepascal.org/Improving_la ... ut_results" onclick="window.open(this.href);return false;

Danke für den Link, der ist in jedem Fall hilfreich.
Ich verknüpfe das Rumschrauben mit Erkenntniserweiterungen bezüglich Threadprogrammierung, Nutzung von MMX und SSE, Ausnutzung der vollen 64bit-Bandbreite. Die Kenntnisse kann ich für Promathika gut gebrauchen - wir wollen hier entsprechende Techniken zur Geschwindigkeitsoptimierung einsetzen. Bin aber in meine Projekte voll eingespannt, werde daher häppchenweise optimieren.

Das erste, was ich umzusetzen versuche ist die Optimierung hinsichtlich Threads des Mandelbrot-Tests. Damit werde ich kommende Woche beginnen. Laut Deinem Link kann man den Test auch durch Nutzung von SSE2 optimieren, das wird der nächste Schritt sein. Realistisch geschätzt könnte somit der Mandelbrot-Test bis Januar im Rahmen meiner Möglichkeiten optimiert sein. Der fertig optimierte Code lässt sich mit dem nicht optimierten Code von Alioth vergleichen und so abschätzen, was bei den anderen Tests rausgeholt werden kann.

Sollte noch jemand Interesse haben, mitzuarbeiten (mschnell?), können wir uns ja genauer absprechen.

Viele Grüße, Euklid

[mschnell]

Das erste, was ich umzusetzen versuche ist die Optimierung hinsichtlich Threads des Mandelbrot-Tests.

Wir haben da gerade im FP-developers Forum d'rüber diskutiert, nachdem ich das Thema aufgebracht habe.

Ein Ergebnis: je nach der verwendeten Hardware bringt das möglicherweise wenig bis nichts, da das Memory-Interface der (vor allem Intel-) Dual-Core-CPU Chips die Geschwindigkeit limitiert. Motherboadrs mit zwei einzelne CPU-Chips könnten besser sein. Möglicherweise sind AMD-Chips mit Hyper-Transport noch besser. Ideal wäre ein "Core". Also kaufen wir eine PS3 .

Sollte noch jemand Interesse haben, mitzuarbeiten (mschnell?), können wir uns ja genauer absprechen.

Melde Dich, wenn Du Zeit hast.

-Michael

[Euklid]

Ein Ergebnis: je nach der verwendeten Hardware bringt das möglicherweise wenig bis nichts, da das Memory-Interface der (vor allem Intel-) Dual-Core-CPU Chips die Geschwindigkeit limitiert. Motherboadrs mit zwei einzelne CPU-Chips könnten besser sein. Möglicherweise sind AMD-Chips mit Hyper-Transport noch besser. Ideal wäre ein "Core". Also kaufen wir eine PS3 .

Wenn ich richtig informiert bin, sitzt bei Intel der Memory-Controller auf dem Mainboard, bei AMD direkt auf der CPU. Sollten beide Kerne auf den Arbeitsspeicher zugreifen müssen, können sie sich tatsächlich ausbremsen und ich nehme an, dass das das ist, was Ihr meint?

Nun, der Mandelbrot-Algorithmus verwendet nicht viel mehr als etwa 12 Variablen, die schlimmstenfalls alle 64bit lang werden, also 12*8=96 Bytes. Es sollten also recht problemlos alle Variablen in den L1-Cache der CPU passen, wodurch die Arbeitsweise des Controllers irrelevant wird. Dadurch sollten AMD- und Intel-CPUs im gleichen Maße von der Thread-Programmierung profitieren können, wenn ich nicht irre.

[theo]

Ich verknüpfe das Rumschrauben mit Erkenntniserweiterungen bezüglich Threadprogrammierung, Nutzung von MMX und SSE, Ausnutzung der vollen 64bit-Bandbreite. Die Kenntnisse kann ich für Promathika gut gebrauchen

Das ist schon interessant. Nur glaube ich, dass man sich dazu ein tiefes Verständnis aller relevanten Faktoren aneignen muss.
Mit geduldigem "rumprobieren" wird man vielleicht einen solchen Alioth Test oder deine Math Routinen verbessern können.
Aber man muss aufpassen, dass die daraus gezogenen Schlüsse nicht "zu kurz greifen" und dass man sich nicht in eine weitere Schlacht mit nicht-verstandenen Schlagworten begibt.

Wenn es dir gelingt, diese Sachverhalte übersichtlich zusammenzufassen, würde mich das natürlich auch interessieren.

Btw. hier noch der Link zu dem von Michael angesprochenen Thread (siehe "parallel Computing")

http://www.mail-archive.com/fpc-devel%4 ... ascal.org/" onclick="window.open(this.href);return false;

[Euklid]

Ich verknüpfe das Rumschrauben mit Erkenntniserweiterungen bezüglich Threadprogrammierung, Nutzung von MMX und SSE, Ausnutzung der vollen 64bit-Bandbreite. Die Kenntnisse kann ich für Promathika gut gebrauchen

Das ist schon interessant. Nur glaube ich, dass man sich dazu ein tiefes Verständnis aller relevanten Faktoren aneignen muss.
Mit geduldigem "rumprobieren" wird man vielleicht einen solchen Alioth Test oder deine Math Routinen verbessern können.
Aber man muss aufpassen, dass die daraus gezogenen Schlüsse nicht "zu kurz greifen" und dass man sich nicht in eine weitere Schlacht mit nicht-verstandenen Schlagworten begibt.

Normalerweise gehöre ich zu der Sorte Menschen, die die Dinge entweder richtig oder garnicht anpacken. In der Vergangenheit wurde ich jedoch häufiger aufgrund größer werdender Zeitnot zur Oberflächlichkeit in bestimmten Bereichen gezwungen. So arbeite ich mich in vielen Bereichen nur so tief ein, wie es für das Erreichen meiner Ziele ausreichend ist. Das gilt auch für die MultiThread-Programmierung - hier reicht es mir, wenn ich die grundlegenden Prinzipien verstehe.

http://www.mail-archive.com/fpc-devel%4 ... ascal.org/" onclick="window.open(this.href);return false;

Danke! Ich hatte schon im Forum danach gesucht...

[theo]

Normalerweise gehöre ich zu der Sorte Menschen, die die Dinge entweder richtig oder garnicht anpacken.

Meine Bemerkung war nicht auf dich persönlich gemünzt, falls das so angekommen sein sollte.

MultiThread-Programmierung - hier reicht es mir, wenn ich die grundlegenden Prinzipien verstehe.

Hoffentlich reicht das, um tatsächlich einen Performance Gewinn zu erreichen.
Multithreading ist auch nicht "gratis" sondern hat einigen "overhead".
Bei Single-Core Systemen bringt's sicher nichts. Bei Multi-Core bleibt zu prüfen, ob unter dem Strich ein Gewinn rauskommt.

[Euklid]

So ist es.