Panama, OpenCL i TornadoVM: Wejście Javy w świat GPU – JVM Weekly vol. 147

1. Panama, OpenCL i TornadoVM: Wejście Javy w świat GPU

Dziś zaczniemy od bombonierki, którą otrzymaliśmy, a którą będę stopniowo rozpakowywał w kolejnych edycjach (proceder, który już tak naprawdę rozpocząłem, prezentując tydzień temu detale dotyczące Projektu Leyden).

JVM Language Summit (JVMLS) to coroczne wydarzenie, które gromadzi śmietankę świata JVM: projektantów języków, twórców kompilatorów i toolingu czy też inżynierów szeroko rozumianego „środowiska uruchomieniowego”, aby omówić bieżący usprawnienia, ale też pomysły na dalszy rozwój JVM. I choć grono gości jest relatywnie wąskie, to już sama komunikacja jest stosunkowo transparentna, ponieważ kolejne wykłady zaczynają powoli spływać, dając nam bardzo interesujący wgląd w prace, również od kuchni. Nie mam tutaj przestrzeni, aby opisywać wszystkie, ale myślę, że w kolejnych edycjach będę przeskakiwał przez kolejne tematy, stopniowo samodzielnie oglądając poszczególne nagrania. Tak jak wspomniałem, mieliśmy okazje porozmawiać już w poprzedniej edycji o Project Leyden, dzisiaj zaś kolejny temat, który wyjątkowo lubię, a o którym rzadko mam okazje wspomnieć – dopasowanie platformy JVM do pracy z GPU.

W swojej prezentacji Java and GPU … are we nearly there yet?, Gary Frost, Architekt z Oracle, przedstawił wnioski dotyczące integracji Javy z GPU, koncentrując się na wyzwaniach i potencjalnych nowych możliwościach rozwoju możliwych do osiągnięcia dzięki wsparciu pracy z procesorami graficznymi. Hardware 101: W przeciwieństwie do tradycyjnych CPU, które posiadają bardziej dziesiątki rdzeni, pojedynczy GPU potrafi dostarczać ich tysiące (zaprojektowane w modelu rdzeń per piksel). GPU jest więc naturalnie zaprojektowane do zarządzania milionami jednoczesnych zadań. Początkowo rdzenie te były głównie używane do cieniowania pikseli w renderingu grafiki, kiedy deweloperzy zauważyli ogromne możliwości obliczeniowe GPU, zaczęły być stosowane w wielu innych zadaniach, w tym w Machine Learning i sztucznej inteligencji. Dotychczasowe podejścia bardzo przystępnie opisuje tekst Programming the GPU in Java, pochodzący jednak jeszcze ze stycznia 2020, a od tamtego czasu sama platforma poszła do przodu.

Z prezentacji Frosta wyłania się znaczenie Projektu Panama. Uznając wcześniejsze wyzwania, w tym ograniczenia samego JVM oraz próby ukrywania złożoności programowania GPU za pomocą API Java (bo to zawsze działa ekh, ekh… RPC), Frost zaproponował bardziej przejrzyste podejście. Wprowadził koncepcję „zestawu narzędzi do akceleracji heterogenicznej”, który jest oparty właśnie na Projekcie Panama, a używać by miał tak zwanego NDRange. Struktura ta pochodzi z frameworku OpenCL, stworzonego do pisania programów, które działają na heterogenicznych platformach składających się z zróżnicowanego hardware, dając abstrakcje nad różnego rodzajami przetwarzania. NDRange to w uproszczeniu zbiór jednostek pracy, który następnie może być w dowolnie rozłożone na dostępne zasoby sprzętowe i przetworzony, a także mogę być łączone w grupy robocze (work-groups) w celu optymalizacji wydajności całego procesu. Abstrakcja ta jest bardzo elastyczna, pozwala programistom na wykorzystanie mocy wielu jednostek obliczeniowych w różnorodnych zadaniach, stąd propozycja dodania jej do JVM.

W dalszej części prezentacji sporo miejsca Frost poświęcił też TornadoVM, które doczekało się swojego własnego, w pełni poświęconego sobie talka: From CPU to GPU and FPGAs: Supercharging Java Applications with TornadoVM, wygłoszonego przez Juan Fumero, twórcę projektu.

