Julia - holy grail!
От: novitk США  
Дата: 11.12.19 15:45
Оценка: 8 (6) :)
Начал играть недавно с Julia и имхо реально бомба. Версия >1.0 и народ проникся, в МIT вроде на ней уже студней учат.
1) Пишется быстро. Питон не нужен.
2) Работает быстро, а если приложить руки, то очень быстро. C++ не нужен.
3) Компилирует быстро. Скала не нужен.
4) Доки — супер, репл — супер, jupyter kernel — супер.
5) Макросы и multiple dispatch, соответственно ООП выкинули. Clojure не нужен.
6) Очень крутой интероп не только с С, но и с питоном.

Из недостатков:
а) сложно со встройкой, очень большая. Lua нужен.
б) нет js-backend, но это наверное сделают.
c) Индексация массивов с 1. Гребанный матлаб.
Re: Julia - holy grail!
От: AlexRK  
Дата: 11.12.19 16:04
Оценка: +2 -4
Здравствуйте, novitk, Вы писали:

N>c) Индексация массивов с 1. Гребанный матлаб.


Так это ж наоборот круто.
Re: Julia - holy grail!
От: Буравчик Россия  
Дата: 11.12.19 18:06
Оценка:
Здравствуйте, novitk, Вы писали:

N>Начал играть недавно с Julia и имхо реально бомба. Версия >1.0 и народ проникся, в МIT вроде на ней уже студней учат.


Не видно никаких серьезных плюсов перед питоном (пока?), за исключением скорости.

Но питон может быть быстрым, если надо.
см. статью о Julia и затем показательный комментарий к ней: https://habr.com/ru/post/427879/#comment_19290799
Best regards, Буравчик
Re[2]: Julia - holy grail!
От: CreatorCray  
Дата: 11.12.19 19:11
Оценка:
Здравствуйте, AlexRK, Вы писали:

ARK>Так это ж наоборот круто.

Шоп да так ж нет!
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re: Julia - holy grail!
От: Manticore США http://github.com/fjarri
Дата: 11.12.19 19:26
Оценка:
Здравствуйте, novitk, Вы писали:

N>c) Индексация массивов с 1. Гребанный матлаб.


Меня гораздо больше напрягает column-major indexing. Если индексация с 1 еще удобна в определенных ситуациях, то это наследие матлаба нужно было смело закапывать.
Re[2]: Julia - holy grail!
От: novitk США  
Дата: 11.12.19 19:27
Оценка:
Здравствуйте, Буравчик, Вы писали:

Б>Не видно никаких серьезных плюсов перед питоном (пока?), за исключением скорости.

Макросы, мултиметоды вместо ООП, нет 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%.

Re: Julia - holy grail!
От: El Camino Real США  
Дата: 11.12.19 23:21
Оценка:
Здравствуйте, novitk, Вы писали:

N>Начал играть недавно с Julia и имхо реально бомба. Версия >1.0 и народ проникся, в МIT вроде на ней уже студней учат.

Очень нравился, пока не попробовал промышленно использовать. Из недостатков: медленный (реально, на числодробилки с кучей матриц — хорошо, остальное — тормозит); не хватает серьёзной конторы, чтобы навела порядок в процессе разработки языка; всё, что вне математических действий — куцое и кривое (по сравнению с питоном); синтаксис — видно, что разработан умными людьми в научных кругах. В общем, для прикидок на локальной машине меня и питон устраивает, а большие данные всё равно в облаке ворочать, там уже скорость исполнения одной операции — дело десятое.
Re[3]: Julia - holy grail!
От: Буравчик Россия  
Дата: 12.12.19 08:02
Оценка:
Здравствуйте, novitk, Вы писали:

N>Здравствуйте, Буравчик, Вы писали:


N>Макросы, мултиметоды вместо ООП, нет GIL. Я как бы за Питон и считаю всякие там Ruby и R ненужными, но Julia/Clojure дают много нового.


