Насколько зрел проект научного языка «Юлия»?

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

Тем не менее, это относительно новый проект, в настоящее время в версии 0.x, и я обнаружил различные предупреждения (опубликованные в разные даты в прошлом), что он не совсем готов для повседневного использования. Следовательно, я хотел бы получить некоторую информацию о состоянии проекта прямо сейчас (февраль 2014 года или всякий раз, когда публикуется ответ), чтобы помочь мне оценить, стоит ли мне лично уделять время для изучения этого языка на данном этапе.

Я был бы признателен за ответы, которые сосредоточены на конкретных фактах о проекте Юлия ; Меня меньше интересуют мнения, основанные на опыте других проектов.

В частности, комментарий Джеффа Оксберри говорит о том, что API Julia все еще находится в состоянии изменения и требует обновления кода при его изменении. Я хотел бы получить представление о степени, в которой это происходит: какие области API стабильны, а какие могут измениться?

Я предполагаю, что обычно я в основном занимался бы линейной алгеброй (например, решением собственных задач), численной интеграцией ODE со многими переменными и построением графиков с использованием PyPlot и / или OpenGL, а также низкоуровневым вычислением чисел в стиле C (например, для моделирования методом Монте-Карло). ). Полностью ли развита библиотечная система Юлии в этих областях? В частности, является ли API более или менее стабильным для этих видов деятельности, или я обнаружу, что мой старый код будет иметь тенденцию ломаться после обновления до новой версии Julia?

Наконец, есть ли другие вопросы, которые стоит рассмотреть, решая, использовать ли Джулию для серьезной работы в настоящее время?

Джулия, на данный момент (май 2019, Джулия v1.1 с v1.2 скоро выйдет) вполне готова для научных вычислений. Релиз v1.0 означал конец ежегодной поломки кода . При этом многие научные вычислительные библиотеки успели просто расти без сбоев. Широкий обзор пакетов Julia можно найти на pkg.julialang.org .

Для основных научных вычислений, то DifferentialEquations.jl библиотека для дифференциальных уравнений (ОДУ, сдесь, ДАЕС, DDEs, Gillespie моделирования и т.д.), Flux.jl для нейронных сетей, а JuMP библиотека для математического программирования (оптимизации: линейная, квадратичная, смешанное целое и т. д. программирование) - три краеугольных камня научной вычислительной экосистемы. В частности, библиотека дифференциальных уравнений гораздо более развита, чем то, что вы видели бы на других языках, с большой группой разработчиков, реализующей такие функции, как интеграторы EPIRK , Рунге-Кутта-Нистром , дифференциальное уравнение с жесткой / дифференциально-алгебраической задержкой иИнтеграторы адаптивных стохастических дифференциальных уравнений с адаптивным по времени , наряду с кучей других полезностей, таких как анализ сопряженной чувствительности , 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 - автоматическая компиляция кода в GPU для его возможностей GPU. Эта совместимость была основой того, что создавало такие вещи, как нейронные дифференциальные уравнения в DiffEqFlux.jl, Вероятностные языки программирования, такие как Turing.jl , также достаточно развиты и используют те же базовые инструменты.

Поскольку библиотеки Джулии основаны на инструментах генерации кода, неудивительно, что существует множество инструментов для генерации кода. Система вещания Джулии генерирует слитые ядра на лету, которые перегружены типами массивов, чтобы предоставить множество функций, упомянутых выше. CUDAnative.jl позволяет компилировать код Julia для ядер GPU. ModelingToolkit.jl автоматически удаляет сахара из AST в символическую систему для преобразования математического кода. Cassette.jlпозволяет вам «перезаписать» чужую существующую функцию, используя правила, чтобы изменить их функцию перед временем компиляции (например: изменить все их распределения массива на статические распределения массива и перенести операции в графический процессор). Это более продвинутый инструментарий (я не ожидаю, что все, кто занимается научными вычислениями, получат прямой контроль над компилятором), но именно так строится множество инструментов следующего поколения (или, скорее, как сами функции пишут).

Что касается параллелизма, я упомянул графические процессоры, а у Юлии встроены многопоточность и распределенные вычисления . Многопоточность Julia очень скоро будет использовать архитектуру выполнения параллельных задач (PARTR), которая позволяет автоматизировать планирование вложенной многопоточности . Если вы хотите использовать MPI, вы можете просто использовать MPI.jl . И, конечно же, самый простой способ использовать все это - просто использовать настройку типа AbstractArray для использования параллелизма в своих операциях.

