Forum-Projekt: Quelltext-Optimierung ALIOTH

Für Dinge zum Forum, Kritik, Verbesserungsvorschläge, Umfragen und ähnliches.
Euklid
Lazarusforum e. V.
Beiträge: 2808
Registriert: Fr 22. Sep 2006, 10:38
OS, Lazarus, FPC: Lazarus v2.0.10, FPC 3.2.0
Wohnort: Hessen
Kontaktdaten:

Forum-Projekt: Quelltext-Optimierung ALIOTH

Beitrag von Euklid »

Hallo Leute,

wir haben in den vergangenen Tagen die schlechten Benchmarkergebnisse von FreePascal auf 64bit-Mehrkern-Systemen diskutiert, vgl.

http://shootout.alioth.debian.org/u64/b ... g2=fpascal" onclick="window.open(this.href);return false;

sogar gegen das langsame Java schneidet der FPC hier schlecht ab, was eine enorme negativ-Werbung für den FPC bedeutet. Dabei liegen die schlechten Resultate nicht am FPC selbst, sondern an dem im Vergleich schlecht optimierten Quelltext der Pascal-Benchmarks. Christian fasste dies so zusammen:
Christian hat geschrieben:ich hab mir eben mal 4 sourcen von den tests angesehn das ist absoulut nicht vergleichbar.
threading ist selbst in c in den meissten beispielen benutzt in pascal in keinem.
optimiert sind die auch kein stück.
Daher ist der Vergleich auf Alioth ein ungleicher Vergleich, der das Bild der Wirklichkeit zu ungunsten des FPC massiv verzerrt.

Die Gründe liegen darin, dass Java (und viele andere Sprachen) eine größere Community besitzt, welche an einem guten Abschneiden interessiert ist und den Quelltext der Benchmarks umfangreich optimiert hat. Der FreePascal-Compiler schneides nur deshalb so schlecht ab, weil es die FreePascal-Community bisher nicht fertig gebracht hat, den Quelltext der Pascal-Benchmarks zu optimieren.

Das lässt sich ändern, wenn wir es nur wollen. Denn wir sind die FreePascal-Community und wenn wir die Optimierungen nicht vornehmen, wer soll es dann tun? Wir sind es also, die es in der Hand haben, welches Bild die Öffentlichkeit von der Leistungsfähigkeit des FPC im Vergleich mit anderen Compilern hat.


Wir haben sicherlich alle bereits unsere individuellen Projekte, welchen wir bereits große Teile unserer Freizeit opfern. Daher würde ich vorschlagen, dass wir die Optimierung des Alioth-Quelltextes Stück für Stück in gemeinsamer Arbeit angehen und so die Last auf mehrere Schultern verteilen. Wir haben bei der Umsetzung auch theoretisch beliebig viel Zeit - wir können den aktuellen Zustand nur verbessern, egal wie schnell oder langsam wir die Optimierungen umsetzen. Wichtig ist, dass sie umgesetzt werden.

Das kann natürlich nur funktionieren, wenn einige Leute dazu bereit sind, sich hier zu engagieren. Daher meine Frage an Euch: Was haltet Ihr von einem solchen Projekt und wer ist bereit, hierfür einen (wenn auch kleinen) Teil seiner Freizeit zu investieren?

Viele Grüße, Euklid

Benutzeravatar
theo
Beiträge: 10921
Registriert: Mo 11. Sep 2006, 19:01

Re: Forum-Projekt: Quelltext-Optimierung ALIOTH

Beitrag von theo »

Grundsätzlich interessieren mich solche Test nicht wirklich. Wie heisst doch die alte Weisheit: "Wer misst, misst Mist".

Wenn das aber wirklich so ist, wie ihr sagt, dann müsste man eigentlich den Thread-Code aus den anderen Sourcen (C, Java) rausnehmen und nicht welchen in die FPC-Sourcen einbauen. Oder was wollen die eigentlich messen?
Das Ganze ist doch offensichtlich ein Witz.
Zuletzt geändert von theo am Mo 3. Nov 2008, 12:17, insgesamt 1-mal geändert.

Hitman
Beiträge: 512
Registriert: Mo 25. Aug 2008, 18:17
OS, Lazarus, FPC: ArchLinux x86, WinVista x86-64, Lazarus 0.9.29, FPC 2.4.1
CPU-Target: x86
Wohnort: Chemnitz

