Начал играть недавно с Julia и имхо реально бомба. Версия >1.0 и народ проникся, в МIT вроде на ней уже студней учат.
1) Пишется быстро. Питон не нужен.
2) Работает быстро, а если приложить руки, то очень быстро. C++ не нужен.
3) Компилирует быстро. Скала не нужен.
4) Доки — супер, репл — супер, jupyter kernel — супер.
5) Макросы и multiple dispatch, соответственно ООП выкинули. Clojure не нужен.
6) Очень крутой интероп не только с С, но и с питоном.
Из недостатков:
а) сложно со встройкой, очень большая. Lua нужен.
б) нет js-backend, но это наверное сделают.
c) Индексация массивов с 1. Гребанный матлаб.
Здравствуйте, novitk, Вы писали:
N>Начал играть недавно с Julia и имхо реально бомба. Версия >1.0 и народ проникся, в МIT вроде на ней уже студней учат.
Не видно никаких серьезных плюсов перед питоном (пока?), за исключением скорости.
Здравствуйте, novitk, Вы писали:
N>c) Индексация массивов с 1. Гребанный матлаб.
Меня гораздо больше напрягает column-major indexing. Если индексация с 1 еще удобна в определенных ситуациях, то это наследие матлаба нужно было смело закапывать.
Здравствуйте, Буравчик, Вы писали:
Б>Не видно никаких серьезных плюсов перед питоном (пока?), за исключением скорости.
Макросы, мултиметоды вместо ООП, нет GIL. Я как бы за Питон и считаю всякие там Ruby и R ненужными, но Julia/Clojure дают много нового.
Б>Но питон может быть быстрым, если надо.
Питон нет. numpy, cython — да, но это хаки все. numba вообще работает только для очень простого кода. Скорость очень сложно в язык добавить потом, о ней надо сразу думать. PyPy тому доказательство.
Б>см. статью о Julia и затем показательный комментарий к ней: https://habr.com/ru/post/427879/#comment_19290799
В показательном комментарии имхо написан бред. Вот тебе показательные примеры:
Язык Julia можно рассматривать как продолжение линии Fortran, где нам нужно написать числодробилку для каких-нибудь сеточных методов в таком императивном стиле, плюс распараллелить все по типу OpenMP.
Современный ответ на эту проблему это концепция потоковых полусимвольный графов вычислений. Что-то типа TensorFlow. Мы отделяем граф вычислений от потоков данных. Граф вычислений собираем из готовых блоков, которые автоматически распределяются под разнообразное железо.На мой взгляд Julia слишком низкоуровневая для этого. А вот Python подходит под эту концепцию на все 100%.
Здравствуйте, novitk, Вы писали:
N>Начал играть недавно с Julia и имхо реально бомба. Версия >1.0 и народ проникся, в МIT вроде на ней уже студней учат.
Очень нравился, пока не попробовал промышленно использовать. Из недостатков: медленный (реально, на числодробилки с кучей матриц — хорошо, остальное — тормозит); не хватает серьёзной конторы, чтобы навела порядок в процессе разработки языка; всё, что вне математических действий — куцое и кривое (по сравнению с питоном); синтаксис — видно, что разработан умными людьми в научных кругах. В общем, для прикидок на локальной машине меня и питон устраивает, а большие данные всё равно в облаке ворочать, там уже скорость исполнения одной операции — дело десятое.
Здравствуйте, novitk, Вы писали:
N>Здравствуйте, Буравчик, Вы писали:
N>Макросы, мултиметоды вместо ООП, нет GIL. Я как бы за Питон и считаю всякие там Ruby и R ненужными, но Julia/Clojure дают много нового.
Не думаю, что наличие макросов и мультиметодов сами по себе дадут существенное улучшение в производительности программиста. Скорее, они будут использоваться для создания удобных библиотек. Т.е. библитеки должны уметь то же, что и питон, причем стать еще более удобными из-за макросов и мультиметодов. И когда это будет?
Отсутствие GIL — да, плюс. Но сейчас проблемы с GIL в питон успешно обходятся.
N>Питон нет. numpy, cython — да, но это хаки все. numba вообще работает только для очень простого кода. Скорость очень сложно в язык добавить потом, о ней надо сразу думать. PyPy тому доказательство.
У питона и нет цели быть быстрым. У него задача — быть простым и гибким. Пусть библиотеку будут быстрыми.
Про numba не знаю, не использовал пока. Есть пример сложного кода, с которым numba не работает?
N>В показательном комментарии имхо написан бред. Вот тебе показательные примеры:
С чем ты не согласен? Идея в том, что вычисления надо описывать декларативно, а вычисляторы пусть сами разберутся как параллелить и что и как быстро вычислять (с использованием LLVM/C/CPU/GPU/cluster). Julia пытается стать удобной и быстрой числодробилкой (как фортран). Питон — остаться клеем (пусть медленным) между быстрыми числодробилками.
Здравствуйте, novitk, Вы писали:
N>Начал играть недавно с Julia и имхо реально бомба. Версия >1.0 и народ проникся, в МIT вроде на ней уже студней учат.
Мы пытались использовать её для наших задач — симуляции электросхем и computer vision/ml.
Пока что вердикт: "Негодно, но стоит проверить ещё через пару лет".
Проблемы:
1. Компилятор таки достаточно небыстрый на больших объёмах, особенно при холодном старте.
2. Плохой менеджмент потоков и памяти. Там свой планировщик задач на libuv, но работает он пока что посредственно.
3. У нас оно часто падало в Jupyter'е, требуя перезапуска ядра.
Но само плохое — это отсутствие библиотек. Не хватает тонн вещей, особенно в области Machine Learning.
По скорости получилось на порядок лучше Питона, но в несколько раз медленнее кода на С++.
Питон у нас используется очень активно для мелких прикладных задач, для отработки алгоритмов можно использовать любой разумный инструмент, в основном это Matlab, но один ученый предпочитает julia. Почему бы и нет? Адаптировать основной фреймворк и CI для поддержки julia (Win/OSX/Linux) заняло примерно 2 недели, по деньгам это, наверное, сравнимо с лицензией на Matlab. Про количество библиотек ничего не скажу, т.к. сам ничего активно не делаю в этой области.
P.S. Наш data scientist очень доволен и вроде как продуктивен.
Здравствуйте, novitk, Вы писали:
N>Начал играть недавно с Julia и имхо реально бомба.
Бомба для чего? Мат обсчеты из numpy достаточно быстро считаются. Статистические пакеты- больше всего их в R.
LISP — мне видится ClojureScript более заманчивым, ибо его под nodejs и на фронтенде можно использовать, он оптимизируется под V8 из коробки.
Я ее пытался трогать несколько лет назад, но потом было ощущение, что на питон все побежали с датасаенсом. Что-то поменялось?
Здравствуйте, Буравчик, Вы писали:
Б>Не думаю, что наличие макросов и мультиметодов сами по себе дадут существенное улучшение в производительности программиста.
Не утверждаю, что производительность на J будет лучше чем на Py, скорее что она будет не хуже.
Что до мултиметодов, то я очень люблю единые и разделенные подходы, которые мы сейчас имеем например в Хаскеле, Ерланге и Clojure. Есть данные, есть функции — все. В Питоне и прочих гибридах все намешано из за того, что единственный удобный adhoc полиморфизм это single-dispatch. В результате в Питоне нужно все время думать как запихнуть модель в это прокрустово ложе и очень часто этот выбор достаточно субъективен и может быть не оптимален по мере эволюции кода или не работать вообще, то есть требовать multi-dispatch, который красиво просто не сделать.
Б>Скорее, они будут использоваться для создания удобных библиотек. Т.е. библитеки должны уметь то же, что и питон, причем стать еще более удобными из-за макросов и мультиметодов. И когда это будет?
Я не вижу причин почему это не будет. Clojure например уже имеет библиотеки в некоторых областях лучше питона.
Б>Про numba не знаю, не использовал пока. Есть пример сложного кода, с которым numba не работает?
numba оптимизирует нижние функции индивидуально, это такой локальный pypy. Если внутри типы выводятся и ничего внешнего о чем она не знает не вызывается — ок. Нет? досвидос.
N>>В показательном комментарии имхо написан бред. Вот тебе показательные примеры: Б>С чем ты не согласен?
С тем, что создание dataflow graphs очень удобно делать на Py, а на J почему-то нет. На самом деле Питон довольно средний язык для создания внутренних DSL. Лучше конечно чем Java, но по сравнению например со Скалой все очень плохо. Например макросы в этом деле сильно помогают. В качестве показательного примера сравни pandаs, в котором на каждый чих надо смотреть stackoverflow, и LINQ, который прост и понятен. Если что, linq завезли: https://github.com/JuliaData/DataFramesMeta.jl/blob/master/src/linqmacro.jl
Здравствуйте, Cyberax, Вы писали:
C>Проблемы: C>1. Компилятор таки достаточно небыстрый на больших объёмах, особенно при холодном старте.
Холодный старт до сих пор плохой, но народ говорит, что Revise.jl купирует проблему.
C>2. Плохой менеджмент потоков и памяти. Там свой планировщик задач на libuv, но работает он пока что посредственно.
C>3. У нас оно часто падало в Jupyter'е, требуя перезапуска ядра.
По слухам вроде сессии живут неделями.
C>Но само плохое — это отсутствие библиотек. Не хватает тонн вещей, особенно в области Machine Learning.
Да, это фигово. Однако PyCall мне очень понравился, то есть переползать можно плавно.
На днях хочу попробовать TF враппер: https://github.com/malmaud/TensorFlow.jl
Здравствуйте, $$, Вы писали:
>Бомба для чего?
One language to rule them all.
>Мат обсчеты из numpy достаточно быстро считаются. Статистические пакеты- больше всего их в R.
Быстро в Py считается только то, что другие люди закодировали на С. Именно поэтому до сих пор R и используют, портировать в Питон замучаешься.
>LISP — мне видится ClojureScript более заманчивым, ибо его под nodejs и на фронтенде можно использовать, он оптимизируется под V8 из коробки.
Clojure по скорости очень слабая, для числовой математики совсем негодная. ClojureScript это круто — да, но ScalaJS еще круче.
>Я ее пытался трогать несколько лет назад, но потом было ощущение, что на питон все побежали с датасаенсом. Что-то поменялось?
фиг знает, вроде она в рейтинге скакнула хорошо.
Здравствуйте, novitk, Вы писали:
C>>Проблемы: C>>1. Компилятор таки достаточно небыстрый на больших объёмах, особенно при холодном старте. N>Холодный старт до сих пор плохой, но народ говорит, что Revise.jl купирует проблему.
Пока не пробовали, но отсутствие настоящего компилятора напрягает.
C>>2. Плохой менеджмент потоков и памяти. Там свой планировщик задач на libuv, но работает он пока что посредственно. N> C>>3. У нас оно часто падало в Jupyter'е, требуя перезапуска ядра. N>По слухам вроде сессии живут неделями.
Баги где-то в рантайме. У нас достаточно сложный многопоточный код.
Но это не фундаментальные проблемы, а просто болезни роста. Потому и вердикт — посмотреть чуть позднее.
C>>Но само плохое — это отсутствие библиотек. Не хватает тонн вещей, особенно в области Machine Learning. N>Да, это фигово. Однако PyCall мне очень понравился, то есть переползать можно плавно. N>На днях хочу попробовать TF враппер: https://github.com/malmaud/TensorFlow.jl
Как-то слишком громоздко. Уж лучше тогда всё на Питоне писать, а на Julia только новые вещи.
Здравствуйте, Cyberax, Вы писали:
C>Но это не фундаментальные проблемы, а просто болезни роста. Потому и вердикт — посмотреть чуть позднее.
А как давно это было?
Здравствуйте, novitk, Вы писали:
C>>Но это не фундаментальные проблемы, а просто болезни роста. Потому и вердикт — посмотреть чуть позднее. N>А как давно это было?
Февраль-март этого года.
Здравствуйте, novitk, Вы писали:
N>В показательном комментарии имхо написан бред. Вот тебе показательные примеры:
Однако, что не так? Intel, вон, начал делать oneAPI как раз для этого. Как раз видно, что низкоуровневые штуки типа OpenCL или HSA не взлетели, а необходимость в графах вычислений на разных устройствах есть.
Здравствуйте, Nuzhny, Вы писали:
N>Однако, что не так? Intel, вон, начал делать oneAPI как раз для этого. Как раз видно, что низкоуровневые штуки типа OpenCL или HSA не взлетели, а необходимость в графах вычислений на разных устройствах есть.
Здравствуйте, novitk, Вы писали:
N>Начал играть
Там уже можно сделать заранее откомпилированный бинарь программы без траходрома (не сильно сложнее, "cmake . && make")? Иначе "убийства" С++ и Fortran так и не состоялось.
Первое после старта процесса рисование прямой линии уже не занимает 40+ секунд?
N>c) Индексация массивов с 1. Гребанный матлаб.
Гребаный Fortran. Матлаб взял массивы (арифметика, слайсы) из Fortran, ну и индексацию тоже.