У Джулии также есть базовая экосистема, которую можно ожидать от языка общего назначения, используемого для научных приложений. Он имеет Juno IDE со встроенным отладчиком с точками останова , имеет Plots.jl для создания всевозможных графиков. Многие специальные инструменты также хороши, например, Revise.jl автоматически обновляет ваши функции / библиотеку при сохранении файла. У вас есть DataFrames.jl , библиотеки статистики и т. Д. На самом деле одна из самых хороших библиотек - это Distributions.jl, которая позволяет вам писать алгоритмы, общие для дистрибутива (например:rand(dist)принимает случайное число независимо от того, какой дистрибутив был передан), и существует целая масса одномерных и многомерных распределений (и, конечно, диспетчеризация происходит во время компиляции, что делает все это так же быстро, как жесткое кодирование функции, специфичной для данного распределения). Существует множество инструментов обработки данных , веб-серверов и т. Д. Вы называете это. На данный момент он достаточно зрел, чтобы, если есть фундаментальная научная вещь, и вы ожидаете, что она будет существовать, вы просто отправите ее в Google с помощью .jl или Джулии, и она появится.

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

В заключение, вы можете найти много движений во многих местах, но в большинстве областей уже есть солидная зрелая библиотека. Это больше не в том месте, где вы спрашиваете «будет ли это принято?»: Юлия была усыновлена ​​достаточным количеством людей (миллионы загрузок), что у нее есть импульс, чтобы остаться навсегда. У него действительно приятное сообщество, так что если вы когда-нибудь захотите просто попутаться и поговорить о параллельных вычислениях или численных дифференциальных уравнениях, некоторые из лучших чатов для этого находятся в Julialang Slack . Является ли это языком, который вы должны выучить, это личный вопрос, и является ли это правильным языком для вашего проекта, это технический вопрос, и это разные. Но разве это язык, который созрел и пользуется поддержкой большой последовательной группы разработчиков? Это кажется утвердительным да.

Если нет, то можно ли дать приблизительную оценку по порядку величины, как долго я должен ждать, прежде чем снова рассмотреть ее?

Моя грубая оценка по порядку величины того, сколько времени требуется языкам вычислительной науки, - около десяти лет.

Пример 1: SciPy началась в 2001 году или около того. В 2009 году был выпущен Scipy 0.7.0, и у интегратора ODE был интерфейс к VODE (что ode15sпримерно эквивалентно ; ode15sоснован на NDF, VODE - BDF / Adams-Bashforth, в зависимости от). В SciPy 0.10.0, интерфейсе dopri5, который примерно эквивалентен MATLAB ode45, метод 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, которая делает то, что вы хотите, напишите прокладку Julia для библиотеки на более устоявшемся языке. Следовательно, я не думаю, что нехватка библиотек будет проблемой. Я думаю, что проблема будет заключаться в том, чтобы изменения в основных функциях языка не кусали вас в задницу. Если вы посмотрите на вехи в репозитории Julia Git, то увидите, что тег «Breaking» используется довольно редко (12 раз в версии 0.2, 5 раз в версии 0.3). Для меня это говорит о том, что базовый язык все еще развивается, поэтому я не решаюсь использовать этот язык прямо сейчас.

РЕДАКТИРОВАТЬ: Аврелий поднимает хороший вопрос:

С чего вы взяли, что Джулия когда-нибудь станет мейнстримом, а не просто умрет в безвестности, как многие другие языки? У SciPy / numpy была / есть поддержка постоянно растущего сообщества питонов, которого нет у Джулии.

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

Что-то, что, как мне кажется, помогает Юлии, это дизайн для исполнения без ущерба для выразительности. Джулия намного более конкурентоспособна с такими компилируемыми языками, как C, чем MATLAB, R или даже Python. Эта цель разработки также является функцией, которая может привлечь людей из существующих языков, таких как:

• Люди, которые очень заботятся о производительности и приходят из таких языков, как C и Fortran, но готовы пожертвовать крошечной производительностью (возможно, в 2 раза), чтобы перейти от скомпилированного языка к меньшему количеству строк интерпретируемого языка (вместе с REPL для более быстрое развитие и тестирование).
• Люди, которые заботятся о высокой производительности и приходят из таких языков, как Python, R и MATLAB, но хотят большей производительности. Когда дело доходит до исполнения, чистый Python, чистый MATLAB и чистый R работают медленно. Разработчики на этих языках изо всех сил стараются обернуть библиотеки в скомпилированные языки, но вы не можете обернуть все, и в какой-то момент базовый язык замедлит вас. Ядро Джулии быстрее, что позволяет быстрее заниматься наукой.
• Люди, которые заботятся о свободном программном обеспечении. Юлия интерпретируется и свободна (как и Питон, Октава и т. Д.); MATLAB нет.

Юлия также пытается облегчить параллелизм; Я не чувствую себя достаточно квалифицированным, чтобы углубляться в этот вопрос, и я не думаю, что это основная черта языка, но я думаю, что это точка продажи, над которой они работают, и я надеюсь, что другие могут пролить свет на это.

