Jak dojrzały jest projekt naukowego języka komputerowego „Julia”?

Rozważam naukę nowego języka do wykorzystania w projektach modelowania numerycznego / symulacyjnego, jako (częściowego) zamiennika dla C ++ i Pythona, którego obecnie używam. Natknąłem się na Julię , co brzmi trochę perfekcyjnie. Jeśli zrobi wszystko, co twierdzi, mógłbym go użyć do zastąpienia zarówno C ++, jak i Pythona we wszystkich moich projektach, ponieważ może on uzyskiwać dostęp do kodu biblioteki naukowej wysokiego poziomu (w tym PyPlot), a także uruchamiać pętle z prędkością podobną do C. Korzystałbym również z takich rzeczy, jak właściwe coroutines, które nie istnieją w żadnym innym języku.

Jest to jednak stosunkowo nowy projekt, obecnie w wersji 0.x, i znalazłem różne ostrzeżenia (opublikowane w różnych datach w przeszłości), że nie jest on całkiem gotowy do codziennego użytku. W związku z tym chciałbym teraz uzyskać informacje na temat statusu projektu (luty 2014 r. Lub za każdym razem, gdy zostanie opublikowana odpowiedź), aby pomóc mi ocenić, czy osobiście powinienem rozważyć poświęcenie czasu na naukę tego języka na tym etapie.

Byłbym wdzięczny za odpowiedzi, które koncentrują się na konkretnych istotnych faktach dotyczących projektu Julii ; Mniej mnie interesują opinie oparte na doświadczeniu z innymi projektami.

W szczególności komentarz Geoffa Oxberry'ego sugeruje, że API Julii wciąż jest w ciągłym ruchu, wymagając aktualizacji kodu, gdy się zmienia. Chciałbym dowiedzieć się, w jakim stopniu tak jest: które obszary interfejsu API są stabilne, a które prawdopodobnie się zmienią?

Wydaje mi się, że zazwyczaj robiłbym głównie algebrę liniową (np. Rozwiązywanie problemów własnych), numeryczną integrację ODE z wieloma zmiennymi i wykreślanie przy użyciu PyPlot i / lub OpenGL, a także niskopoziomowe łamanie liczb w stylu C (np. Dla symulacji Monte Carlo ). Czy system biblioteczny Julii jest w pełni rozwinięty w tych obszarach? W szczególności, czy interfejs API jest mniej lub bardziej stabilny dla tego rodzaju działań, czy też odkryłbym, że mój stary kod miałby tendencję do psucia się po aktualizacji do nowej wersji Julii?

Wreszcie, czy są jeszcze jakieś kwestie, które warto rozważyć przy podejmowaniu decyzji, czy w tej chwili wykorzystać Julię do poważnej pracy?

Julia w tym momencie (maj 2019, Julia v1.1 z v1.2 wkrótce wyjdzie) jest dość dojrzała do naukowego przetwarzania. Wersja 1.0 oznaczała koniec corocznego łamania kodu . Dzięki temu wiele naukowych bibliotek komputerowych miało czas na rozwój bez zakłóceń. Szeroki przegląd pakietów Julii można znaleźć na pkg.julialang.org .

W przypadku podstawowych obliczeń naukowych biblioteka DifferentialEquations.jl do równań różniczkowych (ODE, SDE, DAE, DDE, symulacje Gillespie itp.), Flux.jl dla sieci neuronowych oraz biblioteka JuMP do programowania matematycznego (optymalizacja: liniowa, kwadratowa, mieszane liczby całkowite itp.) są trzema podstawami naukowego ekosystemu komputerowego. W szczególności biblioteka równań różniczkowych jest znacznie bardziej rozwinięta niż w innych językach, a duży zespół programistów implementuje funkcje takie jak integratory EPIRK , Runge-Kutta-Nystrom , równanie różniczkowe sztywne / różniczkowo-algebraiczne orazCzas adaptacyjny równanie różniczkowe sztywny stochastyczny integratorów, wraz z wieloma innymi dodatkami, jak analizy wrażliwości sprzężone , DSL reakcji chemicznej , macierz wolna Newton Kryłowa i zgodności GPU pełna (wolny transfer danych) po treningu nerwowych równań różniczkowych , wszystkie z fantastyczne wyniki testów (zastrzeżenie: jestem głównym programistą).

