Наскільки зрілим є проект з мовних обчислень «Юлія»?

Я розглядаю вивчення нової мови для використання для чисельних / імітаційних моделюючих проектів, як (часткову) заміну для C ++ та Python, якими я зараз користуюся. Я натрапив на Джулію , яка звучить наче ідеально. Якщо він виконує все, на що претендує, я міг би використовувати його для заміни як C ++, так і Python у всіх своїх проектах, оскільки він може отримати доступ до науково-обчислювального коду бібліотеки високого рівня (включаючи PyPlot), а також працювати для циклів зі швидкістю, подібною до C. Я також виграв би від таких речей, як правильні заходи, які не існують ні в одній з інших мов.

Однак, це відносно новий проект, який наразі має версію 0.x, і я виявив різні попередження (розміщені в різні дати в минулому), що він не зовсім готовий для використання у повсякденному режимі. Отже, я хотів би отримати деяку інформацію про стан проекту прямо зараз (лютий 2014 року або щоразу, коли буде опубліковано відповідь), щоб допомогти мені оцінити, чи особисто я повинен розглянути можливість інвестувати час для вивчення цієї мови на цьому етапі.

Я вдячний відповідям, які зосереджуються на конкретних релевантних фактах щодо проекту Юлія ; Мене менше цікавлять думки, засновані на досвіді інших проектів.

Зокрема, коментар Джеффа Оксберрі припускає, що API Julia все ще знаходиться в потоці, і вимагає оновлення коду, коли він змінюється. Я хотів би зрозуміти, наскільки це так: які області API є стабільними, а які, можливо, зміниться?

Я думаю, як правило, я б переважно робив лінійну алгебру (наприклад, розв’язування власних проблем), чисельну інтеграцію ODE з багатьма змінними та побудову графіків за допомогою PyPlot та / або OpenGL, а також стискання чисельних чисел на низькому рівні (наприклад, для моделювання в Монте-Карло ). Чи повністю розвинена бібліотечна система Юлії в цих сферах? Зокрема, чи більш-менш стабільний API для таких видів діяльності, чи я можу виявити, що мій старий код має тенденцію зламатися після оновлення до нової версії Julia?

Нарешті, чи є інші питання, які варто було б розглянути, вирішуючи, чи використовувати Юлію для серйозної роботи в даний час?

Джулія, в цей момент (травень 2019 року, Julia v1.1 з v1.2, який повинен вийти) є досить зрілим для наукових обчислень. Випуск v1.0 означав кінець щорічного злому коду . Зважаючи на це, багато наукових обчислювальних бібліотек встигли просто розростатися без збоїв. Широкий огляд пакетів Julia можна знайти на сайті pkg.julialang.org .

Для основних наукових обчислень - бібліотека DifferentialEquations.jl для диференціальних рівнянь (ODE, SDE, DAE, DDE, моделювання Гіллеспі тощо), Flux.jl для нейронних мереж та бібліотека JuMP для математичного програмування (оптимізація: лінійне, квадратичне, змішане ціле число та ін. програмування) - три основи наукової обчислювальної екосистеми. Бібліотека диференціальних рівнянь, зокрема, набагато розвинена, ніж те, що ви бачили б іншими мовами, з великою командою розробників, що реалізує такі функції, як інтегратори EPIRK , диференціальне рівняння затримки Runge-Kutta-Nystrom , Stiff / Differential-Algebraic та ін.адаптаційні жорсткі стохастичні інтегратори рівняння диференціального рівняння , а також купу інших продуктів, таких як аналіз суміжної чутливості , хімічні реакції DSL , без матриць Ньютона-Крилова та повна сумісність GPU (без передачі даних), з навчанням нейронних диференціальних рівнянь , все з фантастичні результати порівняння (відмова: Я є головним розробником).

Те, що трохи не викликає думки щодо дозрілої екосистеми Юлії, - це її сумісність. По суті, коли хтось будує загальну функцію бібліотеки на зразок функцій DifferentialEquations.jl, ви можете використовувати будь-який тип AbstractArray / Number для створення нового коду на льоту. Так, наприклад, існує бібліотека для розповсюдження помилок ( Measurements.jl ), і коли ви вставляєте її в вирішувач ODE, вона автоматично збирає нову версію вирішувача ODE, яка робить поширення помилок без вибірки параметрів . Через це ви можете не знайти деяких функцій, задокументованих, оскільки код для цих функцій генерується сам, і тому вам потрібно більше подумати про склад бібліотеки.

