Текущее положение Golang в машинном обучение?

Question

[Михаил Р.]

Приветствую!

https://www.reddit.com/r/golang/comments/anbjin/is...
Т.к. вопрос на реддите был задан 2 года назад, то подскажите, как обстоят дела с использованием Golang в машинном обучение на данный момент?

Comments

[Mikhail Osher]

Попробуйте посмотреть вакансии по теме ML, обращайте внимание на стэк.

Answer 1

[Владимир Олохтонов]

Можно запускать либы, написанные на C из Go, но зачем?

Люди выбирают Go в основном из-за умного планировщика, который позволяет удобно работать с сетью. ML сюда не ложится примерно никак, тем более что большинство DS знают Python и это значит, что подходящих людей найти гораздо легче.

Пожалуй единственная нормальная причина использовать ML-библиотеки на Go — это когда у вас уже есть сервис на Go, к которому надо прикрутить немножко ML.

Если же вы пишете новый сервис, где планируется активное использование ML-библиотек, то для невысокой нагрузки прекрасно подойдёт Python, а для высокой лучше всё же сразу взять C++ или какой-нибудь другой язык прозрачно совместимый по памяти с C.

Поэтому мне кажется, что ML-библиотеки на Go так и будут капитально отставать от Python — они там просто почти никому не нужны, вот их и не развивают.

Comments

[Antonio Solo]

"прозрачно совместимый по памяти с C."

это как ?

[Владимир Олохтонов]

Antonio Solo, чтобы буфер, созданный в языке на котором мы пишем, можно было без лишних копирований прочитать в библиотеке на C.

[Станислав Бодро́в]

Люди выбирают Go в основном из-за умного планировщика

Вот оно как. Многопоточность из коробки, нормальный и понятный синтаксис, безопасная модель работы с памятью да и многое другое. Кстати, не стоит забывать кто стоял у истоков С и Go.

который позволяет удобно работать с сетью. ML сюда не ложится примерно никак

Вот когда решишь посчитать модельку, погонять обучение на кластере с сотню серверов, чтобы в каждом десятки ядер и сотни ГБ оперативы, вот тогда посмотрю на то насколько не важно умение работать с сетью. Сколько терабайт сырых данных для обучения заливаешь с хранилища по сети? Сколько сбрасываешь по сети?

лучше всё же сразу взять C++ или какой-нибудь другой язык прозрачно совместимый по памяти с C

Как часто бывает настолько высокая нагрузка на оперативную память, что надо об этом задумываться при выборе ЯП для проекта? Я прекрасно понимаю, что оператива не резиновая и её в случае чего ждёт ООМ, только ядра тоже на дороге не валяются и в случае перегрузки процессора (очень легко делается даже вне ML) к нему волшебный Out of kernel не придёт, за неимением. И всё это время сервер будет представлять из себя тыкву. В Go планировщик достойно справляется со своей работой с памятью. И снимает головную боль порядочную по работе с ней.

ML-библиотеки на Go так и будут капитально отставать от Python

Он (Go) стал набирать популярность, когда начали приобретать популярность приложения для ML на Python. Ну и ещё особенность и строгость Go не позволяет наговнокодить или нашлепать блинов в отличие от Python, поэтому его обошли вниманием начинающие программисты и представители академического кода. Сейчас решения на Python всеми своими хелицерами и ложноножками упираются в производительность и масштабируемость, и бизнес смотрит более достойные варианты.

[Владимир Олохтонов]

Станислав Бодро́в, то что вы описываете, вообще говоря довольно редкий сценарий, большинство моделей можно прекрасно обучить на одном сервере с 4 GPU.

Думаю вы и сами можете сравнить частотность запросов "python machine learning" vs "golang machine learning".

Вообще выбирая между Go и C++ для описанной вами задачи, мы вынуждены будем выбрать между "легче писать" (тут Go действительно заметно выигрывает у плюсов) и "меньше писать" (для C++ у нас сразу доступно множество готовых библиотек).

Что интересно, подобные проекты часто имеют вычислительное ядро на C++, а интерфейсные обёртки вокруг него на Go — таким образом мы получаем лучшее от обоих миров, правда ценой более высоких требований к квалификации разработчиков.

Answer 2

[Станислав Бодро́в]

Текущее положение Golang в машинном обучение?

Довольно неплохое. Постепенно обрастает добротным ПО. Особенно выгодно смотрится он, когда проект становится сложным и нагруженным. Когда траты на разогрев воздуха в ДЦ станут ощутимее прибыли от этого ML (Python однопоточный и вы хоть завалитесь ядрами, цимес как от многопоточности как на Go не получите), когда ты окончательно околеешь от катавасии с версиями Python, их совместимостью и несовместимостью с библиотеками, когда станет вопрос о простом и легком масштабировании (какие сложности с организацией run time для приложения на Go?), когда быстрый hot-fix может быть ещё той лотереей (динамическая типизация может подосрать в самом неожиданном месте), тогда начнёшь думать и ломать свой ИИ.
Если посмотреть на положение дел в текущий момент, то всякие компании типа Ozon, или Avito (наверное слышал о таких) очень активно набирают разрабов даже шапочным знакомством языка Go (подробности смотри на hh.ru) в том числе и в отделы ML и антифрода.

Comments

[Владимир Олохтонов]

Если посмотреть на положение дел в текущий момент, то всякие компании типа Ozon, или Avito (наверное слышал о таких) очень активно набирают разрабов даже шапочным знакомством языка Go (подробности смотри на hh.ru) в том числе и в отделы ML и антифрода.

В Авито все ML-команды пишут его на питоне. Golang используется только как транспортная обёртка в команде рекомендаций, там где нагрузка повыше, сами модели при этом живут в отдельных микросервисах, которые написаны на Python.

Python однопоточный и вы хоть завалитесь ядрами, цимес как от многопоточности как на Go не получите

Это довольно поверхностное утверждение — GIL не позволяет нескольким потокам выполнять код внутри интерпретатора одновременно, но совершенно не мешает одновременно ждать на сетевых операциях, вычислять с помощью мультипроцессинга, или даже с помощью потоков если библиотека отпускает GIL.

Вот хороший доклад на эту тему: https://www.youtube.com/watch?v=AWX4JnAnjBE

[Станислав Бодро́в]

Владимир Олохтонов,

Это довольно поверхностное утверждение — GIL не позволяет нескольким потокам выполнять код внутри интерпретатора одновременно, но совершенно не мешает одновременно ждать на сетевых операциях, вычислять с помощью мультипроцессинга, или даже с помощью потоков если библиотека отпускает GIL.

как это хоть как-то связано с многопоточностью? Где одновременное исполнение множества инструкций на конвейере процессора и где операции с устройством, которое часто живёт по своим законам (когда звезда превращается в шину и начинается борьба за доступ к среде передачи)?
Раз заговорили про потоки (threds)... Как реализовано взаимодействие между потоками исполнения в контексте одного процесса и между потоками исполнения разных процессов в Python? Понятное дело, что как-то так...

[Владимир Олохтонов]

Станислав Бодро́в, вы можете исполнять свой код на нескольких ядрах параллельно используя multiprocessing, если речь идёт о python-коде и multithreading если о сторонних расширениях, отпускающих GIL.

В случае нескольких процессов для передачи данных используются pipe, сокеты и shared memory, ровно так же как и везде — это средства операционной системы, а не языка программирования. Для тредов всё ещё проще, поскольку в рамках одного процесса память у них общая — ровно так же, как и везде.