2012-03-12 18 views
7

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?

+1

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 –

+0

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

+0

@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

Odpowiedz

18

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.

+0

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 –