#dask #coiled
Ураа, после пары часов танцев удалось запустить вычисления на кластере AWS через coiled. Уже хотел отказаться от этой затеи, т.к. постоянно выкидывало ошибку что не установлен мой модуль, хотя я его копировал на узлы с помощью client.upload_file. Уже было расстроился, что не получается сделать прозрачную замену локального dask на распределённый, но оказалось, в той функции, что требуется запустить на кластере, надо сделать импорт из нужного модуля, и тогда всё заработает. Это нигде не документировано и в поисковике не находится, не удивлюсь, если многие до этой проблемы дошли и бросили. Ну ладно, все проблемы решены, получается? Нет, конечно.
Замерил использование CPU на воркере, похоже, всегда загружено только 1 ядро, что за чёрт? Запостил вопрос на их гитхабе (другой поддержки там не предусмотрено).
Похоже, стартап с US$ 21M финансированием, цель которого демократизировать кластерные вычисления питонистов в облаках... решил, что поддерживать многопроцессовость vs многопотоковость, которая нужна для чистого питон-кода, не умеющего обходить GIL, (и которая уже была в dask) не надо, и так сойдёт. Как говорится, что это, глупость или предательство?
Пока что мне подсказали использовать много машинок не более чем с 2 vCPU. По результатам теста, действительно, это позволяет извлечь максимум из железа: 1 ядро по-любому подсунут виртуальное (HT), и оно даёт +15% к производительнсти, даже с учётом того, что dask от coiled на потоках (не знаю, как это получается). Но при добавлении ещё одного реального и виртуального ядра это масштабирается ещё на 15% вместо 50%, что уже невыгодно. Конечно, создавать каждый раз вирутальный сервер со своим полноразмерным образом диска ради 2 потоков глупо, ну а что делать.
Ураа, после пары часов танцев удалось запустить вычисления на кластере AWS через coiled. Уже хотел отказаться от этой затеи, т.к. постоянно выкидывало ошибку что не установлен мой модуль, хотя я его копировал на узлы с помощью client.upload_file. Уже было расстроился, что не получается сделать прозрачную замену локального dask на распределённый, но оказалось, в той функции, что требуется запустить на кластере, надо сделать импорт из нужного модуля, и тогда всё заработает. Это нигде не документировано и в поисковике не находится, не удивлюсь, если многие до этой проблемы дошли и бросили. Ну ладно, все проблемы решены, получается? Нет, конечно.
Замерил использование CPU на воркере, похоже, всегда загружено только 1 ядро, что за чёрт? Запостил вопрос на их гитхабе (другой поддержки там не предусмотрено).
Похоже, стартап с US$ 21M финансированием, цель которого демократизировать кластерные вычисления питонистов в облаках... решил, что поддерживать многопроцессовость vs многопотоковость, которая нужна для чистого питон-кода, не умеющего обходить GIL, (и которая уже была в dask) не надо, и так сойдёт. Как говорится, что это, глупость или предательство?
Пока что мне подсказали использовать много машинок не более чем с 2 vCPU. По результатам теста, действительно, это позволяет извлечь максимум из железа: 1 ядро по-любому подсунут виртуальное (HT), и оно даёт +15% к производительнсти, даже с учётом того, что dask от coiled на потоках (не знаю, как это получается). Но при добавлении ещё одного реального и виртуального ядра это масштабирается ещё на 15% вместо 50%, что уже невыгодно. Конечно, создавать каждый раз вирутальный сервер со своим полноразмерным образом диска ради 2 потоков глупо, ну а что делать.
GitHub
Making a worker use processes rather than cores · Issue #238 · coiled/feedback
Hi, I am trying to run distributed computing on AWS using coiled. My code is pure Python and therefore can not bypass the GIL. When testing with local Dask on my laptop, to activate all cores I had...
#cloudcomputing #dask #business #opticloud
Облачные вычисления с Dask требуют знания цен (особенно на спотовые инстансы), думаю начать регулярный сбор цен основных провайдеров (AWS, GCP, Azure) в базу. Возможно, в последующем сделаю какой-то сервис поиска лучшей площадки и инстансов для заданной нагрузки (с учётом прогнозной доступности и цены на заданную длительность вычислений). Например, клиент делает сабмит 1 блока своей задачи, сервис прогоняет его на нескольких инстансах, с помощью ML рассчитывает время выполнения на всех возможных инстансах всех облачных провайдеров (они же отличаются по железу). Согласно указанному клиентом объёму блоков в день, датам начала/завершения работ, система рассчитывает, в каких именно облаках и на каких конкретно инстансах нужно создавать кластер, чтобы минимизировать стоимость/время расчётов.
Производительность железа распадается на несколько блоков: CPU, GPU, RAM, Storage (HDD/SSD), Network.
Также у клиента могут быть задачи разного типа: ML Training, ML inference, Finance/Physics/Bio simulations, Video Encoding.
В голове крутится прогон подобных бенчмарков на каждом уникальном по соответствующему железу типу инстанса (например: модель процессора, тип и частота памяти, тип СХД, пропускная способность сети).
Тогда пользователь сервиса (в первом приближении) говорит: мне надо обучать sklearn-овскую модель. минимум памяти на ядро 8Гб, где сейчас это лучше сделать? Сервис отвечает: в AWS, регион us-west-2, зона 2b, инстанс такой-то, спот цена такая-то., индекс производительности такой-то. А если клиент указывает фреймворк tensorflow, в сравнении участвуют уже и GPU, TPU, Trainium инстансы, и получается другой ответ, к примеру, GCP, регион такой-то, TPU v3 spot, цена такая-то, индекс производительности такой-то.
В идеале можно будет свою задачу на минималках отправить на тестирование, и тогда уже система точно рассчитает производительность на каждом инстансе. Но для начала можно будет ориентироваться хотя бы на какие-то общие бенчмарки.
Облачные вычисления с Dask требуют знания цен (особенно на спотовые инстансы), думаю начать регулярный сбор цен основных провайдеров (AWS, GCP, Azure) в базу. Возможно, в последующем сделаю какой-то сервис поиска лучшей площадки и инстансов для заданной нагрузки (с учётом прогнозной доступности и цены на заданную длительность вычислений). Например, клиент делает сабмит 1 блока своей задачи, сервис прогоняет его на нескольких инстансах, с помощью ML рассчитывает время выполнения на всех возможных инстансах всех облачных провайдеров (они же отличаются по железу). Согласно указанному клиентом объёму блоков в день, датам начала/завершения работ, система рассчитывает, в каких именно облаках и на каких конкретно инстансах нужно создавать кластер, чтобы минимизировать стоимость/время расчётов.
Производительность железа распадается на несколько блоков: CPU, GPU, RAM, Storage (HDD/SSD), Network.
Также у клиента могут быть задачи разного типа: ML Training, ML inference, Finance/Physics/Bio simulations, Video Encoding.
В голове крутится прогон подобных бенчмарков на каждом уникальном по соответствующему железу типу инстанса (например: модель процессора, тип и частота памяти, тип СХД, пропускная способность сети).
Тогда пользователь сервиса (в первом приближении) говорит: мне надо обучать sklearn-овскую модель. минимум памяти на ядро 8Гб, где сейчас это лучше сделать? Сервис отвечает: в AWS, регион us-west-2, зона 2b, инстанс такой-то, спот цена такая-то., индекс производительности такой-то. А если клиент указывает фреймворк tensorflow, в сравнении участвуют уже и GPU, TPU, Trainium инстансы, и получается другой ответ, к примеру, GCP, регион такой-то, TPU v3 spot, цена такая-то, индекс производительности такой-то.
В идеале можно будет свою задачу на минималках отправить на тестирование, и тогда уже система точно рассчитает производительность на каждом инстансе. Но для начала можно будет ориентироваться хотя бы на какие-то общие бенчмарки.
#ml #dask #daskml
Продумываю переход на распределённое обучение с Dask, и внезапно оказывается, что там вроде бы и нет (распределённого) FS (feature selection), OR (outlier removal), TT (target transformer). По крайней мере, в официальной доке нигде упоминаний нет, и непонятно, что будет, если их попробовать с конвейером dask-ml, скорей всего, не сработает. Есть только HPT (Hyper Parameters Tuning) и ES (Early Stopping). В Spark MlLib есть хотя бы FS:
VectorSlicer
RFormula
ChiSqSelector
UnivariateFeatureSelector
VarianceThresholdSelector
Продумываю переход на распределённое обучение с Dask, и внезапно оказывается, что там вроде бы и нет (распределённого) FS (feature selection), OR (outlier removal), TT (target transformer). По крайней мере, в официальной доке нигде упоминаний нет, и непонятно, что будет, если их попробовать с конвейером dask-ml, скорей всего, не сработает. Есть только HPT (Hyper Parameters Tuning) и ES (Early Stopping). В Spark MlLib есть хотя бы FS:
VectorSlicer
RFormula
ChiSqSelector
UnivariateFeatureSelector
VarianceThresholdSelector
#dask #coiled
Так смешно. Мэтт Роклин, глава Coiled (и создатель Dask), прислал мне емэйл, что, мол, я престал пользоваться их продуктом, не предоставлю ли обратную связь, почему так вышло? Не знаю, часть ли это стандартной практики контроля качества, или связано с нашей беседой по поводу отсутствия в койлед функциональности мультипотоков, которая есть в опенсорсном dask-distributed, на что я указал им в issue и они пытались мне помочь (но их советы не сработали). Я ответил на письмо, что детальный feedback предоставлю, но мне только нужно понять, насколько развитие dask-distributed создаёт конфликт интересов с развитием коммерческого Койлед, к примеру, что будет, если я предложу PR по добавлению в AWS dask-cloudporvider спотовых инстансов, которых там по странному стечению обстоятельств не завезли. В течение часа Мэтт ответил, что это не проблема, и парни из nvidia, которые тоже поддерживают dask, будут рады это принять. Ну хорошо, подумал я, люди открыты меняться в лучшую сторону, и честно изложил во втором письме свои мысли по поводу того, что Койлед берёт слишком много денег за весьма скромную функциональность, и не пытается даже решить актуальные проблемы: выбор серверов где нагрузка юзера будет считаться быстрее и дешевле, гетерогенные кластера в разных облаках, прогноз interruption rates, prices, perf scores с помощью ML и предоставление пользователю этих оценок. Я как-то думал, это приведёт к плодотворной дискуссии, но прошло уже несколько дней, а мой визави просто пропал )
В связи с этим вспомнился анекдот:
- Вы указали в резюме, что Вашим основным недостатком является привычка всегда говорить напрямик и только правду, верно?
- Да.
- Но, знаете, я думаю, это вовсе не недостаток, а даже преимущество.
- Да мне по*уй, что ты там думаешь.
Так смешно. Мэтт Роклин, глава Coiled (и создатель Dask), прислал мне емэйл, что, мол, я престал пользоваться их продуктом, не предоставлю ли обратную связь, почему так вышло? Не знаю, часть ли это стандартной практики контроля качества, или связано с нашей беседой по поводу отсутствия в койлед функциональности мультипотоков, которая есть в опенсорсном dask-distributed, на что я указал им в issue и они пытались мне помочь (но их советы не сработали). Я ответил на письмо, что детальный feedback предоставлю, но мне только нужно понять, насколько развитие dask-distributed создаёт конфликт интересов с развитием коммерческого Койлед, к примеру, что будет, если я предложу PR по добавлению в AWS dask-cloudporvider спотовых инстансов, которых там по странному стечению обстоятельств не завезли. В течение часа Мэтт ответил, что это не проблема, и парни из nvidia, которые тоже поддерживают dask, будут рады это принять. Ну хорошо, подумал я, люди открыты меняться в лучшую сторону, и честно изложил во втором письме свои мысли по поводу того, что Койлед берёт слишком много денег за весьма скромную функциональность, и не пытается даже решить актуальные проблемы: выбор серверов где нагрузка юзера будет считаться быстрее и дешевле, гетерогенные кластера в разных облаках, прогноз interruption rates, prices, perf scores с помощью ML и предоставление пользователю этих оценок. Я как-то думал, это приведёт к плодотворной дискуссии, но прошло уже несколько дней, а мой визави просто пропал )
В связи с этим вспомнился анекдот:
- Вы указали в резюме, что Вашим основным недостатком является привычка всегда говорить напрямик и только правду, верно?
- Да.
- Но, знаете, я думаю, это вовсе не недостаток, а даже преимущество.
- Да мне по*уй, что ты там думаешь.
😁2
#dask #daskml
HyperBandSearchCV в сочетании с "обычным" sklearn-эстиматором показалось интересной идеей.
https://www.youtube.com/watch?v=we1m4-IsbL8
HyperBandSearchCV в сочетании с "обычным" sklearn-эстиматором показалось интересной идеей.
https://www.youtube.com/watch?v=we1m4-IsbL8
YouTube
Tom Augspurger: Scalable Machine Learning with Dask | PyData New York 2019
Python has a great ecosystem for machine learning, especially on relatively small datasets processed on a single machine. We'll use Dask to scale libraries like NumPy, pandas, and scikit-learn to larger datasets and larger problems. We'll see that problems…