Optimierte MilkyWay@home Applikation
- Ersteller Twodee
- Erstellt am
Muß ich verstehen, wie Du auf 4 kommst? Und warum hat SSE1 was damit zu tun?Mein Trick ist, das ich 4xSQRTs bzw. 4xEXP/LOG auf einmal mit doppelter genauigkeit rechnen lassen kann, [bei SSE sind es nur noch 2 auf einmal] dafür büse ich an anderen Stellen durch arrays wieder ein
weil ich LOG/EXP/SQRT über die SSE-Units berechnen lasse, allerdings nicht so wie es MS beschreibt (single precision) sondern etwas umständlicher (double precision)
Crunch3r
Vice Admiral Special
und wo bleibt pow ?
solltest dir das mal anschauen
Code:
#define EXP_POLY_DEGREE 3
#define POLY0(x, c0) _mm_set1_ps(c0)
#define POLY1(x, c0, c1) _mm_add_ps(_mm_mul_ps(POLY0(x, c1), x), _mm_set1_ps(c0))
#define POLY2(x, c0, c1, c2) _mm_add_ps(_mm_mul_ps(POLY1(x, c1, c2), x), _mm_set1_ps(c0))
#define POLY3(x, c0, c1, c2, c3) _mm_add_ps(_mm_mul_ps(POLY2(x, c1, c2, c3), x), _mm_set1_ps(c0))
#define POLY4(x, c0, c1, c2, c3, c4) _mm_add_ps(_mm_mul_ps(POLY3(x, c1, c2, c3, c4), x), _mm_set1_ps(c0))
#define POLY5(x, c0, c1, c2, c3, c4, c5) _mm_add_ps(_mm_mul_ps(POLY4(x, c1, c2, c3, c4, c5), x), _mm_set1_ps(c0))
__inline __m128 exp2f4(__m128 x)
{
__m128i ipart;
__m128 fpart, expipart, expfpart;
x = _mm_min_ps(x, _mm_set1_ps( 129.00000f));
x = _mm_max_ps(x, _mm_set1_ps(-126.99999f));
/* ipart = int(x - 0.5) */
ipart = _mm_cvtps_epi32(_mm_sub_ps(x, _mm_set1_ps(0.5f)));
/* fpart = x - ipart */
fpart = _mm_sub_ps(x, _mm_cvtepi32_ps(ipart));
/* expipart = (float) (1 << ipart) */
expipart = _mm_castsi128_ps(_mm_slli_epi32(_mm_add_epi32(ipart, _mm_set1_epi32(127)), 23));
/* minimax polynomial fit of 2**x, in range [-0.5, 0.5[ */
#if EXP_POLY_DEGREE == 5
expfpart = POLY5(fpart, 9.9999994e-1f, 6.9315308e-1f, 2.4015361e-1f, 5.5826318e-2f, 8.9893397e-3f, 1.8775767e-3f);
#elif EXP_POLY_DEGREE == 4
expfpart = POLY4(fpart, 1.0000026f, 6.9300383e-1f, 2.4144275e-1f, 5.2011464e-2f, 1.3534167e-2f);
#elif EXP_POLY_DEGREE == 3
expfpart = POLY3(fpart, 9.9992520e-1f, 6.9583356e-1f, 2.2606716e-1f, 7.8024521e-2f);
#elif EXP_POLY_DEGREE == 2
expfpart = POLY2(fpart, 1.0017247f, 6.5763628e-1f, 3.3718944e-1f);
#else
#error
#endif
return _mm_mul_ps(expipart, expfpart);
}
#define LOG_POLY_DEGREE 5
__inline __m128 log2f4(__m128 x)
{
__m128i exp = _mm_set1_epi32(0x7F800000);
__m128i mant = _mm_set1_epi32(0x007FFFFF);
__m128 one = _mm_set1_ps( 1.0f);
__m128i i = _mm_castps_si128(x);
__m128 e = _mm_cvtepi32_ps(_mm_sub_epi32(_mm_srli_epi32(_mm_and_si128(i, exp), 23), _mm_set1_epi32(127)));
__m128 m = _mm_or_ps(_mm_castsi128_ps(_mm_and_si128(i, mant)), one);
__m128 p;
/* Minimax polynomial fit of log2(x)/(x - 1), for x in range [1, 2[ */
#if LOG_POLY_DEGREE == 6
p = POLY5( m, 3.1157899f, -3.3241990f, 2.5988452f, -1.2315303f, 3.1821337e-1f, -3.4436006e-2f);
#elif LOG_POLY_DEGREE == 5
p = POLY4(m, 2.8882704548164776201f, -2.52074962577807006663f, 1.48116647521213171641f, -0.465725644288844778798f, 0.0596515482674574969533f);
#elif LOG_POLY_DEGREE == 4
p = POLY3(m, 2.61761038894603480148f, -1.75647175389045657003f, 0.688243882994381274313f, -0.107254423828329604454f);
#elif LOG_POLY_DEGREE == 3
p = POLY2(m, 2.28330284476918490682f, -1.04913055217340124191f, 0.204446009836232697516f);
#else
#error
#endif
/* This effectively increases the polynomial degree by one, but ensures that log2(1) == 0*/
p = _mm_mul_ps(p, _mm_sub_ps(m, one));
return _mm_add_ps(p, e);
}
__inline __m128 new_powf (__m128 x,__m128 y){
return exp2f4(_mm_mul_ps(log2f4(x),y));
}Sowas gibts auch noch für sin und cos ...
@Cruncher, ist bekannt.
Pow kann man auch über Log/EXP realisieren, und im MW fall kann man es weglassen
(aber nur wenn die parameter es zulassen).
Sin/Cos geht auch über SSE, ist um ca. 5-6 mal schneller als x87, lohnt sich aber in MW ebenfalls nicht, zumindest nicht für die wenigen Aufrufe, da fällt mehr overhead an
Pow kann man auch über Log/EXP realisieren, und im MW fall kann man es weglassen
(aber nur wenn die parameter es zulassen).Sin/Cos geht auch über SSE, ist um ca. 5-6 mal schneller als x87, lohnt sich aber in MW ebenfalls nicht, zumindest nicht für die wenigen Aufrufe, da fällt mehr overhead an
Du kannst aber auch nichts für Dich behaltenPow kann man auch über Log/EXP realisieren, und im MW fall kann man es weglassen
ach ich bitte dich, das ist doch offensichtlichDu kannst aber auch nichts für Dich behalten
.
EDIT :
.
http://milkyway.cs.rpi.edu/milkyway/results.php?hostid=24765
Pentium-M 1400Mhz WinXp32 => SSE2 App ~ 1288 Sekunden, und damit im Creditlimit
[2594 Credit/Tag]
.
EDIT :
.
Q9450@3.6Ghz WinXp64 => SSE3 32Bit App ~ 228 Sekunden
.
EDIT :
.
könnte jemand mit einem X4 die SSE2 und SSE3 App gegentesten?
http://www.file-upload.net/download-1320653/MW.rar.html
.
EDIT :
.
![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
kann nicht sein
Zuletzt bearbeitet:
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.066
- Renomée
- 10.446
Beim Testen bin ich gerne dabei wenn's hilft
AMD Phenom X4 9650
Gipsels SSE3V2 => 420 s
Deine neue SSE3 = 480 s
Scheint also Gipsels App für Phenoms besser geeignet zu sein. Vielleicht ist es der ICC11 Penalty für AMD-CPUs
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.066
- Renomée
- 10.446
Die Creditvergabe bei Milkyway ist immer noch ein Witz. Aber das ist die Schuld des Betreibers, nicht der Anwender
Dass sich viele der prinzipiell technikinteressierten P3D-User jetzt so auf Milkyway stürzen, liegt in der Natur der Sache. Das war schon bei Einstein so, als die Power-Apps herauskamen und ist mit SETI nicht anders, seit die Alex-v8 Applikationen raus sind. Man sieht ja auch in den SETI-Stats (Klick auf WU-Ergebnis-ID), dass kaum einer der Stammuser noch mit den Standard-Apps rechnet. Und das liegt imo nicht an den Credits (so viele gibt's davon nicht bei SETI und Einstein), sondern am Optimierungsgedanken. Technikverliebte Anwender schätzen es, wenn durch die Software das letzte Quäntchen an Leistung aus dem System geholt wird. Das ist ja auch der Hintergedanke am Übertakten und der Grund wieso manche alle 2 Tage ein neues Beta-BIOS flashen oder einen neuen Beta-Treiber ausprobieren. Dass die Weiterentwicklung bei Milkyway jetzt auch noch im Heimforum von Usern aus den eigenen Reihen stattfindet, ist sicherlich eine zusätzliche Motivation.
Was Gipsel und Twodee angeht, so kann ich deren Motivation auch verstehen. Als ich im Studium noch programmiert habe, habe ich mich ebenfalls stundenlang damit befasst, bestimmte Routinen zu optimieren, um noch ein paar Sekunden Leistung aus der Anwendung herauszuholen. Das ist quasi Sport. Irgendwann geht's auch gar nicht mehr um die Anwendung selbst, sondern nur noch darum, irgendwo noch eine versteckte Handbremse zu finden. Dass jetzt zwei Programmierer parallel an der Milkyway-App optimieren, forciert das ganze noch, schließlich will man ja besser sein, bessere und gewitztere Ideen zur Optimierung haben, als der andere.
Auch das kenne ich nur zu gut Wichtig ist nur, dass am Ende das gleiche Ergebnis herauskommt, wie bei der Standard-App. Und da auch DC eine Art Wettkampf ist, dass die Apps für jeden frei zugänglich veröffentlicht werden. Beides ist der Fall.Dass sich die Programmierer jetzt auf MW gestürzt haben, hat imo auch wenig mit den Credits zu tun, sondern schlichtweg mit der Tatsache, dass es eines der wenigen Projekte ist wo der Quellcode offen liegt. Es ist schwierig eine closed Source Anwendung zu optimieren
Vielleicht motivieren die unglaublichen Fortschritte bei der Optimierung ja das ein oder andere Projekt ebenfalls den Code zu veröffentlichen. Eigentlich müsste ja jeder Betreiber, der das DC-Projekt nicht nur zum Spaß an der Freud laufen hat, sondern weil er Ergebnisse sehen will, die er für irgendwas wichtiges braucht, froh sein über Leistungssteigerungen im vierstelligen Prozentbereich Und das führt mich auch gleich direkt zum Thema Stromverbrauch und alte Hardware. Ich betreue eine ganze Reihe von Schulungsräumen, die ca. 4-5 Jahre alt sind. Vor geraumer Zeit schon habe ich das verteilte Rechnen auf diesen Maschinen (Sempron 2200+) eingestellt, weil es wirtschaftlich und ökologisch einfach keinen Sinn mehr macht DC auf Hardware zu betreiben, wo ein ganzer Schulungsraum mit 17 PCs und seinem entsprechenden Stromverbrauch von 2,5 kW weniger Ergebnisse liefert, als ein einzelner aktueller Quad-Core Computer mit einem Zehntel des Stromverbrauchs. Zudem wird mit den alten Kisten idR eine WU gar nicht mehr innerhalb eines Unterrichtstages fertig, ehe die Maschine am nächsten Tag per PC-Wächter wieder auf 0 zurückgesetzt wird. Mit den bis zur Bewusstlosigkeit optimierten MW-Apps dagegen habe ich wieder das Gefühl, dass deren Einsatz auch auf den alten Maschinen mehr ist als nur Stromverschwendung, da sie jeden Transistor ausquetscht wie eine Zitrone. Ferner werden die Ergebnisse innerhalb von 1-2 Stunden fertig und damit schnell genug, um es innerhalb eines Unterrichtstages zu schaffen. Und das sind derzeit meine beiden Haupt-Argumente pro MW.
Beim Testen bin ich gerne dabei wenn's hilft
AMD Phenom X4 9650
Gipsels SSE3V2 => 420 s
Deine neue SSE3 = 480 s
Scheint also Gipsels App für Phenoms besser geeignet zu sein. Vielleicht ist es der ICC11 Penalty für AMD-CPUs
das is gut möglich.
was mir auch aufgefallen ist, ist das die reine SSE2 Version nicht mehr (seit dem der ICC11 im Spiel ist) auf AMD Cpus läuft. Die App läuft weder auf einem K8 sempron, X2-4000 noch Opteron, allerdings läuft diese App auf einem Pentium-M (der SSE2 kann). Die SSE3 App hingegen läuft auf dem X2. SSE1 Apps gehen auch.
DerRob
Fleet Captain Special
naja, bei abc@home erreiche ich auf meinem quadcore im schnitt auch so um die 8.000 credits pro tag. je nach WU könnten da auch bis zu 15.000 credits drin sein, wenn ich z.b. ein paar mehr von diesen WUs erhalte.Die Creditvergabe bei Milkyway ist immer noch ein Witz. Aber das ist die Schuld des Betreibers, nicht der Anwender
SR530
Vice Admiral Special
- Mitglied seit
- 21.04.2003
- Beiträge
- 705
- Renomée
- 4
Ich würde eher sagen, dass es im Bereich von 20-25min gehen sollte, im Vergleich zu meinem XP-M 2600 (~18min).
der 1GHz P3 braucht ~34 Minuten
TAL9000
Grand Admiral Special
Wenn ich das lese überlege ich ernsthaft ob ich nicht MW richtig mit meiner Flotte rechne...
Aber nein, das Projekt mag ich nicht. Trotzdem toll was da an der App noch rausgeholt wird. Travis sollte wirklich eure übernehmen und entsprechend es auf der Projektseite würdigen. Aber bitte gleich nach dem er "etwas" die Credits angepasst hat.
Have phun @MW
TAL9000
Ole
Grand Admiral Special
- Mitglied seit
- 25.01.2003
- Beiträge
- 10.319
- Renomée
- 218
Habe mal die SS2 Version, die Du im Paket mit der SS3 Version zum Test auf PhenomX4 verlinkt hattest auf dem eee mit Sellerie900 @ 630MHz getestet: ca 2500 Sekunden. Ganz ordentlich. Ich werde mal sehen, ob die CPU auf die schnelle auf die "normalen" 900MHz bekomme. 
Edit: Läuft jetzt mit 900MHz, die gerade laufende WU ist also halb/halbe, die nächste wird komplett mit 900MHz gerechnet, falls nicht dazwischen kommt.
Edit: Läuft jetzt mit 900MHz, die gerade laufende WU ist also halb/halbe, die nächste wird komplett mit 900MHz gerechnet, falls nicht dazwischen kommt.
Zuletzt bearbeitet:
manni.deutsch
Grand Admiral Special
moin moin
oder einen Deneb spenden
gruß manni
oder einen Deneb spenden
gruß manni
Ole
Grand Admiral Special
- Mitglied seit
- 25.01.2003
- Beiträge
- 10.319
- Renomée
- 218
Vielleicht drehen die Cruncher von MW mal eine Runde bei WCG.
Das Team krebst dort immer noch auf Platz 21 (Christmas Race) herum.
Ich hau ab und an eine WCG WU durch, genauso wie ab und an ein paar MilkyWays. Wahrscheinlich im Endeffekt sogar mehr WCG als MW, die Berechnungsdauer ist ja ein bisschen höher...
Edit: Der eee braucht bei 900MHz um und bei 17XX Sekunden pro WU. SSE2 App.
Zuletzt bearbeitet:
WCG crunch ich erst wieder, wenn die mal ihr system auf boinc-standard umgestellt haben, vorher nicht wieder.Vielleicht drehen die Cruncher von MW mal eine Runde bei WCG.
Das Team krebst dort immer noch auf Platz 21 (Christmas Race) herum.
Na immerhin eine CPU, auf der meine Version noch schneller istBeim Testen bin ich gerne dabei wenn's hilft
AMD Phenom X4 9650
Gipsels SSE3V2 => 420 s
Deine neue SSE3 = 480 s
Scheint also Gipsels App für Phenoms besser geeignet zu sein. Vielleicht ist es der ICC11 Penalty für AMD-CPUs
Übrigens ist die App von mir mit dem ICC10 erstellt, glaube kaum, daß es daran liegt. Eher schmecken dem Phenom die von Twodee per Hand eingefügten SSEx Routinen nicht so recht. Bei mir ist ja alles ganz normales C was einfach kompiliert wird. Auf Intels scheinen die Optimierungen von Twodee gegenüber dem Compiler was zu bringen, auf AMDs eher nicht.
Fünfstellig!
(80k -> unter 300s für 3.2GHz Quad, ~27.000%)Was für Flags benutzt Du denn? Für SSE2 gibt es zumindest beim ICC10 zwei verschiedene (genau wie für SSE3). Das eine ist jeweils intel only, daß andere läuft auch auf AMD-Kisten und läßt laut Doku ein paar Optimierungen weg.
komisch, bevor ich den ICC11 eingesetzt habe, waren die X2/X4 schneller als die 65nm Intels. Mit ICC11 nichtNa immerhin eine CPU, auf der meine Version noch schneller ist
Übrigens ist die App von mir mit dem ICC10 erstellt, glaube kaum, daß es daran liegt. Eher schmecken dem Phenom die von Twodee per Hand eingefügten SSEx Routinen nicht so recht. Bei mir ist ja alles ganz normales C was einfach kompiliert wird. Auf Intels scheinen die Optimierungen von Twodee gegenüber dem Compiler was zu bringen, auf AMDs eher nicht.
, glaube nicht das es an den händischen SSEx Routinen liegen soll.Fünfstellig!
]hmpf, 80K sollen 80.000 Sekunden sein, oder?
Edit.: Unter Linux hatte die standard app ~10K Sekunden gebraucht.
beim ICC11 gibt es nur eine SSE2 Option, Netburst+Pentium-M (SSE2)
Zuletzt bearbeitet:
@Twodee:
Was mir gerade noch einfällt, wenn ich mich richtig erinnere bietet 3DNow übrigens eine genauere erste Schätzung für die Berechnung der Wurzel als SSE (hat größere Lookuptables). Da hat man als Startwert gleich mal ein paar Bits mehr (Mantisse zu 13Bits genau, anstelle von 10 oder so). Wäre das was für Dich, oder bin ich da auf dem falschen Dampfer?
So eine 3DNow-Version (+SSEx) für P3D hätte doch was
Was mir gerade noch einfällt, wenn ich mich richtig erinnere bietet 3DNow übrigens eine genauere erste Schätzung für die Berechnung der Wurzel als SSE (hat größere Lookuptables). Da hat man als Startwert gleich mal ein paar Bits mehr (Mantisse zu 13Bits genau, anstelle von 10 oder so). Wäre das was für Dich, oder bin ich da auf dem falschen Dampfer?
So eine 3DNow-Version (+SSEx) für P3D hätte doch was
Wofür? Tote soll man ruhen lassen@Twodee:
Was mir gerade noch einfällt, wenn ich mich richtig erinnere bietet 3DNow übrigens eine genauere erste Schätzung für die Berechnung der Wurzel als SSE (hat größere Lookuptables). Da hat man als Startwert gleich mal ein paar Bits mehr (Mantisse zu 13Bits genau, anstelle von 10 oder so). Wäre das was für Dich, oder bin ich da auf dem falschen Dampfer?
So eine 3DNow-Version (+SSEx) für P3D hätte doch was
außerdem wäre ein x^0.5 über SSE2 eh genauer
, und nur unwesentlich langsamer
Ole
Grand Admiral Special
- Mitglied seit
- 25.01.2003
- Beiträge
- 10.319
- Renomée
- 218
@Twodee:
Was mir gerade noch einfällt, wenn ich mich richtig erinnere bietet 3DNow übrigens eine genauere erste Schätzung für die Berechnung der Wurzel als SSE (hat größere Lookuptables). Da hat man als Startwert gleich mal ein paar Bits mehr (Mantisse zu 13Bits genau, anstelle von 10 oder so). Wäre das was für Dich, oder bin ich da auf dem falschen Dampfer?
So eine 3DNow-Version (+SSEx) für P3D hätte doch was
Mein Reden, aber das wurde ja schon vor Wochen mit dem Hinweis abgeschmettert 3DNow sei tot...
Aber so als Spielkram für Nostalgiker und endlich mal eine sinnvolle 3DNow! Nutzung... Hätte was! Schliesslich ist das alles jetzt nur noch Spielkram.
Ähnliche Themen