TornadoVM to platforma zaprojektowana właśnie po to, aby umożliwić efektywne wykonywanie aplikacji Java na różnorodnych platformach sprzętowych, w tym na GPU, FPGA oraz systemach wielordzeniowych. Przetwarzając bajtkod Java na wspomniany już OpenCL, TornadoVM zapewnia, że aplikacje Java mogą wykorzystywać możliwości obliczeniowe wyspecjalizowanego hardware bez potrzeby wprowadzania modyfikacji specyficznych dla danego sprzętu, oferując programistom spójne i wydajne środowisko dla ich aplikacji. TornadoVM opiera się na integracji z GraalVM, i wykorzystuje jego kompilator JIT, zdolny do przekształcania bajtkodu Java w natywny kod maszynowy. TornadoVM może korzystać z kompilatora JIT GraalVM w swoich procesach translacji, dodatkowo czerpiąc korzyści z zaawansowanych optymalizacji oferowanych przez GraalVM.

Sporo miejsca w prezentacji skupiło się na prezentacji przyszłych planów i roadmapy dla TornadoVM. Aby jeszcze bardziej zwiększyć wygodę używania i wydajność TornadoVM, zespół bada możliwość włączenia gotowych bibliotek od gigantów branży takich jak NVIDIA, AMD i Intel. W tym kontekście godnym uwagi dodatkiem są też „library tasks”, stworzone do prostszego wykonywania wywołań funkcji natywnych. Łącząc się z tematem prezentacji Frosta, integracja z Panamą jest postrzegana jako potencjalne rozwiązanie problemów, takich jak transfer danych między pamięcią heap oraz off-heap oraz lepszą kontrolą nad pracą Garbage Collectora, co ma ułatwić użycie platformy przez frameworki AI. Pojawiły się też idee dzielenia się javowym heapem między CPU a GPU, zapowiedziano też chęć bardzo ścisłą współpracę z Graal Core Team.

To tak na smaka – kolejne prezentacje dopiero spływają, a myślę, że gdzieś w okolicach JDK 21 warto będzie zrobić sobie przegląd materiałów poświęconych virtual threadom – które jak się pewnie domyślacie, były jednym z istotnych tematów na wydarzeniu.

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

2. Spring I/O przynosi zapowiedź Spring AI

Pozostając w temacie rzeczy, które powoli będę rozpakowywał, to w zeszłym tygodniu odbył się Spring I/O. Na razie niestety nie mamy za wiele dostępnych materiałów (poza obowiązkowym recapem Josha Longa), ale niektóre detale już przeciekły do świadomości publicznej, a wśród nich Spring AI. Rozpakujmy sobie, co kryje się pod tą nazwą.

Spring AI to nowy projekt zainicjowany przez Marka Pollacka, który służyć ma jako pomost między zaawansowanymi możliwościami raz już wytrenowanych modeli AI, a typowymi dla Springa wzorcami pisania aplikacji. Centralnym elementem tej integracji jest możliwość płynnej pracy z modelami, zwłaszcza wariantami GPT.

Udział Javy w rynku sztucznej inteligencji zawsze był ograniczony, głównie ze względu na dominację algorytmów C/C++ (na co rozwiązaniem ma być Panama) i przewagę Pythona w ekosystemie ML/AI. Jednak rozwój generatywnej publicznie dostępnych modeli, które umożliwiają interakcję ze wstępnie wytrenowanymi modelami za pośrednictwem protokołu HTTP (jak choćby GPT), znacznie zmniejszył zależność od określonych języków. Ta ewolucja toruje drogę dla języków takich jak Java, aby stały się bardziej widoczne w świecie sztucznej inteligencji. Czerpiąc inspirację z bibliotek takich jak LangChain, LlamaIndex czy Semantic Kernel, projekt Spring AI ma zaoferować podobne doświadczenie AI dla programistów Spring. Całość też ładnie wpasowuje się w trend zarysowany przez poprzednią sekcje, będąc komplementarnym dla uruchamiania modeli na samym JVM.

Projekt Spring AI wprowadza więc wiele funkcji analogicznych do tych w LangChainie. Główne funkcje obejmują wspólny interfejs API dla interakcji modeli AI oraz rozwój „promptów”, które są kluczowe dla komunikacji modeli AI. Dostępne parsery pomagają konwertować surowe odpowiedzi AI na ustrukturyzowane formaty typu POJO. Projekt podkreśla też znaczenie zarządzania danymi wrażliwymi w LLMach, oferując sposoby na ich użycie bez potrzeby dołączania ich w procesie retrenowania modeli. Odbywa się to poprzez ułatwienie integracji z bazami wektorowymi, które ułatwiają pracę z modelami AI.