Один із способів, коли композиція найбільш корисна, - це лінійна алгебра. Наприклад, ODE-розв'язувачі дозволяють вказати jac_prototypeтип, який дає вам тип для якобіан, який буде використовуватися всередині країни. Звичайно , є речі , в стандартній бібліотеці LineraAlgebra , як Symmetricі Tridiagonalви можете використовувати тут, але , з огляду на корисність composibility в загальних алгоритмах типу, люди тепер пішли і побудували цілі бібліотеки типу масиву. BandedMatrices.jl і BlockBandedMatrices.jl - це бібліотеки, які визначають ( блоковані ) типи матричних ліній , що мають швидкі luперевантаження, що робить їх гарним способом прискорити рішення жорстких дискретностей MOL систем парціальних диференціальних рівнянь. PDMats.jlдозволяє конкретизувати позитивно-визначені матриці. Elemental.jl дозволяє визначити розподілений розріджений якобійський. CuArrays.jl визначає масиви на GPU. І т.д.

Тоді у вас є всі ваші типи номерів. Unitful.jl здійснює перевірку одиниць під час компіляції, так що це накладні бібліотеки одиниць. DoubleFloats.jl - це швидка бібліотека з високою точністю, а також Quadmath.jl та ArbFloats.jl . ForwardDiff.jl - це бібліотека для автоматичного розмежування в прямому режимі, яка використовує арифметику подвійного числа. І я можу продовжувати перераховувати це. І так, ви можете кинути їх у досить загальні бібліотеки Julia, як DifferentialEquations.jl, щоб скласти версію, спеціально оптимізовану для цих типів чисел. Навіть щось на зразок ApproxFun.jlяка функціонує як алгебраїчні об'єкти (як Chebfun) працює з цією загальною системою, що дозволяє специфікувати PDE як ODE для скалярів у просторі функцій.

З огляду на переваги комбінованості та те, як типи можна використовувати для створення нового та ефективного коду на загальних функціях Julia, було зроблено багато роботи над тим, щоб реалізувати реалізацію основних наукових обчислювальних функцій в чисту Julia. Optim.jl для нелінійної оптимізації, NLsolve.jl для вирішення нелінійних систем, IterativeSolvers.jl для ітеративних розв'язувачів лінійних систем та власних систем, BlackBoxOptim.jl для оптимізації чорних ящиків тощо. Навіть бібліотека нейронних мереж Flux.jl просто використовує CuArrays. автоматична компіляція коду до графічного процесора jl для його можливостей. Ця сумісність була основою того, що створювало такі речі, як нейронні диференціальні рівняння в DiffEqFlux.jl. Імовірнісні мови програмування, такі як Turing.jl , також зараз досить зрілі і використовують ті ж основні інструменти.

Оскільки бібліотеки Джулії настільки основані на інструментах генерації коду, не дивно, що навколо створення коду існує багато інструментів. Трансляційна система Джулії генерує зліплені ядра, які перевантажуються типами масивів, що дає безліч згаданих вище функцій. CUDAnative.jl дозволяє компілювати код Julia до ядер GPU. ModelingToolkit.jl автоматично знесилює AST в символічну систему для перетворення математичного коду. Cassette.jlдозволяє "перенастроїти" чужу існуючу функцію, використовуючи правила, щоб змінити їх функцію перед часом компіляції (наприклад: змінити всі їх масиви на масиви на статичні розподіли масиву та перемістити операції до GPU). Це більш вдосконалений інструментарій (я не сподіваюся, що всі, хто займається науковими обчисленнями, мають безпосередній контроль над компілятором), але саме так будується багато інструментів нового покоління (а точніше, як самі функції записують).

Щодо паралелізму, я згадав про графічні процесори, а Юлія вбудувала багатопотокові та розподілені обчислення . Багатопоточна редакція Юлії дуже скоро використає архітектуру виконання паралельних завдань (PARTR), яка дозволяє автоматизувати планування вкладених багатопотокових читань . Якщо ви хочете використовувати MPI, ви можете просто використовувати MPI.jl . І звичайно, найпростіший спосіб скористатись цим - просто скористатися настройкою типу AbstractArray, щоб використовувати паралелізм у своїх операціях.

