Benchmark

[Euler]

Moin,

Ich habe gerade das seltene "Glück", auf 4 Maschinen dasselbe Protein zu rechnen. Da bietet sich ein Benchmark Vergleich an, den ich euch mal posten wollte.

Code: Alles auswählen

Protein: "p604_bba5F8W_ext_278"

CPU			Clock	FrameTime	Core
			GHz		sec.
============================================
XP 1900+	1,6	  60			Windows 
XP 1600+	1,4	  80			Windows 
TB 1200 	1,2	 100			Windows


XP 1900+  	1,6	  90		Linux
K6-III 400	0,4	 885		Linux 

Hiermit wird recht eindrucksvoll dokumentiert, daß einem unter Linux/FreeBSD, ca 30% durch nicht optimale Compiler/Tools verloren gehen.

Damit ist auch zu erklären, daß meine Wochenproduktion von ca. 210 auf 160 gefallen ist, seit ich meinen Dual-Palomino auf FreeBSD umgestellt habe.

Man könnte nun, soweit man lediglich auf maximale Produktion aus ist, argumentieren, dass man seine Maschinen einfach unter Windoze rechnen lässt.

Das wäre sicher im Sinne von Gates, Ballmer & Co., sowie Intel, die
Stanford mit den optimalen Compilern für die P Serie versorgen.

Ich denke jedoch, es wäre PandeLab's Pflicht, die Linux/OpenSource Community, denen sie nahezu *alles* zu verdanken haben, hier mehr zu unterstützen, indem sie rechnerisch einen Ausgleich bei den Punkten schaffen.

Denkt mal darüber nach...

Niemand sollte sich den Intel/Microsoft Monopolisten unterwerfen.
Ich tu's jedenfall nicht, eher verliert Stanford meine Unterstützung.

Euler

[Michael H.W. Weber]

Ich denke jedoch, es wäre PandeLab's Pflicht, die Linux/OpenSource Community, denen sie nahezu *alles* zu verdanken haben, hier mehr zu unterstützen, indem sie rechnerisch einen Ausgleich bei den Punkten schaffen.

Das ist in der Tat eine interessante Idee. Du meinst, man sollte die ungenügenden Compilerqualitäten wenigstens beim "crediting" kompensieren. Also ich hätte nichts dagegen, sehe allerdings keinen Vorteil für das Projekt - abgesehen von Freuden für "stats-a-holics".

Mal 'ne Frage: Wieso gibt es dieses Compilerdefizit unter Linux überhaupt?

Michael.

[huraxprax]

Mal 'ne Frage: Wieso gibt es dieses Compilerdefizit unter Linux überhaupt?

Wahrscheinlich hat Intel erst den Windows Fortran-Compiler für x86 fertig gemacht, und seit drei Jahren sitzt die gesamte Compilerabteilung von Intel ununterbrochen am Itanium und versuchen aus dem wenigstens einen Teil seiner möglichen Performance rauszuholen

Aber um Pande zu verteidigen, sie würden das sicher gerne auch auf Linux optimieren, ihre Rechencluster und ein Teil derServer laufen selbst unter Linux, aber haben es einfach nicht geschafft.
Im Gegensatz zu anderen Projekten denen das absolut egal ist wie schnell der Client läuft.
Und wenn du Gromacs anschaust, da dürften sich dann wohl eher die Windowsuser beschweren. Auf ihren Benchmarks vergleichen sie aber nur Linux-PCs und Itanium mit Macs und Unixrechnern, Windows gibts nicht als Vergleich. http://www.gromacs.org/benchmarks/single.php[/quote]

[Euler]

Das ist in der Tat eine interessante Idee. Du meinst, man sollte die ungenügenden Compilerqualitäten wenigstens beim "crediting" kompensieren. Also ich hätte nichts dagegen, sehe allerdings keinen Vorteil für das Projekt - abgesehen von Freuden für "stats-a-holics".

Mal 'ne Frage: Wieso gibt es dieses Compilerdefizit unter Linux überhaupt?

Ad 1)

Ich hoffe, Du hälst mich nicht für einen "stats-a-holic"
Aber der "Vorteil" für's Projekt ist ganz einfach der, dass sich Linux/Unix
User nicht ungerecht behandelt fühlen, und deshalb bei der Stange bleiben.
Okay, die meisten werden's sowieso tun, da sie anständige Menschen sind.

Ad 2)

Short:
Weil es auf Linux keinen Compiler gibt, der die performance des Intel Fortran Compilers erreicht.

Long:
Ich hatte vor einigier Zeit schon mal auf die Compilerproblematik unter Linux hingewiesen und zwischenzeitlich auch noch mal nen Nachtrag geposted, bezüglich gcc Version >= 3.
Der GNU Compiler (gcc) ist von Haus aus eher ein Cross-Compiler, d.h. generiert code für möglichst viele CPU Typen.
Daher ist die 2nd stage Optimierung (die eigenliche Hardware Codeerzeugung) nicht so ausgefeilt wie bei reinrassigen x86 Compilern.