Rzeczą nieco zadziwiającą w dojrzałym ekosystemie Julii jest jego kompozycyjność. Zasadniczo, gdy ktoś buduje ogólną funkcję biblioteki, taką jak w DifferentialEquations.jl, możesz użyć dowolnego typu AbstractArray / Number do wygenerowania nowego kodu w locie. Na przykład istnieje biblioteka do propagacji błędów ( Measurements.jl ), a po umieszczeniu jej w solverie ODE automatycznie kompiluje nową wersję solvera ODE, która wykonuje propagację błędów bez próbkowania parametrów . Z tego powodu niektóre funkcje nie mogą być udokumentowane, ponieważ kod funkcji generuje się sam, dlatego należy pomyśleć o składzie biblioteki.

Jednym ze sposobów najbardziej przydatnego składu jest algebra liniowa. Na przykład solwery ODE pozwalają ci określić jac_prototype, pozwalając ci podać typ jakobianu, który będzie używany wewnętrznie. Oczywiście nie ma rzeczy w LineraAlgebra biblioteki standardowej jak Symmetrici Tridiagonalmożna użyć tutaj, ale biorąc pod uwagę użyteczność composibility w typie algorytmów generycznych, ludzie już poszedł i zbudowany całych bibliotek typu array. BandedMatrices.jl i BlockBandedMatrices.jl to biblioteki, które definiują (blokowe) pasmowe typy macierzy, które mają szybkie luprzeciążenia, co czyni je dobrym sposobem na przyspieszenie rozwiązania sztywnych dyskretyzacji MOL układów równań różniczkowych cząstkowych. PDMats.jlpozwala na specyfikację dodatnio określonych macierzy. Elemental.jl pozwala zdefiniować rozproszony rzadki jakobian. CuArrays.jl definiuje tablice na GPU. Itp.

Następnie masz wszystkie swoje typy liczb. Unitful.jl wykonuje sprawdzanie jednostek w czasie kompilacji, więc jest to biblioteka jednostek bez narzutów. DoubleFloats.jl to szybka biblioteka o wyższej precyzji, wraz z Quadmath.jl i ArbFloats.jl . ForwardDiff.jl to biblioteka do automatycznego różnicowania w trybie do przodu, która wykorzystuje arytmetykę liczb podwójnych. I mogę nadal wymieniać je. I tak, możesz wrzucić je do wystarczająco ogólnych bibliotek Julii, takich jak DifferentialEquations.jl, aby skompilować wersję specjalnie zoptymalizowaną dla tych typów liczb. Nawet coś takiego jak ApproxFun.jlktóry działa jako obiekty algebraiczne (jak Chebfun), współpracuje z tym ogólnym systemem, umożliwiając określenie PDE jako ODE na skalarach w przestrzeni funkcji.

Biorąc pod uwagę zalety kompozycyjności i sposób, w jaki typy mogą być używane do generowania nowego i wydajnego kodu na ogólnych funkcjach Julii, wiele pracy poświęcono wdrożeniu podstawowych funkcji obliczeń naukowych w czystej Julii. Optim.jl do optymalizacji nieliniowej, NLsolve.jl do rozwiązywania systemów nieliniowych, IterativeSolvers.jl do iteracyjnych solverów systemów liniowych i systemów eigensystem, BlackBoxOptim.jl do optymalizacji czarnych skrzynek itp. Nawet biblioteka sieci neuronowej Flux.jl używa po prostu CuArrays. jl automatyczna kompilacja kodu do GPU dla jego możliwości GPU. Ta kompozycyjność była rdzeniem tego, co stworzyło neuronowe równania różniczkowe w DiffEqFlux.jl. Probabilistyczne języki programowania, takie jak Turing.jl, są teraz dość dojrzałe i korzystają z tego samego podstawowego narzędzia.