Projekt podkreśla również koncepcję „łańcuchów”, które umożliwiają generowanie ciągu interakcji AI dla pojedynczego wejścia. Inne kluczowe komponenty obejmują „Pamięć” do przywoływania poprzednich interakcji i „Agentów”, które wykorzystują modele AI do dynamicznego wyszukiwania danych i generowania odpowiedzi. Wygląda to wszystko bardzo ciekawie, i na pewno się pobawię, tak jak ostatnio eksperymentowałem z Semantic Kernelem.

A nieco przy okazji Spring I/O (a tak naprawdę ciut wcześniej), ogłoszono stabilną wersje innego nietypowego, ale bardzo interesującego springowego projektu. W społeczności programistycznej coraz częściej pojawia się bowiem nawoływanie do powrotu do monolitu – chodzi tu jednak o taki monolit wymyślony trochę na nowo. Zwolennicy tego podejścia twierdzą bowiem, że przy użyciu dzisiejszych narzędzi i dobrej modularyzacji jesteśmy w stanie stworzyć codebase posiadający sporą ilość zalet mikroserwisów przy zaskakująco małej ilości jego wad. Zainteresowanych odsyłam do koncepcji Majestatycznego Monolitu autorstwa DHH, a także interesującej serii Modular Monolith: A Primer.

No dobra, ale jak to się ma do tematu Springa? Otóż ostatnio swoją premierę miał projekt Spring Modulith w wersji 1.0, który ma wprowadzić Springa w erę modularnego monolitu. Spring-Modulith to rozwinięcie istniejącego projektu Moduliths (którego zastąpi), ale jeszcze lepiej zintegrowanego z samym Springiem. Bardzo ciekawy jest sam sposób działania całości – zamiast mocno ingerować on w proces budowania, wykorzystuje do weryfikacji projektu testy integracyjne. Działa więc podobnie do ArchUnit – biblioteki, której celem jest właśnie weryfikacja zależności między poszczególnymi modułami, której asercje są zresztą z nim kompatybilne. Magia Modulitha polega jednak na tym, że dzięki znanemu środowisku uruchomieniowemu (aplikacje Spring Boot 3.0) jest w stanie prekonfigurować odpowiednie testy (w tym wspomnianego) ArchUnita – co też czyni. Dzięki temu w łatwy sposób jesteśmy w stanie przetestować, czy jakieś architektoniczne spaghetti nie przemknęło przez Code Review, jeszcze na poziomie budowania aplikacji.

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

3. Release Radar

Grails 6

Tym razem zaczniemy sobie od zapowiedzi nieco spóźnionej, bo samo Grails 6.0 swoją premierę miało już chwilę temu. Ale jak to mówią – lepiej późno niż wcale. Grails to framework do budowy aplikacji internetowych w Groovy’m, a oparty na niezwykle popularnym kiedyś Rails. Tak jak szał na ten framework i całego Ruby’ego nieco przygasł, tak i raczej mało rozpoczyna się nowych projektów w Grailsach. W dalszym ciągu warto przyglądnąć się, co pokazuje nowa wersja frameworka.

Gwiazdą tego wydania jest nowy UI Grails Forge, umożliwiający deweloperom skuteczne zarządzanie projektami napisanymi we frameworku, oferując uproszczone rozpoczęcie projektu, intuicyjną nawigację, walidację w czasie rzeczywistym, wizualne zarządzanie zależnościami i responsywny design. Co więcej, Grails wzmocnił swoje więzi z Micronautem poprzez ułatwienie używania beanów Micronauta w komponentach Grails oraz wykorzystuje klienta HTTP Micronaut do uproszczonych interakcji z REST API. Grails 6 wprowadził JDK 11 jako minimalną wersje, co umożliwia frameworkowi używanie w internalach nowej składni. To jednak nie koniec zmian – plany są już w toku, by w nadchodzącym dużym wydaniu zapewnić płynne przejście do Java 17.

Testcontainers Desktop Free Application

Projekt Testcontainers, od momentu swojego powstania, zawsze borykał się z problemem „co zrobić, żeby, testy startowały szybko”. W ciągu czasu powstało wiele pomysłów na różne funkcje, takie jak stałe porty czy stabilne kontenery wielokrotnego użytku. Chociaż niektóre funkcje zostały wdrożone w ograniczonym zakresie, to jednak do tej pory najlepszym rozwiązaniem tego problemu pozostawała Testcontainers Cloud. Jednak dla większości z nas, która dalej jednak woli odpalać testy lokalnie, a dodatkowo nie jest gotowa płacić za ten przywilej, powstał właśnie Testcontainers Desktop (oryginalnie nazywający się podobno Testcontainers Cloud Desktop).

