Wywiad: Obietnica Intel oneAPI i Direct Parallel C++

Intel nie jest pierwszą nazwą, która przychodzi na myśl, gdy myślisz o tworzeniu oprogramowania, mimo że jest to jedna z najbardziej wpływowych i innowacyjnych firm technologicznych na świecie. Czterdzieści lat temu procesor Intel 8088 pomógł zapoczątkować rewolucję komputerów PC, a jeśli czytasz to na komputerze stacjonarnym lub laptopie, prawdopodobnie masz Intel Inside. To samo dotyczy serwerów i szeregu innego sprzętu, na którym polegamy na co dzień. Nie oznacza to, że AMD i inni dostawcy nie mają konkurencyjnych produktów, ponieważ mają, ale Intel nadal dominuje na rynku procesorów x86.

Inżynierowie oprogramowania od dziesięcioleci używają platform sprzętowych Intela, zwykle nawet nie biorąc pod uwagę stojącego za nimi oprogramowania i oprogramowania układowego. Jeśli potrzebowali większej wydajności wirtualizacji, zdecydowali się na produkty wielordzeniowe, hiperwątkowe Core i7 lub Xeon. Do majsterkowania w lokalnej bazie danych mogą dostać dysk Intel SSD. Ale teraz Intel chce, aby programiści zaczęli również używać więcej swojego oprogramowania.

Co to jest Intel oneAPI?

Wejdź na platformę oneAPI, reklamowaną przez firmę Intel jako pojedynczy, ujednolicony model programowania, który ma na celu uproszczenie programowania w różnych architekturach sprzętowych: procesory, układy GPU, FPGA, akceleratory AI i nie tylko. Wszystkie mają bardzo różne właściwości i doskonale sprawdzają się w różnego rodzaju operacjach.

Firma Intel jest teraz zaangażowana w strategię „najpierw oprogramowanie” i oczekuje, że programiści zwrócą na to uwagę. Główną ideą oneAPI jest umożliwienie korzystania z jednej platformy dla szeregu różnych urządzeń, dzięki czemu programiści nie będą musieli używać różnych języków, narzędzi i bibliotek podczas kodowania, na przykład, procesorów i kart graficznych. W przypadku oneAPI zestaw narzędzi i baza kodu byłyby takie same dla obu.

Aby było to możliwe, Intel opracował Data Parallel C++ (DPC++) jako alternatywę typu open source dla zastrzeżonych języków zwykle używanych do programowania dla określonego sprzętu (np. GPU lub FFPGA). Ten nowy język programowania ma zapewnić produktywność i znajomość C++, a jednocześnie zawierać kompilator do wdrożenia na różnych docelowych urządzeniach sprzętowych.

Data Parallel C++ zawiera również SYCL firmy Khronos Group w celu obsługi równoległości danych i programowania heterogenicznego. Firma Intel oferuje obecnie bezpłatny dostęp do DevCloud, umożliwiając inżynierom oprogramowania wypróbowanie swoich narzędzi i majstrowanie przy oneAPI i DPC++ w chmurze bez większych problemów.

Ale czekaj, czy będzie działać na sprzęcie innych producentów? A co z licencjonowaniem, czy jest bezpłatne? Tak i tak: oneAPI zostały zaprojektowane tak, aby były niezależne od sprzętu i open-source, i to się nie zmieni.

Aby dowiedzieć się więcej o oneAPI, omówiliśmy jego genezę i przyszłość z Sanjivem M. Shahem, wiceprezesem Intela ds. architektury, grafiki i oprogramowania oraz dyrektorem generalnym działu technicznego, korporacyjnego i przetwarzania w chmurze w firmie Intel.

Sanjiv: Jeśli chodzi o to, co jest w oneAPI, myślę o tym jako o czterech kawałkach. Jedna to biblioteka językowa i standardowa, druga to zestaw narzędzi do głębokiego uczenia się, trzecia to tak naprawdę warstwa abstrakcji sprzętowej i warstwa sterowników oprogramowania, które mogą abstrahować różne akceleratory, a czwarty element to zestaw bibliotek skoncentrowanych na domenie , jak Matlab i tak dalej. To są cztery kategorie rzeczy w oneAPI, ale możemy pójść głębiej i porozmawiać o dziewięciu elementach oneAPI. Te dziewięć elementów to w zasadzie nowy język, który wprowadzamy o nazwie Data Parallel C++ i jego standardowa biblioteka.