У Юлії також є основна екосистема, яку ви могли б очікувати, мова загального призначення, що використовується для наукових застосувань. У нього Juno IDE із вбудованим налагоджувачем з точками прориву , у нього є Plots.jl для створення всіляких сюжетів. Дуже приємно також багато специфічних інструментів, наприклад Revise.jl автоматично оновлює ваші функції / бібліотеку, коли файл зберігається. У вас є ваші DataFrames.jl , бібліотеки статистики тощо. Однією з найприємніших бібліотек є насправді Distributions.jl, яка дозволяє писати алгоритми, загальні для розподілу (наприклад:rand(dist)приймає випадкове число будь-якого переданого розподілу), і є ціле навантаження одноманітних і багатоваріантних розподілів (і, звичайно, відправка відбувається в час компіляції, що робить це все так само швидко, як жорстке кодування функцією, характерною для розподілу). Є купа інструментів для обробки даних , веб-серверів тощо. На даний момент це вже досить зріло, що якщо є основна наукова річ, і ви сподіваєтесь на її існування, ви просто за допомогою Google .lv або Julia, і вона з’явиться.

Тоді на горизонті слід пам’ятати кілька речей. PackageCompiler прагне створити бінарні файли з бібліотек Julia, і він вже має певні успіхи, але потребує більшого розвитку. Makie.jl - це ціла бібліотека для інтерактивності побудови графіків, прискорених графічним процесором, і їй ще потрібно ще трохи роботи, але вона справді шукає стати головною бібліотекою побудови графіків у Джулії. Zygote.jl - це бібліотека автоматичної диференціації від джерела до джерела, яка не має проблем з продуктивністю AD, що базується на трасування (Flux's Tracker, PyTorch, Jax), і прагне працювати над усіма чистими кодами Julia. І т.д.

На закінчення можна знайти багато руху в багатьох місцях, але в більшості областей вже є міцна дозріла бібліотека. Це вже не місце, де ви запитуєте "чи буде прийнято?": Джулію прийняли достатньо людей (мільйони завантажень), щоб вона мала імпульс назавжди назавжди. У ній дійсно приємна спільнота, тому якщо ви хочете просто захотіти на вітрі та поговорити про паралельні обчислення чи числові диференціальні рівняння, деякі з найкращих чатів для цього знаходяться в « Джуліаланг Слабі» . Чи це мова, яку ви повинні вивчити, це особисте запитання, а чи це правильна мова для вашого проекту - це технічне питання, і вони різні. Але це мова, яка визріла і має підтримку великої послідовної групи розробників? Це, мабуть, є позитивним так.

Якщо ні, чи можна дати приблизну оцінку порядку порядку, скільки часу мені слід чекати, перш ніж розглянути його ще раз?

Приблизна оцінка мого грубого порядку, скільки часу потрібно для визрівання мов обчислювальної науки, становить близько десяти років.

Приклад 1: SciPy розпочався в 2001 році. У 2009 році було випущено Scipy 0.7.0, і інтегратор ODE мав інтерфейс до VODE (що еквівалентно ode15s, приблизно; ode15sна основі NDF, VODE - BDF / Adams-Bashforth, залежно). З SciPy 0.10.0, інтерфейс до dopri5, що приблизно еквівалентний MATLAB ode45, метод Runge-Kutta 4-го порядку, як правило, впроваджується як перший практичний метод чисельної інтеграції для студентів. SciPy 0.10.0 був випущений у грудні 2011 року, і їм знадобилося близько 10 років, щоб включити функцію MATLAB, представлену у всіх інженерних недоградах, які я знаю.

Приклад 2: Mathworks була заснована в 1984 році. У своєму першому випуску вони використовували порт LAPACK до C, названий JACKPAC (за Джеком Літлом, інженером MathWorks, який його написав). Вони не замінили його на LAPACK до 2000 року.

Юлія може зайняти менше часу, але я вважаю, що приблизно 10 років від часу заснування стане мейнстрімом. (Уже минуло рік або близько того; можливо, 9-10 років, тоді?)

Чи повністю розвинена бібліотечна система Юлії в цих сферах? Зокрема, чи більш-менш стабільний API для таких видів діяльності, чи я можу виявити, що мій старий код має тенденцію зламатися після оновлення до нової версії Julia?

Я не використовую Джулію, тому прийміть те, що я кажу, із зерном солі, оскільки я бачив, як тільки Джефф Бенансон виступав з доповідями про Джулію. Вони нахилилися назад, щоб полегшити зв'язок і використання бібліотек C, Python і Fortran. Якщо ви не можете знайти бібліотеку Джулії, яка виконує те, що ви хочете, напишіть пробку Юлії для бібліотеки більш усталеною мовою. Отже, я не думаю, що брак бібліотек буде проблемою. Я думаю, що проблема буде переконатися, що зміни основних мовних особливостей не кусають вас у дупу. Якщо ви подивитеся на основні етапи у репо-ролі Julia Git, то побачите, що тег "ламання" використовується досить небагато (12 разів у випуску 0,2, 5 разів у випуску 0,3). Як мені здається, це говорить про те, що основна мова все ще розвивається, і тому я вагаюся використовувати мову зараз.

EDIT: Аврелій приносить хороший момент:

Що змушує вас припускати, що Джулія коли-небудь фактично стане мейнстримом, а не просто відмирає в невідомості, як і багато інших мов? SciPy / numpy мав / має підтримку постійно зростаючої спільноти пітонів, якої у Юлії немає.

У оригінальній відповіді я вирішив уникнути питання "Чи вдасться Юлії стати мейнстрімом?" так багато, як тільки можливо. Провал легко; успіх важкий. Я думаю, що найкраще порівняння Джулії - з технічними мовами обчислень, такими як MATLAB, R та Octave. Мови HPC (Chapel, Fortress, UPC тощо) мають вузьку аудиторію, ніж мови технічних обчислень, а мови загального призначення (C, Python, C ++ тощо) мають більш широку аудиторію, ніж мови технічних обчислень.

Щось, на мою думку, допомагає Юлії - це дизайн для виконання, не приносячи шкоди виразності. Юлія набагато конкурентоспроможнішає для компільованих мов, таких як C, ніж MATLAB, R або навіть Python. Ця мета дизайну також є функцією, яка може залучити людей з існуючих мов, наприклад:

• Люди, які багато піклуються про продуктивність та походять з таких мов, як C та Fortran, але готові пожертвувати невеликою ефективністю (можливо, коефіцієнтом 2ish), щоб перейти від компільованої мови до меншої кількості рядків інтерпретованої мови (разом із REPL для більш швидкий розвиток та тестування).
• Люди, які піклуються про високу продуктивність та походять з таких мов, як Python, R та MATLAB, але бажають більшої продуктивності. Що стосується виконання, чистий Python, чистий MATLAB і чистий R повільний. Розробники цих мов вийшли зі шляху, щоб обернути бібліотеки в компільовані мови, але ви не можете все обернути, і в якийсь момент основна мова збирається сповільнити вас. Основна Джулія швидша, що дозволяє швидше займатися наукою.
• Люди, які піклуються про вільне програмне забезпечення. Джулія інтерпретована і вільна (так це Python, Octave тощо); MATLAB - ні.

Юлія також намагається полегшити паралелізм; Я не відчуваю страшної кваліфікації розширювати цю точку, і я не думаю, що це головний малюнок мови, але я думаю, що це точка продажу, над якою вони працюють, і я сподіваюся, що інші можуть пролити на це світло.

Однак, навіть маючи технічну заслугу на своїй стороні, творцям мови доводиться виконувати роботу з просування мови та євангелізації. Джеф Безансон, Алан Едельман, Стівен Карпінський та Вірусний Шах дуже наполегливо працюють над тим, щоб мова була успішною. Алан Едельман має глибокі зв’язки із спільнотою обчислювальної науки, і раніше він працював над проектами на мовному рівні (зокрема, розширення Star-P до MATLAB). Джеф Безансон протягом певного часу проводив конференцію, щоб просувати Юлію вченими та інженерами-обчислювачами. У MIT вони добре працювали з набору студентів та персоналу (зокрема, Стівен Дж. Джонсон), щоб зробити свій внесок, додавши бібліотеки до Джулії. Вони отримали статтю в Wired і їм вдалося отримати статтю у Вікіпедії для себе, і все це було лише через рік. Їх Git repo має тисячі зірок, сотні виделок, і сотні годин, тому за стандартами з відкритим кодом їх проект досяг успіху. Я думаю, що вони зробили все правильно, поки що, тому справа в підтримці цих зусиль та розбудові громади. Вони все ще можуть зазнати невдачі, але досягти цього далеко мені підказує, що вони мають розумні шанси на успіх.

Я вважаю, що Юлії варто вчитися. Я використовував це для створення декількох кодів кінцевих елементів дослідження, і виробляти їх дуже швидко. Я був дуже задоволений своїм досвідом.

Юлія ввімкнула робочий процес для мене, який мені було важко досягти з іншими мовами. Ви можете використовувати його як мову прототипу на зразок MATLAB, але на відміну від MATLAB, коли у вас є робочий код і переживаєте ітерації профілювання, щоб пришвидшити його, заміна точкових точок кодом C безболісна. Вони зробили взаємодію з C (і Python) пріоритетним у дизайні.

Таким чином, мова дозволила мені дуже швидко перейти від моїх математичних формулювань до функціонального коду, а потім від функціонального коду до високоефективного коду. Я думаю, що ця особливість Юлії недооцінена, але вона додає величезної цінності.

У багатьох випадках я отримав продуктивність C (порівняно з моїм власним кодом C) за лічені години після створення функціонального коду з кінцевими елементами. Поки, якщо я використовую лише функції Julia, я зазвичай дістаюсь до ~ 3X повільніше, ніж C. Після цього я замінюю гарячі точки на функції C (Julia поставляється з профілем вибірки стека, щоб допомогти їх визначити). Часто для цього потрібна лише заміна рядків коду, що ображає правопорушення, на "виклик", а Юлія обробляє будь-який маршал.

Я думаю, що головне, що Юлі зараз не вистачає, хоча це змушує мене роздумувати над більш масштабними проектами, - це відсутність повністю підтримуваної налагоджувальної системи та погана підтримка побудови графіків (саме зараз найкраща ставка у складі проекту - це лише інтерфейс у matplotlib що я частіше ламав). Негайний зворотний зв'язок щодо коду дійсно важливий. Я також не знаю, як вижити без інтерактивної налагодження, і в цьому відношенні мене дуже зіпсують MATLAB та GDB.

З мого досвіду Юлія ще не готова до (наукового) повсякденного використання (я говорю про стабілізовану версію 0.4 березня 2016 року). Мова сама по собі приємна, насичена і послідовна; освіжаючий крок вперед і від матлаба, і від пітона. Безумовно, є випадки, коли Юлія є хорошим вибором навіть на цій ранній стадії. Але якщо вам потрібні надійні та зрілі наукові бібліотеки, я не можу рекомендувати зараз рухатися. Основні проблеми, з якими я зіткнувся:

• Пакети поза серцевиною Джулії не є надійними. Вони зриваються з оновленнями, змінюються, замінюються, іноді є неповними або просто ламаються.
• Особливості паралелізму Джулії (найвигідніші риси потенційних вбивць математики) незрілі. Ви зіткнетеся з помилками сегментації, витоком пам’яті, збоями та невтішною роботою. Іноді вони не грають добре з іншими частинами Джулії, наприклад, з деякими рішеннями для лінійних систем або пакетів поза ядром. Хоча ці риси звучать багатообіцяюче, вони часто досить часто зазнавали невдач для мене. Майже ніколи не було достатньо просто написати @parallelперед циклом for, куди теоретично слід.
• Багато дрібниць, дрібних помилок та проблем, з якими можна було б жити: не такі приємні та часом помилкові сліди стека викликів, невелика історія помилкового перекладача, повільне завантаження пакетів, погана робота того чи іншого пакету / функції тощо. Що мене дратувало більшість - це пакет PyPlot, обгортка для matplotlib, в даний час альтернативи йому немає. Це дійсно чудово, що він є, і він здебільшого працює. Але якщо вам потрібно побудувати дані, будьте готові до дуже повільної продуктивності та проблем.

Це все покращиться. Я впевнений, що одного дня Джулія перевершить матлаб та пітон майже в усіх аспектах. Великі шанси, що для цього будуть розроблені інноваційні пакети. Схоже, там вже є велика громада. Навіть зараз існує безліч пакетів із випадками використання, починаючи від opencl до веб-серверів. Використовувати бібліотеки python або c дуже просто, тому ви, мабуть, не потрапите на стіну з точки зору наявності бібліотеки. Великою силою Джулії буде легкість, з якою можна поєднати високоефективні функціональні можливості з різних джерел на сучасній та постійній мові високого рівня (див. Відповіді вище). Але в цілому я виявив, що він не є ані зрілим, ані стабільним, щоб бути продуктивним.