Тем не менее, даже с технической заслугой на их стороне, создатели языка должны сделать работу по продвижению языка и евангелизации. Джефф Безансон, Алан Эдельман, Стивен Карпински и Вирал Шах очень стараются, чтобы язык стал успешным. Алан Эдельман имеет тесные связи с сообществом вычислительных наук, и раньше он работал над проектами на уровне языка (особенно над расширением Star-P для MATLAB). Джефф Безансон некоторое время проводил конференцию, чтобы представить Джулию ученым и инженерам в области вычислительной техники. В Массачусетском технологическом институте они проделали хорошую работу по набору студентов и сотрудников (в частности, Стивена Джонсона), чтобы внести свой вклад, добавив библиотеки к Джулии. У них есть статья в Wired, и им удалось получить статью для Википедии всего за год. Их Git репо имеет тысячи звезд, сотни вилок, и сотни часов, так что по стандартам с открытым исходным кодом их проект был успешным. Я думаю, что они уже сделали все правильно, так что это вопрос поддержки этих усилий и создания сообщества. Они все еще могут потерпеть неудачу, но если я пойду далеко, это говорит о том, что у них есть разумный шанс на успех.

Я верю, что Юля стоит учиться. Я использовал его для создания нескольких кодов конечных элементов исследований и очень быстрого их создания. Я был очень доволен своим опытом.

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

Таким образом, язык позволил мне очень быстро перейти от моих математических формулировок к функциональному коду, а затем от функционального кода к высокопроизводительному коду. Я думаю, что эта особенность Юлии недооценена, но она добавляет огромную ценность.

Во многих случаях я получил производительность C (по сравнению с моим собственным C-кодом) в течение нескольких часов после создания функционального кода конечных элементов. До сих пор, если я использую только функции Julia, я обычно получаю в ~ 3 раза медленнее, чем C. После этого я заменяю «горячие точки» функциями C (Julia поставляется с профилировщиком выборки из стека, чтобы помочь идентифицировать их). Зачастую для этого требуется только заменить строки кода «горячей точки», вызывающие проблемы, на «ccall», при этом Джулия обрабатывает любые сортировки.

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

По моему опыту, Юлия еще не готова к (научному) повседневному использованию (я говорю о стабильной версии 0.4 от марта 2016 года). Сам язык хороший, многофункциональный и последовательный; освежающий шаг вперед как от matlab, так и от python. Конечно, есть случаи, когда Юлия - хороший выбор даже на этой ранней стадии. Но если вам нужны надежные и зрелые научные библиотеки, я не могу рекомендовать сделать это сейчас. Основные проблемы, с которыми я столкнулся:

• Пакеты вне ядра Джулии не надежны. Они ломаются с обновлениями, меняются, заменяются, иногда являются неполными или просто сломаны.
• Функции Джулии по параллелизму (по моему мнению, наиболее многообещающие потенциальные возможности убийцы Matlab) являются незрелыми. Вы столкнетесь с ошибками сегментации, утечками памяти, сбоями и неутешительной производительностью. Иногда они не очень хорошо играют с другими частями julia, например, с некоторыми из решателей для линейных систем или пакетов вне ядра. Хотя эти функции звучат многообещающе, для меня они часто оказываются неудачными. Почти никогда не было достаточно просто написать @parallelперед циклом for, где в теории это должно быть.
• Множество мелочей, мелких ошибок и проблем, с которыми можно было бы смириться: не очень приятные, а иногда и ошибочные следы стека вызовов, небольшая история ошибок интерпретатора, медленная загрузка пакетов, плохая производительность того или иного пакета / функции и т. Д. Что меня раздражало большая часть - это пакет PyPlot, оболочка для matplotlib, в настоящее время альтернативы ему нет. Это действительно здорово, что он есть и в основном работает. Но если вам нужно построить данные, будьте готовы к очень медленной работе и проблемам.

Это все станет лучше. Я уверен, что когда-нибудь Джулия превзойдет Matlab и Python практически во всех аспектах. Велика вероятность, что для него будут разработаны инновационные пакеты. Кажется, что уже есть большое сообщество. Даже сейчас существует множество пакетов с вариантами использования от opencl до веб-серверов. Использовать библиотеки Python или C очень просто, так что вы, вероятно, не столкнетесь с проблемой доступности библиотек. Сильной стороной Julia будет легкость, с которой можно склеить высокопроизводительную функциональность из различных источников на современном и последовательном языке высокого уровня (см. Ответы выше). Но в целом я обнаружил, что он не является ни зрелым, ни достаточно стабильным для продуктивного использования.