Re: Forum-Projekt: Quelltext-Optimierung ALIOTH

Beitrag von Hitman »

Ich fürchte dann verschwendet ihr eure Zeit. Die Regeln des Shootouts sagen klar, dass die Quelltexte so einfach wie möglich sein sollen. Also eben keine super-optimierten Meisterwerke. Sonst könnte man ja schlecht die Sprachen und dahinterstehenden Compiler vergleichen.
Außerdem wird der selbe Source für x86 und x64 verwendet. Folglich kann man die Performance nicht wirklich verbessern, ohne den jeweils anderen Benchmark in den Abgrund zu reißen.
Eventuell würde es schon helfen, wenn FPC "Integer" immer platformspezifisch handhaben würde (32bit auf x86, 64bit auf x64, ...). Das wäre imho auch problemlos möglich gewesen, wurde aber nun mal nicht gemacht. Also ist FPC da nunmal im Nachteil gegenüber Java/CIL und vlt. sogar GCC.

P.S.: Welcher der Benchmarks nutzen denn Threads? Konnte jetzt auf die Schnelle bei C nur drei finden ... eines davon logischer weise bei "Thread Ring". Also fernab von der "Mehrheit" ;)

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Forum-Projekt: Quelltext-Optimierung ALIOTH

Beitrag von mschnell »

Bevor da jemand loslegt muss erstmal geklärt werden ob und wie wir ALOITH dazu bekommen, den Code auch in ihre Umgebung einzubauen. Das ist für die ja schließlich auch eine Menge Arbeit.

Die von Christian gefundene Problematik mit den Threads ist nur ein Teil-Problem. Auch der single-Prozessor 64 Bit Test fällt für FPC ungünstig aus. Keine Ahnung, warum.

Wie Christian sagt ist der entsprechende GNU-C-Code mit Threads programmiert ("threading ist selbst in c in den meissten beispielen benutzt") - und das geht in C nur explizit, ein "parallel" Sprach-Konstrukt, das das automatisiert, gibt es in GNU C nicht. Dann sollte es das für FPC natürlich auch zulässig sein.