Istnieją dwie biblioteki edukacyjne, jedna dla sieci neuronowych i jedna dla komunikacji. Jest biblioteka, którą nazywamy poziomem zero, która służy do abstrakcji sprzętu i są cztery biblioteki skupione na domenie. Robimy to w bardzo, bardzo otwarty sposób. Specyfikacje dla wszystkich z nich są już otwarte i dostępne. Nazywamy je wersją 0.5. Zamierzamy przejść do wersji 1.0 do końca 2020 roku, a także mamy implementacje open-source wszystkich z nich. Ponownie, naszym celem jest umożliwienie ludziom wykorzystania tego, co już jest. Jeśli dostawca sprzętu chce zaimplementować ten język, może wziąć to, co jest otwarte i działać z nim.

P: Jeśli chodzi o algorytmy i implementację, jak to działa?

Dostarczamy prymitywów, których algorytmy używają: podstawowych prymitywów matematycznych i prymitywów komunikacyjnych. Zazwyczaj innowacje algorytmów mają miejsce na wyższym poziomie niż ten, gdzie tak naprawdę nie przerabiają matematyki podstawowej, matematyki macierzowej, matematyki splotowej i tak dalej. Chodzi o wymyślenie nowych sposobów wykorzystania tej matematyki i nowych sposobów wykorzystania wzorców komunikacji. Naszym celem tak naprawdę jest zapewnienie prymitywnego poziomu zerowego, aby inni mogli dodatkowo wprowadzać innowacje.

P: Jak to działa na poziomie sprzętowym?

Jeśli jesteś dostawcą sprzętu, weźmy na przykład macierz AI, kogoś, kto buduje AI ASIC — dostawca sprzętu ma dwa sposoby na „podłączenie się” i wykorzystanie ekosystemu AI. Jednym z nich byłoby dostarczenie tego niskopoziomowego interfejsu sprzętowego, który nazywamy poziomem zero, a jeśli udostępnią swoją wersję poziomu zerowego za pomocą standardowego interfejsu API, mogą wykorzystać open source, jeśli chcą, a następnie wszystkie powyższe warstwy oprogramowania może to automatycznie wykorzystać.

Może to być trudne dla ASIC zorientowanych na segmenty, aby zapewnić pełną ogólność poziomu zerowego. Tak więc, jako alternatywę, mogą również po prostu dostarczyć jądra matematyczne i komunikacyjne, które są w naszej domenie oraz biblioteki głębokiego uczenia, a następnie wykonamy zadanie „podłączenia” tych bibliotek do frameworków wyższego poziomu, więc otrzymaliby to automatycznie.

P: Wspomniałeś, że wersja, którą masz w tej chwili, jest oznaczona jako 0.5, a pełna specyfikacja powinna być gotowa do końca 2020 roku.

Tak więc nasza inicjatywa oneAPI składa się z dwóch części. Jedna to część branżowa, a druga to produkty Intela. Specyfikacja branżowa wynosi 0,5, a mniej więcej w połowie roku chcielibyśmy, aby była to 1,0. Równolegle Intel buduje zestaw produktów, a produkty, które tworzy Intel, są dziś w wersji beta i implementują specyfikację 0.5. Do końca roku chcielibyśmy przejść do produktu 1.0.

Produkt firmy Intel wykracza poza dziewięć elementów oneAPI, ponieważ oprócz podstawowych elementów programistycznych, które dostarczamy, chcemy również zapewnić rzeczy, których programiści naprawdę potrzebują, takie jak debugery, analizatory i narzędzia zgodności, aby mogli migrować z istniejących języków do Data Język równoległy C++.

P: Jak trudne jest przejście dewelopera? Czy szersze środowisko jest podobne do tego, z którego korzystają od lat?

