[ad_1]

Intel oneAPI, framework programistyczny, jest wykorzystywany przez naukowców z Uniwersytetu Tsukuba do obsługi akceleracji wielohetero, w tym NVIDIA GPU i Intel FPGA jednocześnie. Zespół opracował środowisko oneAPI, które wykorzystuje jeden język programowania, Data Parallel C++ (DPC++), do zarządzania różnymi akceleratorami.

Naukowcy badają również wykorzystanie programowalnych macierzy bramek (FPGA) obok układów GPU w celu przezwyciężenia ograniczeń w obliczeniach o wysokiej wydajności. Zaproponowali oni koncepcję o nazwie CHARM (Cooperative Heterogeneous Acceleration with Reconfigurable Multidevices), by zmaksymalizować ogólną wydajność aplikacji poprzez komplementarne wykorzystanie układów GPU i FPGA.

Czym jest Intel oneAPI i jak działa z programowaniem akceleracji wielohybrydowej?

Intel oneAPI to platforma programistyczna, która akceptuje różne akceleratory, takie jak procesory graficzne (GPU), programowalne tablice bramek (FPGA) i wielordzeniowe jednostki centralne (CPU). Koncentruje się głównie na aplikacjach obliczeniowych o wysokiej wydajności (HPC). Użytkownicy mogą stosować swój kod napisany w jednym języku, Data Parallel C++ (DPC++), w tym heterogenicznym środowisku programowania. Jednak nie zawsze łatwo jest zastosować go do różnych akceleratorów, zwłaszcza w przypadku urządzeń innych niż Intel, takich jak procesory graficzne NVIDIA i AMD.

Naukowcy z Uniwersytetu Tsukuba, Wentao Liang, Norihisa Fujita, Ryohei Kobayashi i Taisuke Boku, z powodzeniem skonstruowali zestaw środowiska OneAPI, który wykorzystuje pojedyncze programowanie DPC++ do obsługi prawdziwej akceleracji wielohetero, w tym GPU NVIDIA i Intel FPGA jednocześnie. W niniejszym artykule omówiono, w jaki sposób udało się to osiągnąć i jakiego rodzaju aplikacje mogą być celem.

Dlaczego akceleratory w obliczeniach o wysokiej wydajności stają się coraz bardziej powszechne?

Wykorzystanie akceleratorów w obliczeniach o wysokiej wydajności stało się bardziej powszechne niż kiedykolwiek wcześniej. Wśród tych akceleratorów, jednostka przetwarzania grafiki (GPU) stała się ważnym komponentem i często przewyższa możliwości tradycyjnej jednostki centralnej (CPU) w wielu scenariuszach wysokiej wydajności i efektywności energetycznej. Przejście to jest szczególnie widoczne w wysoce zrównoleglonych zadaniach i symulacjach fizycznych.

Jednakże, nie wszystkie operacje aplikacji są wysoce zrównoleglone, a niektóre operacje są drobnoziarniste lub wymagają dużej ilości komunikacji. Układy GPU są z natury źle przystosowane do takich operacji, a prawo Amdahla sprawia, że stanowią one wąskie gardło dla poprawy wydajności. Oznacza to, że korzyści płynące z odciążania GPU mogą być ograniczone.

W jaki sposób programowalne tablice bramek (FPGA) mogą zaradzić ograniczeniom procesorów graficznych?

Aby zaradzić ograniczeniom procesorów graficznych, uwaga skupiła się na wykorzystaniu programowalnych macierzy bramek (FPGA). FPGA to adaptowalne urządzenie sprzętowe, które można rekonfigurować poprzez programowanie w celu wydajnego wykonywania określonych funkcji. Jego funkcja umożliwia budowanie akceleratorów specjalizujących się w obliczeniach, do których procesory graficzne nie są odpowiednie. Arytmetyka zmiennoprzecinkowa i wydajność pamięci, które układy FPGA mogą zapewnić jako sprzęt, nie są jednak tak dobre jak układy GPU, a zatem całkowite przejście z odciążania GPU na odciążanie FPGA nie jest dobrym pomysłem.

Dlatego też badacze proponują wykorzystanie układów GPU i FPGA jako wysokowydajnych akceleratorów obliczeniowych we właściwych miejscach w celu przyspieszenia wszystkich obliczeń cząstkowych w aplikacjach na dużą skalę. Wykorzystanie technologii FPGA równolegle z procesorami graficznymi może mieć potężny efekt synergii i skutkować znacznym wzrostem wydajności, zwłaszcza w aplikacjach takich jak symulacje wielofizyczne.

Czym jest koncepcja CHARM i w jaki sposób maksymalizuje ona ogólną wydajność aplikacji?

Koncepcja wykorzystania układów GPU i FPGA do obsługi różnych obciążeń w celu uzyskania wyższej wydajności nosi nazwę CHARM (Cooperative Heterogeneous Acceleration with Reconfigurable Multidevices). Najważniejszym punktem CHARM jest nie tylko wykorzystanie konkretnych akceleratorów, takich jak GPU lub FPGA, do akceleracji aplikacji, ale także wykorzystanie obu w sposób komplementarny, aby zmaksymalizować ogólną wydajność aplikacji.

Dlatego też procesory graficzne są wykorzystywane w gruboziarnistych aplikacjach równoległych, podczas gdy wiele układów FPGA połączonych szybkim interkonektem autonomicznie wykonuje komunikację i obliczenia w obszarach, w których procesory CPU/GPU są nieefektywne. Naukowcy wykazali, że można osiągnąć znaczne przyspieszenie, jeśli CHARM zostanie prawidłowo zastosowany w aplikacji docelowej.

Jakie są wyzwania i rozwiązania we wdrażaniu koncepcji CHARM?

Najważniejszą kwestią, którą należy obecnie rozwiązać, jest metoda programowania CHARM. Metoda implementacji obliczeń akcelerowanych przez GPU-FPGA jest mieszanką programowania CUDA i OpenCL, co oznacza, że jądra obliczeniowe działające na GPU są napisane w CUDA, a te działające na FPGA są napisane w OpenCL. To wielojęzyczne programowanie stanowi duże obciążenie dla programistów i dlatego wymagane jest środowisko programistyczne o wyższej użyteczności.

Badacze koncentrują się na Intel oneAPI jako kluczu do rozwiązania tego problemu. Jest to ujednolicona struktura programowania, co oznacza, że akceleratory i host mogą być programowane i kontrolowane przy użyciu tego samego języka programowania i interfejsów API. Ponieważ jednak Intel oneAPI jest zasadniczo ukierunkowany na procesory CPU, GPU i FPGA firmy Intel, nie jest łatwo zastosować go do urządzeń innych niż Intel, takich jak procesory graficzne NVIDIA i AMD. A ponieważ nie zakłada programowania, które obsługuje różne urządzenia komputerowe jednocześnie, istnieją kwestie techniczne, które należy rozwiązać, aby zastosować Intel oneAPI do koncepcji CHARM.

Szczegóły publikacji: „Wykorzystanie Intel oneAPI do programowania akceleracji wielohybrydowej ze sprzężeniem GPU i FPGA”
Data publikacji: 2024-01-11
Autorzy: W. X. Liang, Norihisa Fujita, Ryohei Kobayashi, Taisuke Boku, et al.
Źródło:
DOI:

[ad_2]