{"id":17824,"date":"2024-03-07T11:58:57","date_gmt":"2024-03-07T10:58:57","guid":{"rendered":"https:\/\/vived.io\/?p=17824"},"modified":"2024-03-08T08:03:28","modified_gmt":"2024-03-08T07:03:28","slug":"code-reflection-triton-dalsze-ulepszenia-programowania-dla-gpu-w-javie-jvm-weekly-vol-166","status":"publish","type":"post","link":"https:\/\/vived.io\/pl\/code-reflection-triton-dalsze-ulepszenia-programowania-dla-gpu-w-javie-jvm-weekly-vol-166\/","title":{"rendered":"Code Reflection Triton: Dalsze ulepszenia programowania dla GPU w Javie – JVM Weekly vol. 166"},"content":{"rendered":"\n

1. Nowe JEPy – usprawnienia CDS, Generacyjny ZGC i Markdown w dokumentacji<\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

JEP draft: (draft) Unified storage for application cache (aka „new CDS workflow”)<\/a><\/h3>\n\n\n\n

Rzadko kiedy informuje o JEP-ach na tak wczesnym etapie, ale ten mi si\u0119 szczeg\u00f3lnie spodoba\u0142. „Unified storage for application cache (aka „new CDS workflow)” ma na celu unifikacj\u0119 miejsca przechowywania danych pami\u0119ci podr\u0119cznej aplikacji, b\u0119d\u0105ce now\u0105 iteracj\u0105 mechanizmu Class-Data Sharing. Celem jest rozwini\u0119cie wykorzystania CDS, w tym momencie u\u017cywanego do przechowywania metadanych klas i obiekt\u00f3w sterty, aby mog\u0142o by\u0107 u\u017cywane jako cache dla szerszego zakresu typ\u00f3w danych, takich jak np. metody skompilowane AOT. Planowane jest r\u00f3wnie\u017c uporz\u0105dkowanie sposobu obs\u0142ugi CDS (kt\u00f3ry na przestrzeni lat rozwin\u0105\u0142 si\u0119 w spos\u00f3b ad hoc) poprzez wprowadzenie pojedynczej flag -XX:CacheDataStore<\/code>, kt\u00f3ry okre\u015bla lokalizacj\u0119 magazynu. Pocz\u0105tkowo magazyn b\u0119dzie sk\u0142ada\u0142 si\u0119 z jednego pliku, ale w przysz\u0142o\u015bci mo\u017ce odnosi\u0107 si\u0119 do wielu plik\u00f3w, potencjalnie hierarchicznych.<\/p>\n\n\n\n

Na razie to wszystko co wiemy na tym wczesnym etapie, wi\u0119c szczeg\u00f3\u0142y mog\u0105 si\u0119 jeszcze zmieni\u0107. W dalszym ci\u0105gu daje nam podgl\u0105d na to, w jaki spos\u00f3b w przysz\u0142o\u015bci b\u0119d\u0105 \u0142\u0105czy\u0107 si\u0119 r\u00f3\u017cne mechanizmy usprawniaj\u0105ce cold start aplikacji.<\/p>\n\n\n\n

JEP draft: Deprecate Non-Generational ZGC<\/a><\/h3>\n\n\n\n

Kontynuuj\u0105c temat draft\u00f3w, kolejna z ciekawych nowo\u015bci to „Deprecate Non-Generational ZGC”. Dopiero co do ZGC wprowadzono Generacyjny wariant ZGC, a ju\u017c w tej chwili pojawiaj\u0105 si\u0119 plany na deprekacji wersji niegeneracyjnej, z zamiar usuni\u0119cia jej w przysz\u0142ych wydaniach. G\u0142\u00f3wnym celem jest redukcja koszt\u00f3w utrzymania oraz technicznego d\u0142ugu wynikaj\u0105cego z obs\u0142ugi dw\u00f3ch r\u00f3\u017cnych tryb\u00f3w dzia\u0142ania. Non-Generational ZGC, mimo \u017ce nie zostanie usuni\u0119ty w ramach tego JEP-u i pewnie zostanie z nami na d\u0142u\u017cej, to stanie si\u0119 tym mniej preferowanym trybem, gdy\u017c Generational ZGC, wprowadzony w JEP 439, jest postrzegany jako lepsze rozwi\u0105zanie w wi\u0119kszo\u015bci use cas\u00f3w.<\/p>\n\n\n\n

JEP 467: Markdown Documentation Comments<\/a><\/h3>\n\n\n\n

JEP 467 to za\u015b wreszcie JEP-kandydat, kt\u00f3rego celem jest umo\u017cliwienie pisania dokumentacji JavaDoc w Markdownie, zamiast wy\u0142\u0105cznie w mieszance HTML i tag\u00f3w JavaDoc. Powiedzmy sobie szczerze, Markdown od lat jest rozwi\u0105zaniem, kt\u00f3re kr\u00f3luje je\u015bli chodzi o tworzenie dokumentacji technicznej i de facto sta\u0142 si\u0119 standardem do tego stopnia, \u017ce w zasadzie ka\u017cde IDE czy Code Editor maj\u0105 do niego \u015bwietne wsparcie.<\/p>\n\n\n\n

\"\"
Behind the scenes: Tak naprawd\u0119, do nawet ten newsletter powstaje w Markdownie, i IA Writer. Dodatkow\u0105 ciekawostk\u0105 jest to, \u017ce pisz\u0119 w macierzystym j\u0119zyku i dopiero potem „przechodz\u0119” na angielski – taki flow mi najlepiej dzia\u0142a od lat.<\/figcaption><\/figure>\n\n\n\n

Celem jest oczywi\u015bcie u\u0142atwienie pisania i czytania komentarzy API. Tworzenie dokumentacja to trudny, \u017cmudny proces niezale\u017cnie od wybranego markupu, a konieczno\u015b\u0107 stosowania HTML (ergo j\u0119zyka quasi-XML-owego), kt\u00f3ry jest mniej intuicyjny dla ludzi, nie pomaga. Ostatnimi czasy wida\u0107 trend, \u017ce i cz\u0119\u015bciej generowany z innych j\u0119zyk\u00f3w znacznik\u00f3w bardziej „przyjaznych” dla cz\u0142owieka. Markdown nie do\u015b\u0107 \u017ce jest popularnym j\u0119zykiem znacznik\u00f3w dla prostych dokument\u00f3w, \u0142atwym do czytania, tworzenia i przekszta\u0142cania w HTML, co czyni go idealnym wyborem dla komentarzy dokumentacyjnych, kt\u00f3re zazwyczaj nie s\u0105 skomplikowanymi dokumentami strukturalnymi… i chyba nie chcieliby\u015bmy, \u017ceby si\u0119 takimi sta\u0142y.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Jak to ma dzia\u0142a\u015b w praktyce? Na przyk\u0142adzie komentarza dla metody hashCode<\/code> mo\u017cna zauwa\u017cy\u0107 r\u00f3\u017cnic\u0119 w u\u017cyciu Markdown, gdzie linie zaczynaj\u0105 si\u0119 od \/\/\/<\/code> zamiast tradycyjnego \/** ... *\/<\/code>. HTML nie jest wymagany do wskazania przerwy akapitowej; wystarczy pusta linia. Elementy HTML takie jak <ul><\/code> i <li><\/code> s\u0105 zast\u0119powane przez znaczniki listy punktowanej Markdown, u\u017cywaj\u0105c -<\/code> do wskazania pocz\u0105tku ka\u017cdego elementu listy. Zamiast <em><\/code>, u\u017cywa si\u0119 podkre\u015ble\u0144 (_<\/code>) do wskazania zmiany czcionki, a instancje tagu {@code ...}<\/code> s\u0105 zast\u0119powane przez znaki odwrotnego apostrofu (`) do wskazania czcionki o sta\u0142ej szeroko\u015bci.<\/p>\n\n\n\n

Dawno chyba te\u017c \u017caden z JEP-\u00f3w nie by\u0142 tak mocno dyskutowany na redditcie<\/a>. Opinia spo\u0142eczno\u015bci poza og\u00f3lnym entuzjazmem (bo taki na pewno towarzyszy rozwi\u0105zaniu) ujawnia kilka g\u0142\u00f3wnych obaw. Po pierwsze, wielu uwa\u017ca wym\u00f3g stosowania trzech uko\u015bnik\u00f3w dla komentarzy dokumentacyjnych za niewygodny, sugeruj\u0105c pr\u00f3b\u0119 wypracowania jakiej\u015b bardziej zwi\u0119z\u0142ej notacji – i tu si\u0119 mocno podpisuje, cho\u0107 fakt, \u017ce wszystkie linie maj\u0105 taki sam prefix z drugiej strony wp\u0142ywa na czytelno\u015b\u0107. Dodatkowo, dyskusja porusza obawy dotycz\u0105ce d\u0142ugoterminowej \u017cywotno\u015bci i elastyczno\u015bci takiego wyboru sk\u0142adni (trzech slashy), zastanawiaj\u0105c si\u0119, co stanie si\u0119, je\u015bli nowy j\u0119zyk znacznik\u00f3w zyska na popularno\u015bci w przysz\u0142o\u015bci (w rozmow\u0119 zaanga\u017cowa\u0142 si\u0119 sam Ron Pressler). Wytykany jest te\u017c brak jakiej\u015b sensownej alternatywy dla tag\u00f3w JavaDoc, kt\u00f3re dalej musz\u0105 by\u0107 mieszane z Markdownem w swojej klasycznej formie. Mimo powy\u017cszego feedbacku, odbi\u00f3r jest pozytywny, a bior\u0105c pod uwag\u0119, \u017ce to ju\u017c kandydacki JEP, a nie np. Preview, to nie spodziewam si\u0119 ju\u017c jakich\u015b daleko id\u0105cych zmian.<\/p>\n\n\n

\n
\"\"
Jak ju\u017c wspomnia\u0142em, bardzo lubi\u0119 Markdowna i mam wra\u017cenie, \u017ce mo\u017cliwo\u015b\u0107 u\u017cywania go do pisania dokumentacji sprawi, \u017ce znaczenie mniej wpis\u00f3w b\u0119dzie jako TODO<\/figcaption><\/figure><\/div>\n\n\n

2. Triton – Kolejne podej\u015bcie do programowania na GPU z Project Babylon<\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

A teraz po raz kolejny w tym roku przygl\u0105dniemy si\u0119 projektowi Babylon. Niedawno bowiem ukaza\u0142a si\u0119 publikacja Paula Sandoza Exploring Triton GPU programming for neural networks in Java<\/a>, czyli kolejna pr\u00f3ba wykorzystania Code Reflection do rozepchania si\u0119 \u0142okciami w przestrzeni oko\u0142o-AI.<\/p>\n\n\n\n

Triton to domenowy model programowania i kompilator, kt\u00f3ry umo\u017cliwia programistom pisz\u0105cym w Pythonie tworzenie kodu dzia\u0142aj\u0105cego na procesorach GPU, nawet tym maj\u0105cy niewielkie do\u015bwiadczenie w pracy z GPU i j\u0119zykami programowania specyficznymi dla GPU, takimi jak CUDA. Ukrywa on bowiem przed programistami bazuj\u0105cy na w\u0105tkach model programowania CUDA, co pozwala kompilatorowi Triton lepiej wykorzysta\u0107 sprz\u0119t GPU, na przyk\u0142ad poprzez optymalizacj\u0119 przypadk\u00f3w, kt\u00f3re mog\u0142yby inaczej wymaga\u0107 jawnej synchronizacji. Dodatkowo, dzi\u0119ki abstrakcji Tritona programi\u015bci operuj\u0105 na tensorach zamiast skalarnych warto\u015bci, co znacz\u0105co upraszcza i przyspiesza proces tworzenia kodu na GPU.<\/p>\n\n\n\n

Triton dzia\u0142a jednak z Pythonem, ale i dla Javy okienko transferowe na wykorzystania modelu programowania Triton otwiera si\u0119 dzi\u0119ki Code Reflection, rozwijanej w ramach Project Babylon. Dla przypomnienia Refleksja kodu pozwala na symboliczne reprezentowanie program\u00f3w Java, co umo\u017cliwia ich analiz\u0119 i automatyczn\u0105 transformacj\u0119 na model kodu Triton. Dzi\u0119ki temu programy napisane w Javie mog\u0105 by\u0107 kompilowane do kodu dzia\u0142aj\u0105cego na GPU, podobnie jak to ma miejsce w przypadku Pythona z u\u017cyciem Tritona. Projekt Babylon w tym kontek\u015bcie dzia\u0142a jako most mi\u0119dzy Jav\u0105, a specyficznymi rozwi\u0105zaniami pod GPU, otwieraj\u0105c programistom drzwi do \u015bwiata programowania GPU z wszystkimi jego korzy\u015bciami, takimi jak rozszerzone mo\u017cliwo\u015bci oblicze\u0144 r\u00f3wnoleg\u0142ych w du\u017cej skali.<\/p>\n\n\n\n

Na poziomie technicznym, proces ten zaczyna si\u0119 od utworzenia modelu kodu Java za pomoc\u0105 refleksji kodu, kt\u00f3ry nast\u0119pnie jest analizowany i transformowany w model kodu Triton. W tym procesie nast\u0119puje przypisanie odpowiednich typ\u00f3w do element\u00f3w modelu, co umo\u017cliwia dok\u0142adn\u0105 transformacj\u0119 kodu Java na kod odpowiedni dla GPU, aby wyprodukowa\u0107 form\u0119 podobn\u0105 do Triton MLIR.<\/p>\n\n\n

\n
\"\"
Nasze karty graficzne nie wiedzia\u0142y, jak mia\u0142y dobrze<\/figcaption><\/figure><\/div>\n\n\n

Je\u015bli jeste\u015bcie ciekawi dodatkowych detali, w artykule pojawiaj\u0105 si\u0119 przyk\u0142ady, gdzie na przyk\u0142adzie dodawania wektor\u00f3w pokazano, jak implementacja w Javie mo\u017ce by\u0107 zbli\u017cona do Pythonowej, mimo np. braku przeci\u0105\u017cania operator\u00f3w w Javie. Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w oryginalnej publikacji<\/a>.<\/p>\n\n\n\n

3. Release Radar<\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Quarkus 3.8<\/a><\/h3>\n\n\n\n

Zacznijmy sobie od Ma\u0142yc-Du\u017cych zmian w Quarkusie. Wersja 3.8 zosta\u0142 og\u0142oszony now\u0105 wersj\u0105 Long-Term Support (LTS). A czemu Ma\u0142o-Du\u017ce? Nowa wersja to bezpo\u015brednio kontynuuje ga\u0142\u0105\u017a 3.7 i tym samym nie zawiera \u017cadnych nowych funkcji wychodz\u0105cych poza 3.7, co najwy\u017cej zawiera kilka dodatkowych poprawek, w\u015br\u00f3d kt\u00f3rych warto wymieni\u0107 zaadresowanie CVE-2024-1597 zwi\u0105zanego z sterownikiem JDBC PostgreSQL. Je\u015bli jednak dalej pozostajecie na ostatnim LTS, kt\u00f3rym by\u0142a jeszcze wersja 3.2, to nowe wydanie b\u0119dzie dla Was sporym przeskokiem – ulepszenia OpenTelemetry, wsparcie dla Java 21 (plus minimalna wspierana nowa wersja to teraz JDK 17), wsparcie dla OpenIDConnect i sporo innych usprawnie\u0144.<\/p>\n\n\n\n

Scala 3.4.0<\/a><\/h3>\n\n\n\n

Pawe\u0142 Marks z VirtusLab poinformowa\u0142 o wydaniu nowej wersji Scali – Scala 3.4. W\u015br\u00f3d najwa\u017cniejszych nowo\u015bci w nowym wydaniu z pewno\u015bci\u0105 nale\u017cy wymieni\u0107 stabilizacje wa\u017cnych SIP-\u00f3w:<\/p>\n\n\n\n