Tak, jest bardzo podobnie. Pozwólcie, że opiszę trochę Data Parallel C++, ponieważ jest to duża część tego, co robimy. DPC++ to trzy rzeczy. Opiera się na międzynarodowym standardzie ISO C++. Istnieje grupa o nazwie Khronos, która definiuje standard o nazwie SYCL, a SYCL jest nałożony na C++. Bierzemy SYCL, a następnie dodajemy rozszerzenia do SYCL. Sposób, w jaki budujemy Data Parallel C++, tak naprawdę jest po prostu C++ z rozszerzeniami, czyli tym, czym jest SYCL.

Każdy kompilator C++ może go skompilować. Piękno DPC++ polega na tym, że każdy kompilator może go skompilować, tylko doświadczony kompilator może skorzystać z tego, co jest w tym języku i wygenerować kod akceleratora. Sposób, w jaki prowadzimy ten język, robimy to bardzo, bardzo otwarcie, więc wszystkie nasze dyskusje na temat Data Parallel C++ odbywają się z komitetem SYCL. Implementacje są open-source, wszystkie rozszerzenia są już opublikowane i pracujemy bardzo, bardzo ostrożnie, aby upewnić się, że mamy dobrą ścieżkę do przyszłych standardów SYCL. Patrząc w dół za 5-10 lat, ścieżka do ISO C++ również.

P: Jeśli chodzi o kompilatory i migrację do DPC++, krzywa uczenia się nie powinna stanowić większego problemu?

Tak, to oczywiście zależy od tego, od czego zaczynasz. Dla programisty C++ krzywa uczenia się byłaby bardzo mała. Dla programisty C musiałbyś pokonać przeszkodę w nauce C++, ale to wszystko. To bardzo znajomy C++. Dla programisty przyzwyczajonego do języków takich jak OpenCL powinno być bardzo podobnie.

Inną częścią, którą muszę podkreślić, jest to, że wykonujemy pracę w otwartym kodzie źródłowym przy użyciu infrastruktury LLVM. Całe nasze źródło jest już otwarte, istnieje repozytorium Intel GitHub, w którym można przejść i przyjrzeć się implementacji języka, a nawet pobrać kompilator o otwartym kodzie źródłowym. Wszystkie narzędzia firmy Intel, nasze oferty produktów w wersji beta, są również dostępne bezpłatnie dla każdego, z którymi może się bawić i pobierać. Mamy również dostępną chmurę programistyczną, w której ludzie nie muszą niczego pobierać ani instalować, mogą po prostu napisać kod i zacząć korzystać ze wszystkich narzędzi, o których rozmawialiśmy.

P: C++ jest wydajny i stosunkowo prosty, ale wszyscy wiemy, że się starzeje, rozwój jest powolny, jest zbyt wielu interesariuszy, więc wszystko spowalnia. To oczywiście nie miałoby miejsca w przypadku DPC++. Miałbyś znacznie szybsze iteracje i aktualizacje?

Myślę, że trafiłeś w bardzo, bardzo ważny dla nas punkt, którym jest szybka ewolucja, która nie jest spowalniana przez standardy. Tak więc, chcemy prowadzić nasze dyskusje otwarcie ze standardem, więc jest sposób na zapoznanie się ze standardami, ale chcemy też zrobić to szybko.

Języki działają najlepiej, gdy są współprojektowane przez użytkowników i realizatorów, w miarę ewolucji architektur. Naszym celem jest naprawdę szybkie iteracyjne projektowanie kodu, w którym ćwiczymy różne rzeczy, znajdujemy najlepszy sposób na robienie rzeczy i czynimy je standardowymi. Tak więc bezwzględnie szybka iteracja to duży cel.

P: Jedno pytanie zadane przez niektórych moich kolegów (prawdopodobnie możesz zrozumieć, że są nieco zaniepokojeni otwartością na wszystko, co pochodzi z dużej korporacji): Czy DPC++ zawsze pozostanie otwarty dla wszystkich użytkowników i dostawców?

Absolutnie! Specyfikacja jest sporządzona na licencji Creative Commons. Każdy może użyć specyfikacji, wziąć ją i rozwidlić, jeśli chce, i ewoluować. Chcę podkreślić, że nie wszystkie elementy oneAPI są typu open source, ale jesteśmy na dobrej drodze, aby prawie wszystkie elementy były open source. Wszystko to każdy może uchwycić i wykorzystać – jest to dostępne do wdrożenia.

