• 06.04.2019

    von Veröffentlicht: 06.04.2019 07:00
    1. Kategorien:
    2. Projekte

    Die Entwicklung der GPU-Anwendung hat zu einer signifikanten Optimierung der CPU-Anwendung geführt, wodurch nun im Umkehrschluss die typische GPU nur noch so schnell wie zwei bis drei CPU-Kerne und daher weniger effizient ist.

    Neuigkeiten zur GPU-Anwendung
    In der letzten Woche hat es einige neue Entwicklungen gegeben. Sie sind sowohl gut als auch schlecht.

    Zuerst einmal etwas Geschichte. Der Grund, warum ich so lange gewartet habe, um eine GPU-App zu entwickeln, ist, dass die Berechnung stark von Multipräzisionsbibliotheken (gmp) und zahlentheoretischen Bibliotheken (pari/gp) abhängig war. Beide verwenden dynamisch zugewiesenen Speicher, was bei GPUs ein großes Tabu ist. Ich fand online eine Multi-Präzisionsbibliothek, die ich verwenden konnte, indem ich die Genauigkeit bis zum maximal erforderlichen Wert (ca. 750 Bit) fest kodierte und so die Abhängigkeit von Speicherzuweisungen beseitigte. Das nächste Teil des Puzzles bestand darin, eine polynomale Diskriminanzfunktion zu kodieren. Danach konnte ich endlich einen Kernel für die GPU kompilieren. Das ist die Historie für die aktuelle GPU-App. Sie ist etwa 20 bis 30 mal schneller als die aktuelle CPU-Version (abhängig von WU und CPU/GPU-Geschwindigkeiten).

    Aber dann dachte ich nach.... mein GPU polynomialer Diskriminanzalgorithmus unterscheidet sich von dem in der PARI-Bibliothek (ihrer funktioniert für jeden Grad und meiner ist auf Grad 10 spezialisiert). Um also einen direkten Vergleich zu machen, habe ich den PARI-Algorithmus durch meinen in der CPU-Version des Codes ersetzt. Ich war schockiert von dem, was ich fand.... die CPU-Version war jetzt etwa 10x schneller als früher. Ich hätte nie gedacht, dass ich in der Lage wäre, einen Algorithmus zu schreiben, der 10x schneller wäre als eine gut etablierte Bibliotheksfunktion. WTF? Jetzt trete ich mir in den Hintern, weil ich das nicht früher gemacht habe!

    Das bringt gemischte Emotionen mit sich. Auf der einen Seite ist es toll, dass ich jetzt eine CPU-Version habe, die 10x schneller ist. Aber es bedeutet auch, dass mein GPU-Code totaler Mist ist. Mit all der Leistung in einer heutigen GPU würde ich erwarten, dass sie mindestens 10x schneller ist als die entsprechende CPU-Version. Im Vergleich zur neuen CPU-Version ist die GPU nur 2 bis 3 mal schneller. Das ist inakzeptabel.

    Der neue Plan sieht also wie folgt aus:
    1. Neue CPU-Ausführungsdateien bereitstellen. Da sie um das 10-fache schneller sind, muss ich die Credits um den Faktor 10 reduzieren. (Die Credits pro Stunde bleiben für die CPU gleich, fallen aber für die GPU offensichtlich ab).
    2. Entwicklung neuer und verbesserter GPU-Kernel.

    Ich kann es den GPU-Benutzern nicht verübeln, dass sie an dieser Stelle das Schiff verlassen haben. Offen gesagt, die Ineffizienz der aktuellen GPU-App macht es einfach nicht wert (für sie oder das Projekt).

    Wie dem auch sei, ich hatte openCL-Versionen gebaut. Die Nvidia-Version funktioniert perfekt. Die AMD-Version ist aus irgendeinem Grund fehlerhaft, ebenso wie die Windows-Version. Da ich die Kernel sowieso ändern werde, hat es keinen Sinn, sie noch zu debuggen.
    06.04.2019, 00:40:01 MEZ

    Originaltext:
    Zitat Zitat von https://numberfields.asu.edu/NumberFields/forum_thread.php?id=366
    GPU app status update
    So there have been some new developments over the last week. It's both good and bad.

    First of all, some history. The reason I waited so long to develop a GPU app is because the calculation was heavily dependent on multi-precision libraries (gmp) and number theoretic libraries (pari/gp). Both of these use dynamically allocated memory which is a big no-no in GPUs. I found a multi-precision library online that I could use by hard coding the precision to the maximum required (about 750 bits), thereby removing the dependence on memory allocations. The next piece of the puzzle was to code up a polynomial discriminant function. After doing this, I could finally compile a kernel for the GPU. That is the history for the current GPU app. It is about 20 to 30 times faster than the current cpu version (depends on WU and cpu/gpu speeds).

    But then I got thinking... my GPU polynomial discriminant algorithm is different from the one in the PARI library (theirs works for any degree and mine is specialized to degree 10). So to do a true apples-to-apples comparison, I replaced the PARI algorithm with mine in the cpu version of the code. I was shocked by what I found... the cpu version was now about 10x faster than it used to be. I never thought I was capable of writing an algorithm that would be 10x faster than a well established library function. WTF? Now I'm kicking myself in the butt for not having done this sooner!

    This brings mixed emotions. On one side, it is great that I now have a cpu version that is 10x faster. But it also means that my GPU code is total crap. With all the horsepower in a present day GPU I would expect it to be at least 10x faster than the equivalent cpu version. Compared with the new cpu version, the gpu is only 2 to 3 times faster. That is unacceptable.

    So the new plan is as follows:
    1. Deploy new cpu executables. Since it's 10x faster, I will need to drop the credit by a factor of 10. (Credits/hour will remain the same for the cpu but will obviously drop for the GPU)
    2. Develop new and improved GPU kernels.

    I don't blame the GPU users for jumping ship at this point. Frankly, the inefficiency of the current GPU app just makes it not worth it (for them or the project).

    For what it's worth, I did have openCL versions built. Nvidia version works perfectly. The AMD version is buggy for some reason, as is the windows version. Since I will be changing the kernels anyways, there is no point in debugging them yet.
    5 Apr 2019, 23:40:01 UTC
Single Sign On provided by vBSSO