In der Version 3 nun versuchte man den gcc zu tunen, indem er u.A. "instruction prefetching" Strategien anwendet.
Unglücklicherweise sind diese Strategien aber inkompatibel zwischen Ps und Athlons, sodaß die ersten Versionen der Version 3 ca. 50% schlechtere performance auf Athlon CPUs ergaben.
Man versucht nun, das in der kommenden Version 3.2 auszubügeln.

Fakt ist: (Nahezu) Alles, was unter Linux/Unix läuft, ist mit gcc kompiliert, da er sozusagen das "backbone" des gesamten Systems darstellt. Auch GROMACS dürfte hier keine Ausnahme machen, da mir im Moment kein Compiler unter *X bekannt ist, der generell besseren Code als gcc erzeugt.

Interessant in diesem Zusammenhang ist, dass der GROMACS Core, so wie er von PandeLabs kommt, eine Mixtur aus gcc 2.95 und gcc 2.96 Fragmenten ist.
Der gcc 2.96 (eine frühe Vorstufe des 3.0) ist besonder "giftg" für Athlons.

Näheres kann man unter der URL nachlesen, die ich vor einigen Tagen mal unter dem Thema "gcc performance" geposted habe.


Euler

[Michael H.W. Weber]

Weil es auf Linux keinen Compiler gibt, der die performance des Intel Fortran Compilers erreicht.

Aha. Nun macht es sich die Linux-Fangemeinde allerdings immer gerne - auch öffentlich - zu eigen, u.a. aus einem Sammelsurium von Programmierprofis zu bestehen (was ich nicht mal bezweifle ). Warum kriegt von denen dann keiner einen gediegenen Compiler - von mir aus auch mehrere jeweils auf die benötigte CPU optimiert - hin? Das müßte doch mal ein Ansporn sein.

Michael.

[Gast]

Weil es auf Linux keinen Compiler gibt, der die performance des Intel Fortran Compilers erreicht.

Aha. Nun macht es sich die Linux-Fangemeinde allerdings immer gerne - auch öffentlich - zu eigen, u.a. aus einem Sammelsurium von Programmierprofis zu bestehen (was ich nicht mal bezweifle ). Warum kriegt von denen dann keiner einen gediegenen Compiler - von mir aus auch mehrere jeweils auf die benötigte CPU optimiert - hin? Das müßte doch mal ein Ansporn sein.

Michael.

Wie ich schon sagte, gcc 3.0 bzw. 3.1 sollte in dieser Hinsicht auf x86 getuned werden, was allerdings zu Lasten des Athlon schief ging.
Die performance für Ps ist recht gut mit 3.1.

Die Version 3.2 soll aber auch für Athlons wieder optimal werden.
Warten wir's ab.

Aber! Was ich immer gesagt habe: Kein C Compiler, auch nicht der Beste, kann mit FORTRAN in punkto number crunching mithalten.

(Nahezu) Alle wissenschaftlichen tasks, die brutale Rechenkraft<g> benötigen - auf Supercomputern wie der CRAY beispielsweise - sind in FORTRAN geschrieben. Es gibt nichts besseres (hierfür).

Der gcc hat ein FORTRAN front-end (g77), was aber gerade diese optimalen Eigenschaften nicht aufweist, da der gesamte gcc [g]ein und derselbe[/b] Compiler für verschiedene Sprachen ist.

Euler

[Wurmi]

Weil es auf Linux keinen Compiler gibt, der die performance des Intel Fortran Compilers erreicht.

Hi Euler,
für FreeBSD mag das ja gelten , für LINUX jedoch gibt es sehr wohl die Intel-Compiler (incl. VTune) . Kostet halt. Als "Frischling" habe ich mir gestern den DF client gezogen und der wurde in einer "GCC" und einer "Intel"-Version angeboten. Ich denke, das bezieht sich tatsächlich beides auf den Compiler.

Grüßle,
Wurmi :

[Euler]

Tja Wurmi, da hattu wohl recht.

Ich weiß, daß es den gibt, jedoch war der Vergleich auf Windoze Intel FORTRAN bezogen.
Mag sein, daß das nicht gut rüber kam.

Also noch mal möglichst korrekt:

Es gibt auf Linux/FreeBSD/... (einfach POSIX) keinen x86 Compiler (auch kein Intel FORTRAN), der die performance des Intel x86 FORTRAN Compilers unter Windows erreicht, für überwiegend numerische (floating point) Berechnungen [i.e. "brute force number crunching"].

Warum das so ist, liebe Kinder, das denkt euch mal schön selber ...
(Sonst erzählt's euch halt Tante Erika in der nächsten Bastelstunde)

Euler