Codeplay, która jest firmą z Wielkiej Brytanii, ogłosiła implementację Nvidii DPC++ i naprawdę zachęcamy wszystkich dostawców sprzętu i oprogramowania do wykonania swojego portu. Jesteśmy w wyjątkowym momencie w branży, w którym akceleratory stają się powszechne dla wielu dostawców. Kiedy dzieje się to w historii, kiedy jest tylko jeden dostawca, ich język dominuje. Branża oprogramowania wymaga standardowego rozwiązania i wielu dostawców.

To, co próbujemy tutaj zrobić, to to, co zrobiliśmy około dwie i pół dekady temu z OpenMP, gdzie istniało wiele języków równoległych, ale żaden naprawdę nie dominował. Wzięliśmy to wszystko i ujednolicliśmy w standard, który teraz, 25 lat później, jest sposobem programowania dla HPC.

P: Czy słuszne byłoby stwierdzenie, że w DPC++ w ciągu najbliższych kilku lat nastąpi duża ewolucja? A co z tensorami, co z pojawieniem się nowego sprzętu?

Tak, absolutnie, masz rację. Musimy ewoluować język, aby obsługiwać nowy sprzęt, który się pojawia. Taki jest cel szybszej iteracji. Inną kwestią, którą chcę podkreślić, jest to, że projektujemy Data Parallel C++, aby można było również podłączyć rozszerzenia specyficzne dla architektury, jeśli chcesz.

Tak więc, chociaż jest to standardowy język, który chcemy uruchomić w wielu architekturach, zdajemy sobie również sprawę, że czasami publiczność, bardzo ważna publiczność, potrzebuje maksymalnej możliwej wydajności. Mogą chcieć zagłębić się w programowanie bardzo niskopoziomowe, które niekoniecznie będzie przenośną architekturą. Budujemy rozszerzenia i mechanizmy, dzięki którym możesz mieć rozszerzenia dla tensorów i tak dalej, co byłoby specyficzne dla architektury.

P: Jak dużą kontrolę nad kodem wygenerowanym dla sprzętu może mieć programista? Jaką kontrolę mogą mieć nad zarządzaniem pamięcią między systemem a różnymi akceleratorami?

Zapożyczamy koncepcję buforów z SYCL, które dają użytkownikowi bardzo wyraźną kontrolę nad pamięcią, ale oprócz tego dodajemy również pojęcie pamięci zunifikowanej . Naszym celem jest zapewnienie programiście poziomu kontroli, którego potrzebuje, nie tylko do zarządzania pamięcią, ale także do generowania szybkiego kodu. Niektóre z rozszerzeń, które dodajemy w SYCL to podgrupy, redukcje, potoki i tak dalej. To pozwoli Ci wygenerować znacznie lepszy kod dla różnych architektur.

P: Interesującą kwestią jest dystrybucja oneAPI dla Pythona — firma Intel wymieniła konkretnie NumPy, SciPy, SciKit Learn. Jestem ciekawy wzrostu wydajności i korzyści w zakresie produktywności, które można odblokować za pomocą oneAPI. Czy masz jakieś dane na ten temat?

To doskonałe pytanie. Wspieramy ten ekosystem. Dlaczego Python miałby używać akceleratora? Ma wydobyć wydajność z bibliotek matematycznych, analitycznych. To, co robimy, to „hydraulika” NumPy, SciPy, SciKit Learn itp., abyśmy mogli uzyskać dobrą wydajność, wykorzystując biblioteki, które mamy na to. Domyślna implementacja NumPy, SciPy, SciKit Learn i tak dalej, w porównaniu z tą, która jest prawidłowo przygotowana za pomocą zoptymalizowanych pakietów natywnych, może przynieść bardzo, bardzo duże korzyści. Widzieliśmy zyski rzędu 200x, 300x itd.

Naszym celem w Pythonie jest osiągnięcie rozsądnego ułamka, w granicach 2x, może w granicach 80% wydajności kodu natywnego. Dzisiejszy stan jest taki, że często jesteś 10 razy lub więcej. Chcemy naprawdę wypełnić tę lukę, wykonując wszystkie zadania o wysokiej wydajności, abyś był w czynniku 2, a właściwie znacznie wyższym.