...Hatte ich bis eben gedacht. Nun lese ich aber gerade, dass der neue GNU C-Compiler ab Version 4.2 Unterstützung für OpenMP bietet (für C, C++ und Fortran). Ich weis nicht, wie das funktioniert, ist aber wohl zum Zweck der komfortablen Parallelisierung eingebaut worden.
Using one aspect of OpenMP, code is annotated with areas in which parallelism should occur using preprocessor directives. The code is converted into a multi-threaded program for the duration of block, then joined back together as each thread within the block finishes.
Christian: ist das im ALIOTH code tatsächlich so gemacht ? Das wäre dann eine im Rahmen der Statuen sichjerlich zulässige "Optimierung". Daß FPC keine OpenMP-Unterstützung hat, ist tatsächlich ein massiver Nachteil gegenüber GNU C, den wir nicht durch eine begrenzte Optimierung ausbügeln können. . :(

(In C# und Oxygen gibt es "parallel Loops" als Sprachelement, es wäre schön, wenn man FPC modernisieren würde indem man das auch einbaut. Ich habe das in der "Developers" Mailing List vorgeschlagen, die haben aber anscheinend nicht verstehen wollen, das das auch ohne .NET Framework in der RTL (z.B. mit OpenMP) implementierbar ist ) . Es gibt im FPC Wiki auch einen Artikel darüber. (M.E. wäre eine sehr sinnvolle Implementierung sich an die von Oxygen vorgeschlagene Syntax für "parallel Loops" zu halten.

Zu klärende Frage: Wie stellt man mit FPC die Anzahl der verwendbaren Kerne fest (um die Anzahl der zu kreierenden Threads festzulegen).

-Michael
Zuletzt geändert von mschnell am Mo 3. Nov 2008, 13:25, insgesamt 6-mal geändert.

Targion
Beiträge: 688
Registriert: Mi 3. Okt 2007, 21:00
OS, Lazarus, FPC: Linux (L 0.9.29 FPC 2.4.2)
CPU-Target: x86_64

Re: Forum-Projekt: Quelltext-Optimierung ALIOTH

Beitrag von Targion »

Ist ALIOTH nicht ein Teil der Debian-Serverfarm, auf der GForge läuft? Wenn ja, dann müsste man den Code problemlos kriegen.

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: Forum-Projekt: Quelltext-Optimierung ALIOTH

Beitrag von mse »

mschnell hat geschrieben: Auch der single-Prozessor 64 Bit Test fällt für FPC ungünstig aus. Keine Ahnung, warum.
Wie in einem anderen thread geschrieben, nutzt FPC die zusätzlichen x64 Register nicht optimal (habe ich gelesen) und kann dadurch die Nachteile von 64Bit Code (grössere Cache- und Datenbus-Belastung) nicht wettmachen.

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Forum-Projekt: Quelltext-Optimierung ALIOTH

Beitrag von mschnell »

Der "Mandelbrot" Test eignet sich hervorragend für parallele Prozesse, ist in C aber nicht mit OpenMP Pragma versehen, sondern alles ganz standardmäßig programmiert. Trotzdem ist C dreimal schneller als FPC :(.

-Michael

Euklid
Lazarusforum e. V.
Beiträge: 2808
Registriert: Fr 22. Sep 2006, 10:38
OS, Lazarus, FPC: Lazarus v2.0.10, FPC 3.2.0
Wohnort: Hessen
Kontaktdaten:

Re: Forum-Projekt: Quelltext-Optimierung ALIOTH

Beitrag von Euklid »

Ok, dann lassen wir das. Ich wollte mir generell mal tiefergehende Kenntnisse bezüglich Multi-Threading aneignen, ev. werde ich das in Verbindung mit einer Optimierung des Mandelbrot-Tests machen.
mschnell hat geschrieben:Der "Mandelbrot" Test eignet sich hervorragend für parallele Prozesse, ist in C aber nicht mit OpenMP Pragma versehen, sondern alles ganz standardmäßig programmiert. Trotzdem ist C dreimal schneller als FPC :(.
Ja, C verwendet hier keine Threads. Dafür werden hier durch die Verwendung der Datentypen

Code: Alles auswählen

typedef double v2df __attribute__ ((vector_size(16))); // vector of two doubles
typedef int v4si __attribute__ ((vector_size(16))); // vector of four ints
die Register in ihrer vollen Breite (64bit) ausgenutzt, wenn ich mich nicht irre....
Hitman hat geschrieben:Außerdem wird der selbe Source für x86 und x64 verwendet. Folglich kann man die Performance nicht wirklich verbessern, ohne den jeweils anderen Benchmark in den Abgrund zu reißen.
Bei Java haben die das schlau gemacht: Die starten genau so viele Threads, wie Kerne vorhanden sind. So wird jeder Prozessor ideal ausgelastet.

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Re: Forum-Projekt: Quelltext-Optimierung ALIOTH

Beitrag von Christian »

Außerdem wird der selbe Source für x86 und x64 verwendet. Folglich kann man die Performance nicht wirklich verbessern, ohne den jeweils anderen Benchmark in den Abgrund zu reißen.
Defines sind erfunden, wenn der jewails andere compiler die variablenbreiten von der architektur abhängig hat können wir dort auch mit defines arbeiten oder ?
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Forum-Projekt: Quelltext-Optimierung ALIOTH

Beitrag von mschnell »

Ich habe gerade mich noch ein bisschen über die neuen Versionen des GCC Compilers informiert und dabei gelesen, dass er auch Java compilieren kann. Ich vermute also die Java Benchmarks sind in direkten native-Code kompiliert und deshalb viel schneller als ich von Java Bytecode vermutet habe.

-Michael
Zuletzt geändert von mschnell am Mo 3. Nov 2008, 20:47, insgesamt 1-mal geändert.

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Forum-Projekt: Quelltext-Optimierung ALIOTH

Beitrag von mschnell »

Euklid hat geschrieben:Bei Java haben die das schlau gemacht: Die starten genau so viele Threads, wie Kerne vorhanden sind. So wird jeder Prozessor ideal ausgelastet.
Ja wenn die Sprache das unterstützt ist das eine feine Sache :) .

GCC v4.2 und später kann das durch OpenMP einfach mit mit
#pragma opc_parallel for
for (i=0; i<100000; i++);

Oxygen (ein Objekt-Pascal-Dialekt) kann das noch einfacher mit
parallel for i:= 0 to 100000 do

leider kann FPC das momentan nur indem man explizit im user-code Threads programmiert :( . Das wird ALIOTH nicht akzeptieren.
-Michael
Zuletzt geändert von mschnell am Mo 3. Nov 2008, 20:56, insgesamt 1-mal geändert.

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Forum-Projekt: Quelltext-Optimierung ALIOTH

Beitrag von mschnell »

Euklid hat geschrieben:

Code: Alles auswählen

typedef double v2df __attribute__ ((vector_size(16))); // vector of two doubles
typedef int v4si __attribute__ ((vector_size(16))); // vector of four ints
die Register in ihrer vollen Breite (64bit) ausgenutzt, wenn ich mich nicht irre....
Es wird SIMD (Single instruction multiple data) mit 16*8=128 Bit des Multi-Media- Befehlssatzes verwendet, also in einem Assembler-Befehl gleichzeitig zwei Float-Operationen (je 64 Bit) bzw vier Integer-Operationen (je 32 Bit)ausgeführt. Also mehr als 64 Bit :).

Das sollte bei 32-Bit code aber auch gehen, weil die 64 Bit-Register hier garnicht verwendet werden.

Aber FPC kann das jedenfalls nicht :( .

-Michael

Euklid
Lazarusforum e. V.
Beiträge: 2808
Registriert: Fr 22. Sep 2006, 10:38
OS, Lazarus, FPC: Lazarus v2.0.10, FPC 3.2.0
Wohnort: Hessen
Kontaktdaten:

Re: Forum-Projekt: Quelltext-Optimierung ALIOTH

Beitrag von Euklid »

mschnell hat geschrieben: Es wird SIMD (Single instruction multiple data) mit 16*8=128 Bit des Multi-Media- Befehlssatzes verwendet, also in einem Assembler-Befehl gleichzeitig zwei Float-Operationen (je 64 Bit) bzw vier Integer-Operationen (je 32 Bit)ausgeführt. Also mehr als 64 Bit :).

Das sollte bei 32-Bit code aber auch gehen, weil die 64 Bit-Register hier garnicht verwendet werden.

Aber FPC kann das jedenfalls nicht :( .

-Michael
Doch, kann er. Schau mal in der Doku unter Verwendung von MMX und SSE. Auch hier liegt es am Quelltext, da die entsprechenden Fähigkeiten nicht genutzt werden.
leider kann FPC das momentan nur indem man explizit im user-code Threads programmiert :( . Das wird ALIOTH nicht akzeptieren.
Alioth hat dies 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.

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Re: Forum-Projekt: Quelltext-Optimierung ALIOTH

Beitrag von Christian »

Bei den beispielen wo auch in anderen Srachen threads geutzt wreden sollten sie Threads auch beim fpc akzeptieren.
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

Euklid
Lazarusforum e. V.
Beiträge: 2808
Registriert: Fr 22. Sep 2006, 10:38
OS, Lazarus, FPC: Lazarus v2.0.10, FPC 3.2.0
Wohnort: Hessen
Kontaktdaten:

Re: Forum-Projekt: Quelltext-Optimierung ALIOTH

Beitrag von Euklid »

mse hat geschrieben:Wie in einem anderen thread geschrieben, nutzt FPC die zusätzlichen x64 Register nicht optimal (habe ich gelesen) und kann dadurch die Nachteile von 64Bit Code (grössere Cache- und Datenbus-Belastung) nicht wettmachen.
Kannst du Quellen für deine Angaben angeben?
Ich nehme an, du sprichst hier über die Registererweiterung:
http://de.wikipedia.org/wiki/AMD64#Registererweiterung" onclick="window.open(this.href);return false;
Christian hat geschrieben:Bei den beispielen wo auch in anderen Srachen threads geutzt wreden sollten sie Threads auch beim fpc akzeptieren.
Die Regel, dass der Quelltext möglichst einfach gehalten werden soll

http://shootout.alioth.debian.org/u32q/ ... #implement" onclick="window.open(this.href);return false;

scheint in der Tat sehr aufgeweicht. Sie trifft für den FPC noch zu, aber nicht mehr für die anderen Programmiersprachen, die durch Nutzung von Extras Vorteile haben.

Antworten