JulM hat geschrieben:Wie wird denn genau der Speed-Up berechnet? [...] (execution time cpu) / (execution time gpu) = speed up, ist das richtig so?
Genau, solange ihr nur die reine Berechnungszeit ohne Dateiladen etc. beruecktsichtigt.
JulM hat geschrieben:Denn noch bekomme ich meinen Kernel nicht unter 126 ms , dabei habe ich mich sehr an den reinen CPU-Code gehalten. Um es noch etwas zu reduzieren müsste man wahrscheinlich, die Berechnung noch verändern oder?
Wahrscheinlich musst du dann wirklich noch etwas mehr vom CPU-Code abweichen. Es gibt auch oft Anwendungsfaelle, bei denen man auf der GPU ganz andere Wege geht als auf der CPU, damit die GPU voll ausgelastet wird.
Du kannst ja mal versuchen eine Art Profiling zu machen, indem du nacheinander einzelne Codeabschnitte (von einer Synchronisation zur naechsten) doppelt ausfuehren laesst (einfach durch Codekopieren). Dann ist zwar u.U. das Endergebnis nicht mehr korrekt aber du kannst sehen, welcher Abschnitt die Ausfuehrungszeit am meisten verlaengert.
bttf hat geschrieben:Es ging uns nur darum 42 Work Items in einer Work Group zu haben, deshalb die localWorkSize von 7*7. Ob das das Ganze auch schneller macht....keine Ahnung ).
Ihr koennt die localWorksize beliebig machen, z.B. auch 42*1. Das haette auch den Vorteil, dass ihr nurnoch auf get_local_id(
0) zugreifen muesst.
Generell ist es sinnvoll, wenn die localWorksize ein Vielfaches der Zahl der Threads ist, die ein CUDA-Core gleichzeitig ausfuehrt, also 32. Wenn die localWorksize ein echtes Vielfaches (also nicht 1*32 sondern 2*32, ...) ist, kann der Cudacore auch Latency Hiding machen, d.h. waehrend er fuer einen Satz von 32 Threads auf Speicheranfragen wartet, kann er in der Zwischenzeit an einem anderen Satz von 32 Threads weiterrechnen.