Ponieważ biblioteki Julii są tak zasadniczo oparte na narzędziach do generowania kodu, nie powinno dziwić, że wokół generowania kodu jest wiele narzędzi. System rozgłoszeniowy Julii w locie generuje połączone jądra, które są przeciążone przez typy macierzy, zapewniając wiele wyżej wymienionych funkcji. CUDAnative.jl pozwala na kompilację kodu Julii do jądra GPU. ModelingToolkit.jl automatycznie usuwa cukier z AST w symboliczny system do przekształcania kodu matematycznego. Cassette.jlpozwala „dogonić” istniejącą funkcję innej osoby, używając reguł, aby zmienić jej funkcję przed czasem kompilacji (na przykład: zmień wszystkie ich alokacje tablic na statyczne alokacje tablic i przenieś operacje do GPU). Jest to bardziej zaawansowane narzędzie (nie oczekuję, że wszyscy zajmujący się obliczeniami naukowymi przejmą bezpośrednią kontrolę nad kompilatorem), ale w ten sposób powstaje wiele narzędzi nowej generacji (a raczej, jak same funkcje piszą).

Jeśli chodzi o paralelizm, wspomniałem o GPU, a Julia ma wbudowaną wielowątkowość i przetwarzanie rozproszone . Wielowątkowość Julii wkrótce będzie wykorzystywać architekturę środowiska uruchomieniowego zadań równoległych (PARTR), która umożliwia automatyczne planowanie zagnieżdżonej wielowątkowości . Jeśli chcesz korzystać z MPI, można po prostu użyć MPI.jl . A potem, oczywiście, najłatwiejszym sposobem na wykorzystanie tego wszystkiego jest po prostu użycie konfiguracji typu AbstractArray w celu użycia równoległości w swoich operacjach.

Julia ma również podstawowy ekosystem, którego można oczekiwać od języka ogólnego przeznaczenia używanego w zastosowaniach naukowych. Ma Juno IDE z wbudowanym debuggerem z punktami przerwania , ma Plots.jl do tworzenia wszelkiego rodzaju wykresów. Przydatne jest również wiele konkretnych narzędzi, takich jak Revise.jl automatycznie aktualizuje funkcje / bibliotekę po zapisaniu pliku. Masz swoją DataFrames.jl , biblioteki statystyk itp. Jedną z najpiękniejszych bibliotek jest w rzeczywistości Distribution.jl, która pozwala pisać ogólne algorytmy dla dystrybucji (na przykład:rand(dist)pobiera losową liczbę wszystkich przekazanych dystrybucji), i istnieje cały ładunek dystrybucji jednowymiarowych i wielowymiarowych (i oczywiście wysyłanie odbywa się w czasie kompilacji, dzięki czemu wszystko to jest tak szybkie, jak zakodowanie na stałe funkcji specyficznej dla dystrybucji). Istnieje wiele narzędzi do obsługi danych , serwerów WWW itp., Które nazywacie. W tym momencie jest na tyle dojrzały, że jeśli istnieje podstawowa rzecz naukowa i można się spodziewać, że będzie istnieć, wystarczy, że przeszukujesz ją za pomocą .jl lub Julii i pojawi się.

