Комментарии 21
Если честно, то язык уже не настолько новый, чтобы каждую публикацию начинать с того, для чего он нужен. Посмотрите хаб https://habr.com/ru/hub/julia/
Основная область применения — математика и высоконагруженные вычисления.
- без проблем с производительностью
- без глобальной блокировки интерпретаторa
- с опциональной типизацией с выводом типов
- с, вообще говоря, зависимыми типами. Раньше в документации так и писали, но потом убрали из-за того, что в julia это не то же самое и не так круто как в idris, но когда люди читают «зависимые типы», то ждут именно чего то в стиле idris...
- с отличными средствами интроспекции и оптимизации кода, когда вызываешь что то в стиле @code_llvm custom_code, смотришь генерируемый llvm-код, подправляешь, обычно, типы, снова смотишь… добиваясь идеального кода, чтобы julia все могла вывести статически, чтобы в рантайме не было лишних выделений памяти или диспатчеризации методов… кайф...
- с макросами
- с множественной диспатчеризацией
При этом она позволяет органично использовать экосистему python с помощью github.com/JuliaPy/PyCall.jl
@pyimport math
# с этого момента math - полноценный julia-модуль
m = math
m.sin(m.pi/4)
Вообще говоря, можно подконнектиться к существующему python-процессу…
Самое главное, что julia разрывает порочный круг, когда прототипируешь на python, но потом это начинает работать слишком медленно, переписываешь на что то более быстрое и менее интерактивное… и в этом момент получается две версии одного кода, которые надо синхронизировать и каждое изменение в прототипе может потребовать переписывать ускоренную версию. А на juliа прототипируешь, уже получая большую производительность… Но в случае чего достаточно расставить типы в критических местах(массивы, циклы) и проблема с производительностью решена.
А поддержка синтаксиса в стиле matlab/octave/numpy — это, скорей, приятный бонус. Синтаксический сахарок. Да и, на самом деле, для питона поболее математических библиотек…
не понмиаю, почему вы так сужаете область применения Julia? У меня она полностью вытеснила python в т.ч. в работе. Julia — это тот же python, тока:
Вы ставите меня в неудобное положение… Если бы я не испытывал симпатии к Julia, то не писал бы обзоры о ней… В то же время, вынужден отметить, что не совсем всё так хорошо.
При ответах на вопрос для чего нужна Julia, я привожу именно ту область, где соревноваться с ней некому, если не говорить о специализированных коммерческих продуктах. В области научных исследований, там, где нужна реальная разработка новых алгоритмов, а не копирование существующих решений, с Julia соревноваться просто некому.
Однако я бы не стал сейчас рекомендовать Julia в веб-разработку. Я стараюсь следить за этой областью, но не видел никаких более-менее надёжных бенчмарков о том, как поведёт себя HTTP.jl на высоких нагрузках. Если же сравнивать скорость разработки и удобство поддержки веб-приложений, например Ruby on Rails и https://github.com/GenieFramework/Genie.jl, то результат, явно не в пользу Genie. Безусловно, всё может измениться, если какая-то крупная компания решит поддержать её, обеспечит разработку массы типовых проектиков, проведёт популяризацию разработки именно на Julia. Но они этого не делают.
У Julia недостаточная интеграция в Java-код. Всё, что связано с "большими данными" — это Java. ETL — преимущественно Java. И если для других языков уже разработаны средства для интеграции с Java, то в случае с Julia — нет. Уже больше года назад я слепил для тестов обвязку https://github.com/rssdev10/julia4j. Бинарная часть собирается руками, потому как перевести на CMAKE и проверить это на разных операционках, руки у меня не дошли. Проблема в том, что embedded Julia не может быть запущена в изолированном контейнере. А значит, даже если мы активируем код из какого-нибудь условного Apache Beam/Flink/Ignite, у нас проблема с запуском на параллельное выполнение кода из разных узлов нашего workflow в рамках одного процесса.
В части интерфейса для Питон-кода. Да, он есть и работает, как минимум для чистого питон-кода. Но проблема в том, что большинство библиотек для Питона — грязные. Например, попытки подключить код, использующий pandas, приведут к ошибке активации его native-библиотек. Понятно, что для Julia-программы pandas не нужен ни в какой форме. У нас есть DataFrames, CSV и пр. с быстрым разбором файлов и быстрыми методами обработки таблиц, но для кода на питоне, использующего pandas это означает, что сначала нам надо его переписать… Даже не представляю, что будет, если пытаться подключить pytorch и как его после этого настраивать на GPU (если кто это проделал — оставьте комментарий). Понятно, что для Julia есть Flux, но кто же будет переписывать на него, например Flair Framework (у Zalando Research нет ни одного публичного проекта на Julia).
И, есть ещё одна серьёзная проблема — люди слишком ленивы, чтобы переключиться на что-то новое просто потому, что оно более быстрое и удобное в перспективе. Я постоянно сталкиваюсь с питонистами, которые меня на полном серьёзе уверяют, что не бывает такого, чтобы в каком-то практическом проекте не нашлось готовой библиотеки для питона. И, даже в принципе, невозможна такая ситуация, что им придётся реализовывать свой вычислительный алгоритм, потому, что такого не бывает… Всё уже сделано до нас и глубоко оптимизировано внутри существующих библиотек (не мои слова)… И речь не идёт о бестолковых студентах. Речь идёт о людях, которые несколько лет занимаются анализом данных… Да и, откровенно говоря, вокруг Питона сейчас зарабатывают очень много денег. На рекламе курсов, на курсах, на продаже учебной литературы и пр. Кто же хочет это всё ломать.
Также, моё личное мнение — Julia — наиболее подходящий язык для обучения программированию. Он простой по синтаксису, позволяет правильно поставить алгоритмическое мышление и избежать зашоренности готовыми библиотеками. А вот будущее Julia сильно зависит от того, на сколько быстро появится поколение, которое выросло именно на Julia.
Julia для меня хороша тем, что из коробки предоставляет неплохой язык программирования для научных расчетов с почти идеальной производительностью. Но как язык общего уровня для других задач, например для веба или простых утилит, она проигрывала Питону.
Питон меня полностью устраивает как язык общего уровня. Крайне нравится идеология векторизованных вычислений через NumPy. Но еще пару лет тому назад меня расстраивали три вещи: а) не всегда можно все выразить через NumPy, да и сам NumPy местами медленный, b) GIL, и сложность с параллельными вычислениями и c) отсутствие типизации, что важно для сложных проектов. Все эти проблемы решались через Cython, но код при этом становился крайне плохо читаемым.
Но за последние несколько лет Python практически решил все эти проблемы: a) появилась Numba, JIT компиляция на лету; теперь достаточно всего пары аннотаций для максимально производительного параллельного кода, b) в python 3.8 появилась концепция субинтерпретаторов с экспериментальным API для shared memory, т.е. проблемы GIL уже почти нет и c) очень неплохая система аннотации типов.
В настощий момент я на чистом Python (Numpy + Numba) могу написать красивый код (с ясной аннотацией типов), который по производительности не будет уступать Julia. При этом у меня есть широчайшее коммьютнити и библиотеки на каждый чих.
Но вообще, я очень болею за Julia! Это важный проект для всей области научных расчетов. Мне очень не хватает в Julia простой компиляции в нативный код. Было бы это просто (например, как в nim с его проектом nimpy), я пробовал бы потихоньку на julia писать бинарные модули и использовать из Python.
Мне очень не хватает в Julia простой компиляции в нативный код.
Есть https://github.com/JuliaLang/PackageCompiler.jl
Можно сгенерировать запускаемый бинарник. Только код должен быть оформлен в пакет и быть установлен как пакет. А бинарник будет довольно жирным. Для сервисов — годится.
На счёт остального — не могу прокомментировать. Нам удавалось избегать использования Питона где бы то ни было. И, как раз сейчас, я сомневаюсь в его будущем и целесообразности каких-либо инвестиций в него. Очень большие сомнения, что версия 3.8 дойдёт до массового внедрения. И что новые, вообще, появятся. В сообществе разработчиков постоянные конфликты. Впрочем, это взгляд со стороны. Прямо сейчас я не готов начать какой-либо новый проект на нём. На Julia — без проблем. На счёт библиотек на каждый чих, большинство из них давно заброшены, имеют проблемы стабильности и совместимости с новыми версиями языка.
Есть github.com/JuliaLang/PackageCompiler.jlДа, я его как раз и пробовал. Но для меня пока и процесс компиляции, и результат оказались довольно тяжеловесными. Надеюсь, что компилятор будет постепенно совершенствоваться.
Можно сгенерировать запускаемый бинарник. Только код должен быть оформлен в пакет и быть установлен как пакет. А бинарник будет довольно жирным.
Нам удавалось избегать использования Питона где бы то ни было. И, как раз сейчас, я сомневаюсь в его будущем и целесообразности каких-либо инвестиций в него.Хмм… Ну не знаю. Пока я наблюдаю как раз обратную картину взрывного роста использования Питона в научных расчетах. Почти каждая крупная компания недавно выдвинула свою инициативу развития Python. Вот некоторые примеры
— Intel: software.intel.com/distribution-for-python, полная интеграция со своими флагманскими библиотеками для высокопроизводительных расчетов Intel Math Kernel Library, Intel Data Analytics Acceleration Library
— NVidia: developer.nvidia.com/how-to-cuda-python, полная поддержка компиляции Python для GPU
— Google: это TensorFlow, сейчас один из важнейших продуктов для Google,
— Netflix: практически полностью построен на Python, medium.com/netflix-techblog/python-at-netflix-bba45dae649e, тут как раз и преимущество Python, что на нем можно писать не только научные расчеты, а строить всю инфраструктуру
— одно из главных открытий в физике последних лет, непосредственно измеренные гравитационные волны, были рассчитаны на Python: pycbc.org,
— много много других
Вот еще интересная публикация о статистике использования фреймворков для машинного обучения, собранная по данным упоминания на самых популярных научных конференциях: thegradient.pub/state-of-ml-frameworks-2019-pytorch-dominates-research-tensorflow-dominates-industry. Там говорится, что по большому счету остались только два самых популярных фреймворка: TensorFlow и PyTorch, оба это Python.
На счёт библиотек на каждый чих, большинство из них давно заброшены, имеют проблемы стабильности и совместимости с новыми версиями языка.Вот это все-таки не так. Все хоть как-либо значимые библиотеки уже давно собраны в очень качественные дистрибутивы с полной поддержкой последних версий Python и регулярным обновлением под три платформы: Windows, Linux, Mac. Вот наиболее популярный пакет www.anaconda.com/distribution/#download-section. Мне сложно придумать типовую математическую задачу, которая не была бы уже в том или ином виде реализована в этом дистрибутиве.
- Intel инвестировала в Julia Computing — https://juliacomputing.com/docs/JC_Whitepaper_110417.pdf Поэтому, в ближайшее время, они точно будут поддерживать Julia. Кроме того, у Intel есть специальные сборки Julia именно под их железо. Актуально для резидентов США.
- Проект с Google — это TPU — https://github.com/JuliaTPU/XLA.jl
- Машинное обучение — https://github.com/alan-turing-institute/MLJ.jl, Los Alamos National Laboratory — https://lanl-ansi.github.io/software/, https://mads.lanl.gov/
- Flux.jl с неофициальными бенчмарками, где оказывается сильно быстрее PyTorch по большинству типовых задач. Скорее всего, из-за возможности глубокой автоматической оптимизации. Всё же, один язык для всего — это плюс.
Всё это из того, что на поверхности.
Большинство крупных компаний поддерживает несколько перспективных на их взгляд технологий. Да и, если клиенты хотят, то почему бы за их деньги не сделать.
Касаемо Питона — ну не знаю, зачем его тащить в научные вычисления. Поддержка библиотек на одном языке всегда дешевле, чем 2-3, что приходится делать с Питоном. Надежда на то, что программисты готовы работать за еду, поскольку их очень много, иногда оправдывается. Иногда выливается в то, что искать толковых становится дороже, чем мигрировать на новую технологию.
А вообще, есть простой вопрос. Если что-то случилось, то кому платить? В случае Julia — платить Julia Computing и они всё исправят. В Питоне — не знаю. Авторы библиотек только за свои куски отвечают. Да и, вообще, не факт, что исправят, потому что процесс принятия решения в Питоне стал слишком тяжеловесным.
На счёт математических задач — они постоянно возникают. Это и анализ текстов, и различные методы приближенных вычислений, методы кластерного анализа и пр. Если бы там было больше нечего делать, уже во всех языках давно бы сделали полные библиотеки.
Да, я его как раз и пробовал. Но для меня пока и процесс компиляции, и результат оказались довольно тяжеловесными. Надеюсь, что компилятор будет постепенно совершенствоваться.
Это не сложно делается. На тестовом сервисе мы это отработали. Но в статью, пока, не готов оформить. Хотелось бы ещё мелочи с докером и HTTP.jl вычистить. А вообще, разбирались с этим тут: https://discourse.julialang.org/t/packagecompiler-sockets-web-app/28793
Там есть ссылки на проектик, который я использую как полигон. Но, хотелось бы его почистить перед тем, как статью делать.
Python это «официальный» API для Tensorflow. По статистике на github.com/tensorflow/tensorflow Python составляет более 30% кодовой базы, что для совсем тонкого интерфейса многовато. Да и вообще использование low-level C/C++ модулей распространенное решение в экосистеме Python, это делается очень просто и органично. Python тут выступает очень эффективным «клеем» для интеграции low-level функций.
Для экосистемы Julia использование C/С++ модулей не слишком «спортивно». Julia позиционируется как язык, способный конкурировать с C/C++ на его поле за счет развитой системы типов с диспетчеризацией вызовов и JIT компиляции. Иделогия Julia как раз в том, чтобы иметь на высоком уровне выразительный язык типа MatLab для научных вычислений, но при этом иметь возможность получать произодительность нативной плафтормы. Поэтому оборачивание C/C++ TensorFlow в Julia выглядит как пренебрежение идеологией Julia.
По поводу задач, которые в Питоне не решаются (быстро) — Ракаукаса можно почитать (http://www.stochasticlifestyle.com/).
Если кратко — нелинейные диффуры. Правую часть зачастую сложно записать в векторизованном виде, и набор солверов в SciPy довольно скудный.
Сейчас, конечно, Julia — больше для энтузиастов. Библиотек мало, готовые решения часто не очень-то готовые и т.д. Что там будет дальше в конкуренции с питоном — неясно, но в области научных расчетов мне как-то вот просто питон не хочется. Хочется типы, мультиметоды, более близкую к математической запись и возможность писать без отступов.
Коркретно по pandas, numpy, scipy я оценивал готовность pycall. Скажем, mean — «грязный» вызов из нативной части pandas, прекрасно работает:
@pyimport pandas
pd = pandas
s = pd.Series([1, 2, 3, 4, 5, 6])
s.mean() # => 3.5pytorch обязательно попробую на днях прикрутить…
Нашел стек. Это была машинка с CentOS 7, но что-то подобное я ловил и на MacOS. Именно проблема с некоторыми питоновскими библиотеками в их зависимостях libstdc++. Возможно, это можно исправить полной пересборкой на своей платформе, но кому же эта красота нужна....
Возможно, надо править пути поиска или делать ссылки, но, тоже, не слишком интересное занятие. Тот код просто вычистили от pandas.
Resolving package versions…
loaded
ERROR: LoadError: LoadError: LoadError: InitError: PyError ($(Expr(:escape, :(ccall(#= /home/ml/.julia/packages/PyCall/RQjD7/src/pyeval.jl:39 =# @pysym(:PyEval_EvalCode), PyPtr, (PyPtr, PyPtr, PyPtr), o, globals, locals))))) <class 'ImportError'>
ImportError("/usr/bin/../lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /home/ml/anaconda3/lib/python3.6/site-packages/pandas/_libs/window.cpython-36m-x86_64-linux-gnu.so)",)
File "/home/ml/.julia/packages/PyCall/RQjD7/src/pyeval.jl", line 2, in const Py_file_input = 257
File "/home/ml/anaconda3/lib/python3.6/site-packages/pandas/init.py", line 42, in from pandas.core.api import *
File "/home/ml/anaconda3/lib/python3.6/site-packages/pandas/core/api.py", line 10, in from pandas.core.groupby.groupby import Grouper
File "/home/ml/anaconda3/lib/python3.6/site-packages/pandas/core/groupby/init.py", line 2, in from pandas.core.groupby.groupby import (
File "/home/ml/anaconda3/lib/python3.6/site-packages/pandas/core/groupby/groupby.py", line 49, in from pandas.core.frame import DataFrame
File "/home/ml/anaconda3/lib/python3.6/site-packages/pandas/core/frame.py", line 74, in from pandas.core.series import Series
File "/home/ml/anaconda3/lib/python3.6/site-packages/pandas/core/series.py", line 3978, in Series._add_series_or_dataframe_operations()
File "/home/ml/anaconda3/lib/python3.6/site-packages/pandas/core/generic.py", line 8891, in _add_series_or_dataframe_operations
from pandas.core import window as rwindow
File "/home/ml/anaconda3/lib/python3.6/site-packages/pandas/core/window.py", line 36, in import pandas._libs.window as _window
$ conda install libgcc
Возможно, что просто никто не хотел разбираться. Ставили через https://github.com/JuliaPy/Conda.jl
Но в любом случае, DataFrames быстрее.
PS: Если PyTorch заведётся из под Julia, то это лишний аргумент проектировать продукты именно на Julia, постепенно заменяя питоновские куски.
Julia. С чего начать проект?…