W C++ AMP funkcje jądra lub lambdy są oznaczone ograniczeniem (amp), które nakłada surowe ograniczenia na dozwolony podzbiór C++ (listed here). Czy CUDA pozwala na większą swobodę w podzbiorze C lub C++ w funkcjach jądra?Czy ograniczenie (wzmacniacz) jest bardziej restrykcyjne niż kod jądra CUDA?
Odpowiedz
Od wersji Visual Studio 11 i CUDA 4.1, restrict(amp)
funkcje są bardziej restrykcyjne niż analogiczne funkcje CUDA __device__
. Najwyraźniej AMP jest bardziej restrykcyjny w kwestii tego, w jaki sposób można wykorzystać wskaźniki. Jest to naturalna konsekwencja obliczeniowego substratu obliczeniowego DirectX11 firmy AMP, który uniemożliwia wyświetlanie wskaźników w kodzie HLSL (moduł cieniujący grafikę). W przeciwieństwie do CUDA, IR na niższym poziomie to PTX, który jest bardziej ogólny niż HLSL.
Oto linia po linii porównania:
| VS 11 AMP restrict(amp) functions | CUDA 4.1 sm_2x __device__ functions |
|------------------------------------------------------------------------------|
|* can only call functions that have |* can only call functions that have |
| the restrict(amp) clause | the __device__ decoration |
|* The function must be inlinable |* need not be inlined |
|* The function can declare only |* Class types are allowed |
| POD variables | |
|* Lambda functions cannot |* Lambdas are not supported, but |
| capture by reference and | user functors can hold pointers |
| cannot capture pointers | |
|* References and single-indirection |* References and multiple-indirection |
| pointers are supported only as | pointers are supported |
| local variables and function | |
|* No recursion |* Recursion OK |
|* No volatile variables |* Volatile variables OK |
|* No virtual functions |* Virtual functions OK |
|* No pointers to functions |* Pointers to functions OK |
|* No pointers to member functions |* Pointers to member functions OK |
|* No pointers in structures |* Pointers in structures OK |
|* No pointers to pointers |* Pointers to pointers OK |
|* No goto statements |* goto statements OK |
|* No labeled statements |* Labeled statements OK |
|* No try, catch, or throw statements |* No try, catch, or throw statements |
|* No global variables |* Global __device__ variables OK |
|* Static variables through tile_static |* Static variables through __shared__ |
|* No dynamic_cast |* No dynamic_cast |
|* No typeid operator |* No typeid operator |
|* No asm declarations |* asm declarations (inline PTX) OK |
|* No varargs |* No varargs |
można przeczytać więcej na temat ograniczeń restrict(amp)
„s here. Możesz przeczytać o obsłudze C++ w funkcjach CUDA __device__
w dodatku D do CUDA C Programming Guide.
IIRC jest dyskusja na temat funkcji włączonych w C++ AMP, ale nie w oparciu o wyraźne wybory zachęcające do dobrych praktyk w obliczeniach równoległych: http://channel9.msdn.com/Shows/Going+Deep/C- AMP-The-Development-Team-Technical-RoundTable –
Mogą być powiązane z następującym pytaniem. http://stackoverflow.com/questions/4899425/what-are-the-real-c-language-constructs-supported-by-cuda-device-code –
Dobre pytanie, choć obawiam się, że nie jest tak naprawdę porównywalne (może migrować do programmers.SE?): nvcc w ogóle nie obsługuje jeszcze C++ 11, więc mówiąc o lambdasie, najwyraźniej nie znajdziesz się zbyt daleko! Z drugiej strony AMP ma zupełnie inne ograniczenia, poczynając od Microsoftu; ten (lub, bardziej poprawnie, obecny brak implementacji bez DirectX) sprawia, że jest on całkowicie bezużyteczny dla wielu, np. zastosowania naukowe. Ale przypuszczam, że masz na myśli tylko ograniczenia _language_? – leftaroundabout
@leftaroundabout: Tak, mówię tylko o ograniczeniach _language_ i jestem w porządku pozostać w C++ 03. Wspomniałem lambdy tylko dlatego, że jest to zalecany mechanizm uruchamiania kodu jądra z C++ AMP. – Eugene