Не думаю, что наличие макросов и мультиметодов сами по себе дадут существенное улучшение в производительности программиста. Скорее, они будут использоваться для создания удобных библиотек. Т.е. библитеки должны уметь то же, что и питон, причем стать еще более удобными из-за макросов и мультиметодов. И когда это будет?

Отсутствие GIL — да, плюс. Но сейчас проблемы с GIL в питон успешно обходятся.

N>Питон нет. numpy, cython — да, но это хаки все. numba вообще работает только для очень простого кода. Скорость очень сложно в язык добавить потом, о ней надо сразу думать. PyPy тому доказательство.


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

N>В показательном комментарии имхо написан бред. Вот тебе показательные примеры:


С чем ты не согласен? Идея в том, что вычисления надо описывать декларативно, а вычисляторы пусть сами разберутся как параллелить и что и как быстро вычислять (с использованием LLVM/C/CPU/GPU/cluster). Julia пытается стать удобной и быстрой числодробилкой (как фортран). Питон — остаться клеем (пусть медленным) между быстрыми числодробилками.
Best regards, Буравчик
Re: Julia - holy grail!
От: Cyberax Марс  
Дата: 12.12.19 08:18
Оценка: 3 (2)
Здравствуйте, novitk, Вы писали:

N>Начал играть недавно с Julia и имхо реально бомба. Версия >1.0 и народ проникся, в МIT вроде на ней уже студней учат.

Мы пытались использовать её для наших задач — симуляции электросхем и computer vision/ml.

Пока что вердикт: "Негодно, но стоит проверить ещё через пару лет".

Проблемы:
1. Компилятор таки достаточно небыстрый на больших объёмах, особенно при холодном старте.
2. Плохой менеджмент потоков и памяти. Там свой планировщик задач на libuv, но работает он пока что посредственно.
3. У нас оно часто падало в Jupyter'е, требуя перезапуска ядра.

Но само плохое — это отсутствие библиотек. Не хватает тонн вещей, особенно в области Machine Learning.

По скорости получилось на порядок лучше Питона, но в несколько раз медленнее кода на С++.
Sapienti sat!
Re: Julia - holy grail!
От: Skorodum Россия  
Дата: 12.12.19 09:33
Оценка:
Здравствуйте, novitk, Вы писали:

У нас тоже используется:
Автор: Skorodum
Дата: 08.11.19


Питон у нас используется очень активно для мелких прикладных задач, для отработки алгоритмов можно использовать любой разумный инструмент, в основном это Matlab, но один ученый предпочитает julia. Почему бы и нет? Адаптировать основной фреймворк и CI для поддержки julia (Win/OSX/Linux) заняло примерно 2 недели, по деньгам это, наверное, сравнимо с лицензией на Matlab. Про количество библиотек ничего не скажу, т.к. сам ничего активно не делаю в этой области.


P.S. Наш data scientist очень доволен и вроде как продуктивен.
Re: Julia - holy grail!
От: $$ Австралия жж
Дата: 12.12.19 10:40
Оценка:
Здравствуйте, novitk, Вы писали:

N>Начал играть недавно с Julia и имхо реально бомба.


Бомба для чего? Мат обсчеты из numpy достаточно быстро считаются. Статистические пакеты- больше всего их в R.
LISP — мне видится ClojureScript более заманчивым, ибо его под nodejs и на фронтенде можно использовать, он оптимизируется под V8 из коробки.

Я ее пытался трогать несколько лет назад, но потом было ощущение, что на питон все побежали с датасаенсом. Что-то поменялось?
Re[4]: Julia - holy grail!
От: novitk США  
Дата: 12.12.19 14:03
Оценка:
Здравствуйте, Буравчик, Вы писали:

Б>Не думаю, что наличие макросов и мультиметодов сами по себе дадут существенное улучшение в производительности программиста.

Не утверждаю, что производительность на 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
Отредактировано 12.12.2019 22:53 novitk . Предыдущая версия . Еще …
Отредактировано 12.12.2019 22:52 novitk . Предыдущая версия .
Re[2]: Julia - holy grail!
От: novitk США  
Дата: 12.12.19 14:13
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Проблемы:

C>1. Компилятор таки достаточно небыстрый на больших объёмах, особенно при холодном старте.
Холодный старт до сих пор плохой, но народ говорит, что Revise.jl купирует проблему.

C>2. Плохой менеджмент потоков и памяти. Там свой планировщик задач на libuv, но работает он пока что посредственно.



C>3. У нас оно часто падало в Jupyter'е, требуя перезапуска ядра.

По слухам вроде сессии живут неделями.

C>Но само плохое — это отсутствие библиотек. Не хватает тонн вещей, особенно в области Machine Learning.

Да, это фигово. Однако PyCall мне очень понравился, то есть переползать можно плавно.
На днях хочу попробовать TF враппер: https://github.com/malmaud/TensorFlow.jl
Re[2]: Julia - holy grail!
От: novitk США  
Дата: 12.12.19 14:26
Оценка:
Здравствуйте, $$, Вы писали:

>Бомба для чего?

One language to rule them all.

>Мат обсчеты из numpy достаточно быстро считаются. Статистические пакеты- больше всего их в R.

Быстро в Py считается только то, что другие люди закодировали на С. Именно поэтому до сих пор R и используют, портировать в Питон замучаешься.

>LISP — мне видится ClojureScript более заманчивым, ибо его под nodejs и на фронтенде можно использовать, он оптимизируется под V8 из коробки.

Clojure по скорости очень слабая, для числовой математики совсем негодная. ClojureScript это круто — да, но ScalaJS еще круче.

>Я ее пытался трогать несколько лет назад, но потом было ощущение, что на питон все побежали с датасаенсом. Что-то поменялось?

фиг знает, вроде она в рейтинге скакнула хорошо.
Отредактировано 12.12.2019 16:10 novitk . Предыдущая версия .
Re[3]: Julia - holy grail!
От: Cyberax Марс  
Дата: 12.12.19 21:47
Оценка: 2 (1)
Здравствуйте, 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 только новые вещи.
Sapienti sat!
Re[4]: Julia - holy grail!
От: novitk США  
Дата: 12.12.19 22:39
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Но это не фундаментальные проблемы, а просто болезни роста. Потому и вердикт — посмотреть чуть позднее.

А как давно это было?
Re[5]: Julia - holy grail!
От: Cyberax Марс  
Дата: 13.12.19 00:29
Оценка:
Здравствуйте, novitk, Вы писали:

C>>Но это не фундаментальные проблемы, а просто болезни роста. Потому и вердикт — посмотреть чуть позднее.

N>А как давно это было?
Февраль-март этого года.
Sapienti sat!
Re[3]: Julia - holy grail!
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 13.12.19 03:42
Оценка:
Здравствуйте, novitk, Вы писали:

N>В показательном комментарии имхо написан бред. Вот тебе показательные примеры:


Однако, что не так? Intel, вон, начал делать oneAPI как раз для этого. Как раз видно, что низкоуровневые штуки типа OpenCL или HSA не взлетели, а необходимость в графах вычислений на разных устройствах есть.
Re[4]: Julia - holy grail!
От: novitk США  
Дата: 13.12.19 05:25
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Однако, что не так? Intel, вон, начал делать oneAPI как раз для этого. Как раз видно, что низкоуровневые штуки типа OpenCL или HSA не взлетели, а необходимость в графах вычислений на разных устройствах есть.


Последний параграф здесь
Автор: novitk
Дата: 12.12.19
.
Re: Julia - holy grail!
От: student__  
Дата: 13.12.19 09:27
Оценка:
Здравствуйте, novitk, Вы писали:

N>Начал играть

Там уже можно сделать заранее откомпилированный бинарь программы без траходрома (не сильно сложнее, "cmake . && make")? Иначе "убийства" С++ и Fortran так и не состоялось.
Первое после старта процесса рисование прямой линии уже не занимает 40+ секунд?

N>c) Индексация массивов с 1. Гребанный матлаб.

Гребаный Fortran. Матлаб взял массивы (арифметика, слайсы) из Fortran, ну и индексацию тоже.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.