Wydana wersja oferuje funkcje takie jak ustawianie stałych portów, możliwość zamrażanie kontenerów umożliwiająca ich debugowanie oraz stanowi abstrakcje nad różnymi runtime’ami konteneryzacji, w tym moim ulubionym Podmanem. Jest też swoistą zachętą, osoby, które zdecydują się spróbować dostaną bowiem dostęp do 300-minutowej wersji próbnej Testcontainers Cloud.

Camel 4.0

Dla tych, którzy nie mieli okazji zetknąć się z projektem, Apache Camel to oprogramowanie mocno enterprisowe, oparte na rodzinie wzorców znanych jako Enterprise Integration Patterns – spodziewajcie się dużo XML-a, aczkolwiek sam Camel też się mocno unowocześnił od czasu, kiedy miałem przyjemność go stosować. Ułatwia integrację różnych systemów, umożliwiając im efektywną wymianę danych bez potrzeby tworzenia dedykowanego, powtarzalnego kodu integracyjnego i obsługuje liczne formaty transportu i danych, co czyni go całkiem interesującym narzędziem, jeśli Wasza firma wpada w świat Enterprise.

Apache Camel 4.0 to głównie znana Wam migracja z javax na jakarta, dostosowując się do nowości z Jakarta EE 10, i podbija minimalną wersję Javy do JDK 17 (osoby, które nie mogą dokonać aktualizacji, zmuszeni są do pozostania na wersji Camel 3.x,), eliminuje też obowiązkowe zależności na JAXB. Jest również przystosowany, by integrować się łatwo z Spring Framework 6, Spring Boot 3 oraz Quarkusem 3. Wydanie łączy Camel Core i Camel Spring Boot (co obrazuje kierunek rozwoju) oraz wintegrowuje Camel Karaf jako subkomponent Apache Karaf. Z drugiej strony, dochodzi do kilku deprekacji, jak np. w camel-cdi czy wsparciu dla JUnit 4.

Gradle 8.3

Pojawiła się nowa wersja Gradle 8.3, wprowadził mnóstwo ulepszeń w swojej ostatniej aktualizacji. Godną uwagi zmianą jest optymalizacja kompilacji Java, dzięki użyciu deamonów, które rozgrzewają się po kilku użyciach, co może prowadzić do skrócenia czasu kompilacji nawet o 30%. Po stronie konfiguracji ulepszono pamięć podręczną konfiguracji, aby buforować wyniki fazy konfiguracji, zwiększając wydajność kompilacji.

Kolejnym ulepszeniem jest pełna (wreszcie) obsługa Java 20. Wcześniej, podczas gdy Gradle 8.1 ułatwiał kompilację i testowanie z Javą 20, nie obsługiwał uruchamiania Gradle na tej wersji JDK, co prowadziło do sytuacji gdy niektóre projekty musiały posiadać wcześniejszą wersje JDK tylko na potrzeby build toola. Aktualizacja zawiera również ulepszenia w dla wtyczki CodeNarc oraz ulepszoną obsługę nowych narzędzi Mavena.

Zadowoleni będą też fani Kotlina. Dalsze udoskonalenia dostał Kotlin DSL, zapewniając takie funkcje takie jak automatyczne uzupełnianie i szybki dostęp do dokumentacji. W tym wydaniu Kotlin DSL jest ustawiony jako domyślny dla nowych kompilacji Gradle. Wprowadzono szereg aktualizacji, w tym obsługę kompilatora K2 i użycie funkcji embeddedKotlin() dla wtyczek.

Compose Mulitplatform 1.5.0

A na koniec – Kotlin Multiplatform w edycji UI! Czyli popularny Compose.

Compose Multiplatform 1.5.0, przynosząc stabilizację wersji Desktopowej, przynosząc łatwiejsze testowania interfejsu użytkownika i usprawnioną interoperacyjność ze Swingiem. Wersja iOS została zaś opublikowana jako alfa, doczekując się znaczących ulepszeń, takich jak usprawnione przewijanie, obsługa Dynamic Type, czy lepsza obsługa wyświetlaczy o wysokiej częstotliwości odświeżania. Niestety, chcącym używać wersji webowej radzę jednak uzbroić się w cierpliwość, ponieważ ta pozostaje eksperymentalna. Nowe wydanie opiera się na Jetpack Compose 1.5 i integruje Material Design 3 w wersji 1.1, wprowadzając kilka nowych komponentów, min. DataPicker. Nowe funkcje obejmują zaś uspójnienie kodu komponentów Dialog, Popup i WindowInsets.