Na horyzoncie jest kilka rzeczy, o których należy pamiętać. PackageCompiler chce budować pliki binarne z bibliotek Julii i ma już pewne sukcesy, ale wymaga dalszego rozwoju. Makie.jl to cała biblioteka do drukowania z akceleracją GPU z interaktywnością, i wciąż wymaga trochę pracy, ale naprawdę chce stać się główną biblioteką plotowania w Julii. Zygote.jl to biblioteka automatycznego różnicowania między źródłami, która nie ma problemów z wydajnością AD opartego na śledzeniu (Flux's Tracker, PyTorch, Jax), i który chce działać na wszystkich czystych kodach Julii. Itp.

Podsumowując, można znaleźć dużo ruchu w wielu miejscach, ale w większości obszarów jest już solidna, dojrzała biblioteka. Nie jest już w miejscu, w którym pytasz „czy zostanie adoptowany?”: Julia została adoptowana przez wystarczającą liczbę osób (miliony pobrań), aby mieć siłę, by pozostać na zawsze. Ma naprawdę fajną społeczność, więc jeśli chcesz po prostu strzelać do wiatru i rozmawiać o obliczeniach równoległych lub równaniach różniczkowych numerycznych, niektóre z najlepszych pokojów rozmów na ten temat znajdują się w Julialang Slack . Czy to jest język, którego powinieneś się nauczyć, jest osobistym pytaniem, i czy jest to właściwy język dla twojego projektu, jest pytaniem technicznym, a te są różne. Ale czy jest to język, który dojrzał i ma poparcie dużej, spójnej grupy programistów? To wydaje się być twierdzącym tak.

Jeśli nie, to czy można podać przybliżony rząd wielkości, na ile powinienem czekać przed ponownym rozważeniem?

Moje przybliżone, uporządkowane według wielkości oszacowanie, ile czasu zajmuje dojrzałość języków nauki obliczeniowej, wynosi około dekady.

Przykład 1: SciPy rozpoczęło się w 2001 roku. W 2009 roku wydano Scipy 0.7.0, a integrator ODE miał interfejs do VODE (co odpowiada ode15smniej więcej; ode15sjest oparty na NDF, VODE to zależnie od BDF / Adams-Bashforth). W SciPy 0.10.0 interfejs do dopri5, który jest w przybliżeniu odpowiednikiem MATLAB ode45, metody czwartego rzędu Runge-Kutta zwykle wprowadzanej jako pierwsza praktyczna metoda integracji numerycznej dla studentów. SciPy 0.10.0 zostało wydane w grudniu 2011 r. I zajęło im około 10 lat, aby włączyć funkcję MATLAB wprowadzoną do każdego licencjata inżynierskiego, którego znam.

Przykład 2: Mathworks został założony w 1984 roku. W pierwszym wydaniu użyli portu LAPACK do C o nazwie JACKPAC (od Jacka Little'a, inżyniera MathWorks, który to napisał). Nie zastąpili go LAPACK aż do 2000 roku.

Julia może zająć mniej czasu, ale szacuję, że około 10 lat od założenia do głównego nurtu. (Minęło już około roku; może więc 9-10 lat?)

Czy system biblioteczny Julii jest w pełni rozwinięty w tych obszarach? W szczególności, czy interfejs API jest mniej lub bardziej stabilny dla tego rodzaju działań, czy też odkryłbym, że mój stary kod miałby tendencję do psucia się po aktualizacji do nowej wersji Julii?

Nie używam Julii, więc weź to, co mówię, z odrobiną soli, ponieważ widziałem, jak Jeff Bezanson wygłaszał prezentacje na temat Julii. Odchylili się do tyłu, aby ułatwić łączenie i używanie bibliotek z C, Python i Fortran. Jeśli nie możesz znaleźć biblioteki Julii, która robi to, co chcesz, napisz podkładkę Julii dla biblioteki w bardziej ustalonym języku. W związku z tym nie sądzę, że brak bibliotek będzie problemem. Myślę, że problemem będzie upewnienie się, że zmiany w podstawowych funkcjach językowych nie ugryzą cię w dupę. Jeśli spojrzysz na kamienie milowe w repozytorium Julii Git, zobaczysz, że znacznik „breaking” jest używany dość często (12 razy w wersji 0.2, 5 razy w wersji 0.3). Dla mnie sugeruje to, że język podstawowy wciąż się rozwija, dlatego waham się teraz go używać.

EDYCJA: Aurelius porusza dobrą sprawę:

Co sprawia, że ​​zakładasz, że Julia kiedykolwiek stanie się głównym nurtem, a nie umrze w zapomnieniu, jak wiele innych języków? SciPy / numpy miał / ma poparcie stale rosnącej społeczności python, której Julia nie ma.

W pierwotnej odpowiedzi postanowiłem uniknąć pytania „Czy Julii uda się zostać głównym nurtem?” tak dużo jak to możliwe. Upadek jest łatwy; sukces jest trudny. Myślę, że najlepsze porównanie Julii to techniczne języki obliczeniowe, takie jak MATLAB, R i Octave. Języki HPC (Chapel, Fortress, UPC itp.) Mają węższą grupę odbiorców niż techniczne języki komputerowe, a języki ogólnego przeznaczenia (C, Python, C ++ itp.) Mają szerszą grupę odbiorców niż techniczne języki komputerowe.

Myślę, że coś, co pomaga Julii, to projektowanie pod kątem wydajności bez poświęcania ekspresji. Julia jest znacznie bardziej konkurencyjna w przypadku skompilowanych języków, takich jak C, niż MATLAB, R, a nawet Python. Ten cel projektowania jest także funkcją, która może przyciągać ludzi z istniejących języków, takich jak:

• Ludzie, którzy dbają wiele o wydajności i pochodzą z języków takich jak C i Fortran, ale są gotowi poświęcić maleńki kawałek wydajności (może być czynnikiem 2ish), aby przejść od skompilowany języka do mniejszej liczby linii języku interpretowanym (wraz z REPL dla szybszy rozwój i testowanie).
• Ludzie, którym zależy na wysokiej wydajności i pochodzą z języków takich jak Python, R i MATLAB, ale chcą większej wydajności. Jeśli chodzi o wykonanie, czysty Python, czysty MATLAB i czysty R są wolne. Programiści w tych językach starali się pakować biblioteki w języki skompilowane, ale nie można zawijać wszystkiego, a w pewnym momencie język podstawowy spowolni. Rdzeń Julia jest szybszy, co pozwala szybciej robić więcej nauki.
• Ludzie, którym zależy na wolnym oprogramowaniu. Julia jest interpretowana i darmowa (podobnie jak Python, Octave itp.); MATLAB nie jest.

Julia próbuje również ułatwić paralelizm; Nie czuję się zbyt dobrze wykwalifikowany, aby rozwinąć tę kwestię i nie sądzę, że to główny nurt języka, ale myślę, że jest to zaletą, nad którą pracują i mam nadzieję, że inni mogą rzucić na to światło.

Jednak nawet ze względu na swoje zalety techniczne, twórcy języków muszą wykonać zadanie, aby promować język i ewangelizować. Jeff Bezanson, Alan Edelman, Stephen Karpinski i Viral Shah bardzo ciężko pracują, aby język odniósł sukces. Alan Edelman ma głębokie powiązania ze społecznością obliczeniową i wcześniej pracował nad projektami na poziomie językowym (zwłaszcza rozszerzenie Star-P do MATLAB). Jeff Bezanson od jakiegoś czasu organizuje konferencję, aby promować Julię wśród informatyków i inżynierów. W MIT wykonali dobrą robotę, rekrutując studentów i pracowników (zwłaszcza Stevena G. Johnsona) do pomocy, dodając biblioteki do Julii. Mają artykuł w Wired i udało im się zdobyć artykuł w Wikipedii dla siebie, wszystko po zaledwie roku. Repozytorium Git ma tysiące gwiazd, setki widelców, i setki zegarków, więc według standardów open source ich projekt odniósł sukces. Myślę, że do tej pory zrobili wszystkie właściwe rzeczy, więc jest to kwestia utrzymania tego wysiłku i budowania społeczności. Nadal mogą ponieść porażkę, ale dotarcie tak daleko sugeruje mi, że mają rozsądną szansę na sukces.

Wierzę, że Julia jest warta nauki. Użyłem go do stworzenia kilku badań kodów elementów skończonych i wyprodukowania ich bardzo szybko. Byłem bardzo zadowolony z mojego doświadczenia.

Julia umożliwiła mi przepływ pracy, który trudno mi osiągnąć w przypadku innych języków. Możesz go używać jako języka prototypowego, takiego jak MATLAB, ale w przeciwieństwie do MATLAB, gdy masz działający kod i przechodzisz kolejne iteracje profilowania, aby go przyspieszyć, zastępowanie punktów aktywnych kodem C jest bezbolesne. Uczyniono interfejs z C (i Pythonem) priorytetem w projektowaniu.

Tak więc język umożliwił mi bardzo szybkie przejście od moich formuł matematycznych do kodu funkcjonalnego, a następnie z kodu funkcjonalnego do kodu o wysokiej wydajności. Myślę, że ta cecha Julii jest podkreślona, ​​ale dodaje ogromnej wartości.

W wielu przypadkach uzyskałem wydajność C (w porównaniu do własnego kodu C) w ciągu kilku godzin po utworzeniu funkcjonalnego kodu elementu skończonego. Do tej pory, jeśli używam tylko funkcji Julii, zwykle osiągam ~ 3X wolniej niż C. Następnie zastępuję punkty aktywne funkcjami C (Julia jest wyposażona w profiler próbkowania stosu, aby pomóc je zidentyfikować). Często wymaga to tylko zastąpienia szkodliwych wierszy kodu „ccall”, a Julia obsługuje wszelkie rozkazy.

Myślę, że głównymi rzeczami, których obecnie brakuje Julii, dlatego waham się nad rozważeniem tego w przypadku większych projektów, to brak w pełni obsługiwanego debugera i słaba obsługa kreślenia (teraz najlepszym rozwiązaniem w kreśleniu jest właściwie interfejs do matplotlib że często miałem przerwę). Natychmiastowa informacja zwrotna na temat kodu jest naprawdę ważna. Nie wiem też, jak przetrwać bez interaktywnego debugowania, i pod tym względem bardzo rozpieszczają mnie MATLAB i GDB.

Z mojego doświadczenia wynika, że ​​Julia nie jest jeszcze gotowa do (naukowego) codziennego użytku (mówię o ustabilizowanej wersji 0.4 marca 2016 r.). Sam język jest ładny, bogaty w funkcje i spójny; odświeżający krok naprzód zarówno od Matlaba, jak i Pythona. Z pewnością istnieją przypadki, w których Julia jest dobrym wyborem nawet na tym wczesnym etapie. Ale jeśli potrzebujesz niezawodnych i dojrzałych bibliotek naukowych, nie mogę teraz polecić wykonania tej czynności. Główne problemy, które napotkałem to:

• Paczki poza rdzeniem Julii nie są niezawodne. Zrywają się z aktualizacjami, zmieniają się, zastępują, czasem są niekompletne lub po prostu zepsute.
• Funkcje równoległości Julii (imo najbardziej obiecujące funkcje zabójcy Matlaba) są niedojrzałe. Napotkasz błędy segmentacji, wycieki pamięci, awarie i niezadowalającą wydajność. Czasami nie działają dobrze z innymi częściami Julii, na przykład niektórymi rozwiązaniami dla systemów liniowych lub pakietów poza rdzeniem. Choć te funkcje brzmią obiecująco, często mi się nie udaje. Prawie nigdy nie wystarczyło napisać @parallelprzed pętlą for, gdzie teoretycznie powinno.
• Wiele drobiazgów, drobnych błędów i problemów, z którymi można by żyć: niezbyt ładne i czasem błędne ślady stosów wywołań, trochę błędnych historii interpretera, powolne ładowanie pakietów, złe działanie jednego lub drugiego pakietu / funkcji itp. Co mnie zdenerwowało większość to pakiet PyPlot, opakowanie dla matplotlib, obecnie nie ma dla niego alternatywy. To naprawdę wspaniałe, że tam jest i to w większości działa. Ale jeśli chcesz wykreślić dane, przygotuj się na bardzo niską wydajność i problemy.

Wszystko będzie lepiej. Jestem pewien, że pewnego dnia Julia będzie lepsza od Matlaba i Pythona w prawie każdym aspekcie. Są duże szanse, że zostaną opracowane dla niego innowacyjne pakiety. Wygląda na to, że istnieje już duża społeczność. Nawet teraz istnieje wiele pakietów z przypadkami użycia od opencl do serwerów sieciowych. Korzystanie z bibliotek Python lub C jest bardzo łatwe, więc prawdopodobnie nie uderzysz w ścianę pod względem dostępności bibliotek. Wielką siłą Julii będzie łatwość, z jaką można skleić wysoką wydajność z różnych źródeł w nowoczesnym i spójnym języku wysokiego poziomu (patrz odpowiedzi powyżej). Ale jako całość uważam, że nie jest on ani dojrzały ani stabilny, aby można go było produktywnie wykorzystać.