You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Wäre cool wenn wir unsere devicePtr wieder verwenden könnten. Also wenn wir das gleiche Argument bei mehreren Kernelausführungen brauchen, könnte man sich dann mehrfaches uploaden und downloaden vom device sparen.
Describe the solution you'd like
Man könnte einfach statt dem CudevicePtr-Attribut einen sharedPtr auf einen CudevicePtr machen. Dieser wird dann beim ersten uploaden initialisiert, kann dann mehrmals verwendet werden und wird dann irgendwann durch den sharedPtr automatisch mit cuMemFree wieder freigegeben, sobald das KernelArg zerstört wird.
Man müsste beachten, dass sich der Inhalt eines KernelArgs auch ändern kann, weswegen dieses dann nochmal hochgeladen werden müsste. Vom JNI kommen aber sowieso nur lesbare KernelArgs.
Weiterhin ist das Ganze insgesamt speicherintensiver, aber dafür halt schneller, wenn man weniger hoch- und runterladen muss.
Weiterhin ist auch die Frage wie gut das mit Java zusammen arbeitet, weil in Java die Objekte ja erst irgendwann vom garbage collector freigegeben werden. Das könnte halt Probleme geben, je nachdem wie viele Argumente noch nicht wieder freigegeben worden sind.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Wäre cool wenn wir unsere devicePtr wieder verwenden könnten. Also wenn wir das gleiche Argument bei mehreren Kernelausführungen brauchen, könnte man sich dann mehrfaches uploaden und downloaden vom device sparen.
Describe the solution you'd like
Man könnte einfach statt dem CudevicePtr-Attribut einen sharedPtr auf einen CudevicePtr machen. Dieser wird dann beim ersten uploaden initialisiert, kann dann mehrmals verwendet werden und wird dann irgendwann durch den sharedPtr automatisch mit cuMemFree wieder freigegeben, sobald das KernelArg zerstört wird.
Man müsste beachten, dass sich der Inhalt eines KernelArgs auch ändern kann, weswegen dieses dann nochmal hochgeladen werden müsste. Vom JNI kommen aber sowieso nur lesbare KernelArgs.
Weiterhin ist das Ganze insgesamt speicherintensiver, aber dafür halt schneller, wenn man weniger hoch- und runterladen muss.
Weiterhin ist auch die Frage wie gut das mit Java zusammen arbeitet, weil in Java die Objekte ja erst irgendwann vom garbage collector freigegeben werden. Das könnte halt Probleme geben, je nachdem wie viele Argumente noch nicht wieder freigegeben worden sind.
The text was updated successfully, but these errors were encountered: