Здравствуйте, kaa.python, Вы писали:
KP>Вообще да. У нас тоже PyTorch для обучения, а потом уже мы на плюсы переносим. Но сейчас уже пошли SoC с ML-модулями способными напрямую выполнять натренированную модель с минимальными затратами электричества, что вообще круто для встраиваемых систем.
Все так, но дорого. Для встраиваемых конечная цель — запускать на дешёвом арме и чтоб оно само себя дообучало по ходу пьесы. И пока не видел хорошего решения.
Здравствуйте, El Camino Real, Вы писали:
ECR>В ML есть такой неприятный момент, что оно, зараза, проникает повсюду. Значит питон и расчёты в облаках становятся лишь стадией прототипирования. Нужен "язык для проадакшена". Теоретически — С/С++. Практически — а где ты столько годных плюсовиков найдёшь?
Программистов на C++ уж всяко легче найти, чем на какой-нибудь экзотике.
Здравствуйте, El Camino Real, Вы писали:
ECR>Все так, но дорого. Для встраиваемых конечная цель — запускать на дешёвом арме и чтоб оно само себя дообучало по ходу пьесы. И пока не видел хорошего решения.
Сам себя обучать — это пока фантастика. В лучшем случае как в Тестле: отправлять данные на сервер, где будет идти контролируемое пополнение датасета, дообучение и обновление моделей на устройствах.
Здравствуйте, kaa.python, Вы писали:
KP>т.е. ты тренируешь модель на Python и тебе даже не надо притрагиваться к Плюсам? Звучит интересно, а насколько оно по скорости адекватно работает?
Да, все модели на TorchScript. Который, кстати, JIT-компилируется при необходимости. Обучение идёт или на AWS-инстансах, или на своём небольшом кластере из 50 видеокарт.
KP>Всё же если говорить решение на базе BEAM, то там будет доступ к OTP что дает довольно неожиданные возможности для распределённых вычислений. Ни Python ни C++ такого нет и иметь не будут.
Ну так а смысл? Для тренировки нейронок ничего распределённого не нужно. А запускать будут, один фиг, или на устройствах пользователя (iOS, Android — никакого BEAM), или на серверах (где тоже таки нужна скорость).
Лет 5 назад ещё можно было что-то сделать, а сейчас ниша уже прочно занята.
Здравствуйте, Cyberax, Вы писали:
C>Ну так а смысл? Для тренировки нейронок ничего распределённого не нужно.
Так вот это я и хочу понять. Однозначно не глупые люди зачем-то же решили запилить Nx. Просто что бы было я не исключаю, но как-то это грустно звучит.
C>Лет 5 назад ещё можно было что-то сделать, а сейчас ниша уже прочно занята.
А почему 5 лет назад такая штука была бы полезна?
Я, наверное, глупые вопросы задаю, просто мои познания в машинном обучении ограниченны курсом Энга
Здравствуйте, El Camino Real, Вы писали:
ECR>Все так, но дорого. Для встраиваемых конечная цель — запускать на дешёвом арме и чтоб оно само себя дообучало по ходу пьесы. И пока не видел хорошего решения.
Зависит от задачи. Для тех же AV есть интересные решения от компаний типа Ambarella. ASIL-D решений я не видел, но ASIL-B есть.
Хосе хочет эту WG возглавить, и использовать бюджет EEF для различных работ. Это означает conflict of interest с его нынешней позицией (board member), поэтому он и уходит с нее (как раз перед выборами, кстати, которые уже через неделю откроются). В этом году, кстати, я в списке на перевыборы, и в определенном роде это решение Хосе мне на руку, больше шансов остаться в board.
Здравствуйте, kaa.python, Вы писали:
C>>Ну так а смысл? Для тренировки нейронок ничего распределённого не нужно. KP>Так вот это я и хочу понять. Однозначно не глупые люди зачем-то же решили запилить Nx. Просто что бы было я не исключаю, но как-то это грустно звучит.
Видимо, чтобы хоть как-то поймать уезжающий поезд. Сам язык уже практически однозначно сдулся, так как его использование не нарастает.
C>>Лет 5 назад ещё можно было что-то сделать, а сейчас ниша уже прочно занята. KP>А почему 5 лет назад такая штука была бы полезна?
Потому, что тогда ещё не было развитой питоновской инфраструктуры. Сам по себе ведь Питон для ML не сильно важен как язык, важны инструменты вокруг него (включая и всякие OpenCV, NumPy, и т.п.)
KP>Я, наверное, глупые вопросы задаю, просто мои познания в машинном обучении ограниченны курсом Энга
А хороший пример, кстати. Курс от товарища Нья делается в Jupyter, что сейчас практически является однозначным требованием для ML-инструментов.
KP>Переобучить программиста на любом языке в программиста на Elixir — это 1-2 месяца.
Синтаксис, да.
Но даже очень сообразительный разработчик с хорошим опытом на императивных языках потратит не менее года (а чаще два) на то, чтобы начать писать более-менее идиоматично на Erlang/Elixir/LFE. И то только при условии что его будет менторить еще более опытный товарищ, включая diff reviews.
Уж слишком много надо шаблонов сорвать. Мало того, что функциональный (но не совсем) подход, так еще и shared (nothing), и к concurrency совсем другое отношение, и (полу)прозрачный distribution — на освоение всего этого требуется время и много усилий.
Здравствуйте, SkyDance, Вы писали:
SD>Но даже очень сообразительный разработчик с хорошим опытом на императивных языках потратит не менее года (а чаще два) на то, чтобы начать писать более-менее идиоматично на Erlang/Elixir/LFE. И то только при условии что его будет менторить еще более опытный товарищ, включая diff reviews.
SD>Уж слишком много надо шаблонов сорвать. Мало того, что функциональный (но не совсем) подход, так еще и shared (nothing), и к concurrency совсем другое отношение, и (полу)прозрачный distribution — на освоение всего этого требуется время и много усилий.
В каких именно целях?
Если просто из любопытства, то, наверное, я бы просто рекомендовал начать с какой-нибудь литературы. Например, с книги "Learn you some Erlang", написанную Фредом Хебертом, веселым канадцем.
Другой вариант, сделать что-то работающее, какую-нибудь классику вроде чата. Или поднять свой ejabberd сервер (это с чего whatsapp начинался).
Хотелось бы в общих чертах понять, что Вы имели ввиду, когда писали "писать более-менее идиоматично на Erlang/Elixir/LFE" и "слишком много надо шаблонов сорвать. Мало того, что функциональный (но не совсем) подход, так еще и shared (nothing), и к concurrency совсем другое отношение, и (полу)прозрачный distribution".
Я так понимаю, что при разработке distributed систем каждый раз возникают типовые задачи.
И в Erlang выработаны подходы/инструменты для их решения.
Хотелось бы понять, что это за подходы, их +/- и почему они такие.
PS Что-то типа книжек, в которых авторы технологий с нуля объясняют, какие задачи идеи у них были на старте, что сработало, а что нет, что и почему они сделали в итоге.
SL>Хотелось бы в общих чертах понять, что Вы имели ввиду, когда писали "писать более-менее идиоматично на Erlang/Elixir/LFE" и "слишком много надо шаблонов сорвать. Мало того, что функциональный (но не совсем) подход, так еще и shared (nothing), и к concurrency совсем другое отношение, и (полу)прозрачный distribution".
У разработчика с опытом в других языках есть багаж знаний, который делает освоение функциональных (и тем более распределенных) языков сложным.
Могу, пожалуй, порекомендовать лекцию Роберта Вирдинга, там есть немного по теме.
SL>Я так понимаю, что при разработке distributed систем каждый раз возникают типовые задачи.
После 20 лет в индустрии любые задачи кажутся типовыми. И это ведет к типовым же решениям. Которые, внезапно, оказываются сразу же устаревшими на 20 лет. Потом история делает новый виток, и рождается еще один подход, который, разумеется, повторяет предыдущие, но со своими особенностями. За справкой можно пройти к войнам между "ServiceLocator" и "DependencyInjecton"
SL>И в Erlang выработаны подходы/инструменты для их решения. SL>Хотелось бы понять, что это за подходы, их +/- и почему они такие.
Ага! За этим можно обратиться к Бьярну Декеру, и его выступлениям на конференциях, про историю Ericsson Labs, как Эрланг получился таким, какой он есть.
SL>PS Что-то типа книжек, в которых авторы технологий с нуля объясняют, какие задачи идеи у них были на старте, что сработало, а что нет, что и почему они сделали в итоге.
Да, как раз что нужно. Можно начать с исторической справки. Забавно, что ровно через 10 минут начинается второй день конференции CodeBEAM America (увы, virtual), где Бьярн будет повторять это выступление. Ибо, видимо, все еще актуально.
Здравствуйте, kaa.python, Вы писали:
KP>Долгое время Elixir был (да и сейчас есть, пожалуй) эдакий RoR на стероидах. Как бы и Руби, но поверх BEAM, так что много вкусняшек из коробки. Да, я в курсе про всякие WhatsApp, но на общем фоне они погоды не делают.
А какая связь с Руби и МЛ? Я понимаю Elixir это развитие Элранга. Он конечно похож чем-то МЛ, так как тоже ФП. Но как-то это все натянуто.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А какая связь с Руби и МЛ? Я понимаю Elixir это развитие Элранга. Он конечно похож чем-то МЛ, так как тоже ФП. Но как-то это все натянуто.
У Руби никакой, и у Эликсира никакой. А вот что в случае с Руби, что в случае с Эликсиром чуть ли не единственный заметный сценарий использования — написание CRUD. Ну и писал Эликсир автор РоР, так что они крайне похожи.
KP>У Руби никакой, и у Эликсира никакой. А вот что в случае с Руби, что в случае с Эликсиром чуть ли не единственный заметный сценарий использования — написание CRUD. Ну и писал Эликсир автор РоР, так что они крайне похожи.
Ты что-то перепутал. Хосе не писал ruby on rails. Хосе сначала увлекся РоР, а потом познакомился с BEAM, и очень ему эта виртуальная машина понравилась. Но т.е. РоР ему тоже очень нравился, он смог сделать Руби на BEAM. Не просто сделать, а еще и с финансированием под это — что втройне сложная задача!
На Elixir CRUD, конечно, удобно, но это отнюдь не единственная задача, под которую он годен. Еще есть много всяких data processing pipelines, всякие там distributed systems, ну а теперь, с развитием beam/erlang/..., и вовсе можно на planetary scale applications замахиваться.
Здравствуйте, SkyDance, Вы писали:
SD>Ты что-то перепутал. Хосе не писал ruby on rails. Хосе сначала увлекся РоР, а потом познакомился с BEAM, и очень ему эта виртуальная машина понравилась. Но т.е. РоР ему тоже очень нравился, он смог сделать Руби на BEAM. Не просто сделать, а еще и с финансированием под это — что втройне сложная задача!
José Valim is co-founder of Plataformatec, creator of the Elixir programming language and member of the Ruby on Rails Core Team.
SD>На Elixir CRUD, конечно, удобно, но это отнюдь не единственная задача, под которую он годен.
Это единственная задача на данный момент где он хоть как-то заметен. Что такое современный Elixir? Это Phoenix + Ecto и... и всё
SD> Еще есть много всяких data processing pipelines, всякие там distributed systems, ну а теперь, с развитием beam/erlang/..., и вовсе можно на planetary scale applications замахиваться.
Много что можно, даже на C++ такое написать можно, и что интересно писали и пишут. А еще можно Scala с Akka взять и будет тебе фактически тот же Elixir, разве что пошустрее работающий, но статически типизированный. Planetary scale applications на динамически типизированном языке, пусть и с ништяками типа сопоставления с образцом это идея сильно на любителя. Я знаю что ты как раз в компании таких любителей, но то, что мало кто еще использует таким образом BEAM (в планетарном масштабе) говорит о плохом масштабировании с точки зрения человеческих ресусов (сам-то BEAM шикарно масштабируется).
Тоесть я за BEAM и Elixir, очень хорошие инструменты, но на данный момент они слабо подходят для старта чего-то кроме CRUD в коммерческой разработке. Что бы не быть голословным, я поработал немного в компании фанатов Elixir-а и заметил интересную особенность. Как только ты хоть на шаг отходишь от CRUD, у тебя появляется гора других языков. Надо прикрутить NLP — привет микросервисы на Python. Надо добавить интеграцию с ClickHouse — привет микросервисы на Go. И так всё время!
José Valim is co-founder of Plataformatec, creator of the Elixir programming language and member of the Ruby on Rails Core Team.
Между "автором РоР" (Дэвид) и контрибутором есть большая разница А то так и меня можно было бы автором эрланга назвать, да?
KP>Тоесть я за BEAM и Elixir, очень хорошие инструменты, но на данный момент они слабо подходят для старта чего-то кроме CRUD в коммерческой разработке. Что бы не быть голословным, я поработал немного в компании фанатов Elixir-а и заметил интересную особенность. Как только ты хоть на шаг отходишь от CRUD, у тебя появляется гора других языков. Надо прикрутить NLP — привет микросервисы на Python. Надо добавить интеграцию с ClickHouse — привет микросервисы на Go. И так всё время!
Так это же твой выбор — "прикрутить". Посмотри на того же Jose Valim, он ведь тоже мог бы "прикрутить pytorch" (и да, прикрутил).
Но есть и другой подход. Реализовать на родном языке, Erlang/Elixir/..., а то и вовсе изобрести.
Мы о разных вещах говорим просто. Я о фундаментальных. Ты — о прикладных.
