SuperPi goes AVX -> y-cruncher

[Opteron]

Zitat von Ge0rgy

Wenn man aber betrachtet dass BD bei AVX256 nur grob die Hälfte der Rohleistung gegenüber Sandy aufbieten kann, sind die Werte wiederum recht ordentlich - denn Sandy ist nicht doppelt so schnell.

Ja, aber das musst Du dann auch innerhalb Intels- betrachten. Allgemein bringt AVX nicht soviel da yCrunsher die langen Vektoren nicht überall gebrauchen kann, Auszug aus dem FAQs:

Q: Why does AVX (v0.5.5) only give about 10% speedup over SSE4.1 (v0.5.4)? Shouldn't it be double the speed?
A: Unlike the majority of compute-intensive applications, y-cruncher does not exclusively use floating-point. As of v0.5.4, only about 30% of a Pi computation is floating-point bound. The remainder of the time is spent on integer operations and stalling on memory access. So cutting that 30% in half yields little overall speedup. Speeding up the code in this manner exposes more memory bottlenecks - which ends up reducing the speedup to only 10%...

Inwieweit die Compiler dabei reinspielen, kann ich aber auch nicht abschätzen. Interessant allemal, dass der ICC überhaupt SSE > 2 auf AMD-CPUs benutzt.

Ja es lebe die Kartellklage. Seitdem gibts Architektur-Optiemierungsflags /arch:SSExyz, die zumindest bei yCrunsher dem normalen Code für Intels entsprechen. Zumindest konnte der Autor auf nem Intel keine Unterschiede zw. den Compilaten festellen, wenn ich mich recht erinnere.
Also alles ganz brauchbar. Ausnahme ist AVX, da gibts noch keine Architekturoptimierung, aber das ist ja egal, da MS Visual Studio den schnelleren Code liefert. Lustig.

[Crashtest]

Fraglich wäre, wieviel eine Kompilierung mit PGI-Compiler bringen würde - immerhin bietet der auch guten Support für Bulldozer sowie die passenden ACML ...

[Helle53]

Eins vorweg: Wenn ein (Desktop)-Prozessor mit neuen Funktionen auf den Markt kommt ist dies ein Anreiz für mich, das Ding zu haben. Für mich sind alle neuen Funktionen "nice to have"; egal von welchem Hersteller und ob sie direkt (sofort) irgend einen Nutzen bringen. Jetzt zu FMA (egal in welcher Variation): Echt "nive to have", aber ausserhalb von synthetischen Benchmarks bitte nicht überschätzen! So oft kommt die Kombination MUL/ADD(SUB) in normalen Code nicht vor; auch in y-cruncher nicht. Übrigens habe ich mal Tests mit einem FX-8120 bezüglich FMA4 vs. AVX gemacht; FMA4 also eine Instruktion, AVX zwei getrennte Instruktionen (1.MUL, 2.ADD /SUB). Der Speed-Unterschied lag bei ca.30% (also FMA4 ca.30% schneller). Die Abweichungen bez. Genauigkeit lagen im Dunstkreis der üblichen Float-Abweichungen, hier greifen sicher erst etliche aufeinander aufbauende Berechnungs-Terme; in der Praxis eher selten.
So, jetzt direkt zu y-cruncher (@GeOrgy): FAM4 wird nicht viel bringen, die Nutzung von (möglichst vielen) 256-Bit-Operationen bringen die Punkte. In y-cruncher sind ca.30% Float-Berechnungen (s.o. Opteron). Gehen wir mal davon aus das weitere 30% Integer-Berechnungen von 256-Bit-Integer-Operationen profitieren könnten, warte ich mal auf Haswell mit AVX2; also 256-Bit-Integer-Operationen.
Mein Gott, nach einem Biergarten-Besuch schreibt man doch ein bisschen mehr. Also meine Kern-Aussage: FMA wird hier (für y-cruncher) nicht der große Bringer sein.

[Opteron]

@Helle53:
So ganz einfach ist es doch nicht, der Kollege hat da mehrer Algos am Start:

Now to answer wuttz's question:

I expect FMA4 to give a noticable speedup on computations smaller than 100 million digits assuming sufficient memory bandwidth. For larger sizes, the only algorithm that can use FMA is no longer scalable and thus the program switches to an integer-based algorithm that uses a lot less floating-point.