P: O jakich typach sprzętu mówimy? Czy programiści mogliby uwolnić ten potencjał na zwykłej stacji roboczej, czy też wymagałoby to czegoś nieco mocniejszego?

Nie, byłoby wszędzie. Jeśli pomyślisz o tym, skąd pochodzi zysk, zrozumiesz. Zwykłe biblioteki Pythona nie wykorzystują żadnych możliwości wirtualizacji procesorów. Nie używają żadnej z funkcji wielordzeniowych procesorów. Nie są zoptymalizowane, system pamięci i wszystko, co nie jest zoptymalizowane. Tak więc sprowadza się to do mnożenia macierzy, które zostało napisane przez naiwnego programistę i skompilowane przez kompilator bez żadnej optymalizacji, a następnie porównać to z tym, co ekspert pisze w kodzie asemblera. Porównując te dwa, możesz zobaczyć zyski rzędu kilku-100 razy, aw świecie Pythona w zasadzie tak się dzieje.

Interpretery Pythona i standardowe biblioteki są tak wysokopoziomowe, że kod, który otrzymujesz, staje się bardzo, bardzo naiwnym kodem. Kiedy odpowiednio ją zgłębisz za pomocą zoptymalizowanych bibliotek, uzyskasz ogromne korzyści. Laptop ma już od dwóch do sześciu lub ośmiu rdzeni procesorów, są wielowątkowe i mają całkiem przyzwoite możliwości wektoryzacji, może to 256, może 512. Tak więc w laptopach i stacjach roboczych jest dużo wydajności. Kiedy skalujesz to do GPU, gdy masz dostępną grafikę, możesz sobie wyobrazić, skąd pochodzą zyski.

Jeśli spojrzysz na naszą zintegrowaną grafikę, również stają się bardzo wydajne. Jestem pewien, że widzieliście Ice Lake Gen 11, gdzie zintegrowana grafika jest znacznie lepsza niż w poprzedniej generacji. Możesz zobaczyć, skąd pochodzą korzyści, nawet na laptopach.

P: A co z dostępnością DevCloud? Jeśli dobrze pamiętam, w tej chwili można z niego korzystać za darmo dla wszystkich, ale czy tak pozostanie po tym, jak w przyszłym roku zdobędziesz złoto?

To dobre pytanie. W tym momencie będę szczery, nie znam odpowiedzi. Naszą intencją w tym momencie jest, aby była wolna na zawsze. To jest dla rozwoju, do zabawy, i jest tam dużo koni mechanicznych, więc ludzie mogą faktycznie biegać.

P: Więc nie miałbyś nic przeciwko, gdybyśmy poprosili kilka tysięcy programistów, aby spróbowali?

Och, absolutnie nie. Chcielibyśmy, żeby tak się stało!

Mogę podsumować to, co staramy się zrobić. Po pierwsze, jesteśmy bardzo, bardzo podekscytowani oneAPI. Nadszedł czas, aby pojawiło się rozwiązanie od wielu dostawców, ponieważ na rynku dostępnych jest obecnie wielu dostawców. Jeśli spojrzysz na naszą linię procesorów, a nie tylko na nadchodzące procesory graficzne, coraz mocniejsze zintegrowane procesory graficzne i naszą mapę drogową FPGA, jest to ekscytujący czas na zbudowanie standardu dla tego wszystkiego. Naszym celem jest produktywność, wydajność i infrastruktura branżowa, aby można było na nich budować.

Jeśli chodzi o trzy grupy odbiorców, o których mówiłem, twórcy aplikacji mogą z łatwością korzystać z rzeczy, ponieważ są już dostępne. Dostawcy sprzętu mogą skorzystać ze stosu oprogramowania i podłączyć nowy sprzęt, podczas gdy dostawcy narzędzi i języków mogą z niego łatwo korzystać. Intel nie jest w stanie zbudować wszystkich języków i wszystkich narzędzi na świecie, więc jest to infrastruktura typu open source, z której inni mogą bardzo łatwo korzystać i na której można budować.