However, once the size exceeds 80 billion digits, the integer-algorithm falls apart as well. In v0.6.1, I will be introducing a new algorithm that will efficiently handle these huge sizes. This algorithm is nearly 100% vector floating-point and uses a LOT of FMA and XOP instructions. It is the first algorithm that I have written specifically for XOP and FMA. On Intel processors, I'm emulating the FMAs by simply not fusing them and the XOP instructions with a set of equivalent instructions. The results are already very good on Intel.

The drawback is that, you need to reach 80 billion digits, which means will need an insane amount of disk bandwidth to see this algorithm fully abuse FMA and XOP.

Now you'll be asking why I can't use this new algorithm for smaller sizes. The answer is that it's slower than the integer algorithm.

On Bareclona, it's 2.5x slower. (SSE3 only)
On Core 2, it's 2.0x slower. (SSE4.1)
On Sandy Bridge, it's 1.2x slower. (AVX)


It's only when the integer algorithm falls apart at the large sizes and becomes inefficient that the new algorithm becomes faster.

However, this gap narrows as the instruction set strengthens. So we may see this algorithm viable at smaller sizes. Time will tell. I need the hardware to see for myself.

http://www.amdzone.com/phpbb3/viewto...138791#p210752
Eventuell wäre auf nem BD mit FMA schon ein Plus drin, aber er hat halt keinen BD zum Testen.

[yasu]

i5-2500k @ 3,3GHz. Turbo hab ich auf den Takt fest gelegt.


Edit:
Hier noch mit 3,0 GHz:


Edit2:
So jetzt auch mit der richtigen Anzahl an Digits @3GHz. ^^"


Auslastung lag zumeist bei 98-100% auf allen 4 Kernen.

[Ge0rgy]

@Opteron und Helle
Danke für die weiteren Infos.
Ich finde die BD-Zahlen bei den entsprechenden Befehlssätzen sprechen dennoch Bände.
Mal die AVX - Porblematik aussen vor und die Tatsache dass FMA keine Verwendung findet, hatten wir doch im Spekuforum auch mal ein Schaubild das sich mit Instruktionslatenzen bei der FPU beschäftigt, wo man recht gut sehen konnte dass SSE3 noch mit am besten optimiert ist, einige Teile von SSE4 sind auch rasend schnell, und dann explodieren die Latenzzahlen. Heisst für mich:
Als AVX verabschiedet wurde, war BD schon soweit fortgeschritten, dass man die Kodierung übernommen hat, die SSE5-Fähige FPU aufgebohrt hat damit sie 256Bittig arbeiten kann für die breiten Befehle, aber nicht mehr unheimlich viel Zeit in die optimierung dort investiert hat.
Selbst wenn AVX keine Verdoppelung bringt, auch auf Sandy nicht, kann man dennoch sehen, dass während Sandy sauber skaliert und in AVX nochmal an Geschwindigkeit zulegt, Bulldozer im Gegenzug bei AVX ohne FMA deutlich nachlässt.
Wenn man aber auch in den FAQ lesen kann, dass es einige Integer-Operationen gibt und Speicherbandbreite die zum Flaschenhals werden können, stellen sich mir dir Fragen:
1. Wie gut schmeckt der reine Integer-Teil des Benchmarks den BD-INT-Cores, und ließe sich da noch was gewinnen mit besseren Optimierungen.
2. Ist vielleicht garnicht AVX und dessen Implementierungsschwäche auf BD ein Problem, sondern eher die Speicherbandbreite, wo wir ja wissen dass es gewisse "Probleme" geben kann mit zu kleinen L1D-Caches, Trashing und mehreren Limitierungen beim Cachezugriff in BD (Siehe Agner Fog)
3. Bietet Piledriver irgend eine Verbesserung in diesen Punkten?

Nebenbei ist es schön zu lesen dass der Autor an einer FMA + XOP - Version arbeitet - auf die Ergebnisse bin ich sehr gespannt.
Sollte Steamroller nicht auch AVX2 beherrschen?

[Helle53]

Die FMA/XOP-Version wird mich auch sehr interessieren. XOP sind ja durchweg (spezielle) Integer-Instruktionen und ich habe im Moment keine Vorstellung, wie A.Yee diese bei Chudnovsky nutzen will. Aber ich lasse mich da gerne positiv überraschen !

[Helle53]

Es gibt jetzt die Version 0.6.1.9282, aber noch nichts mit FMA oder XOP.