#architecture #highload #exchange #moex
https://habr.com/en/company/moex/blog/444300/
https://habr.com/en/company/moex/blog/444302/
https://habr.com/en/company/moex/blog/444300/
https://habr.com/en/company/moex/blog/444302/
Habr
Эволюция архитектуры торгово-клиринговой системы Московской биржи. Часть 1
Всем привет! Меня зовут Сергей Костанбаев, на Бирже я занимаюсь разработкой ядра торговой системы. Когда в голливудских фильмах показывают Нью-Йоркскую фондовую биржу, это всегда выглядит так: толпы...
#cuda #gpu #architecture #programming
Напоминалка, как устроена программная модель Cuda. Что такое потоки, блоки, сетки.
https://developer.nvidia.com/blog/cuda-refresher-cuda-programming-model/
Напоминалка, как устроена программная модель Cuda. Что такое потоки, блоки, сетки.
https://developer.nvidia.com/blog/cuda-refresher-cuda-programming-model/
NVIDIA Technical Blog
CUDA Refresher: The CUDA Programming Model
This is the fourth post in the CUDA Refresher series, which has the goal of refreshing key concepts in CUDA, tools, and optimization for beginning or intermediate developers.
#featureengineering #python #architecture
Возникла архитектурная задача. Мне нужно рассчитывать признаки на большом количестве дней. Сырые данные по дню лежат в 3 отдельных файлах. Что делается сейчас в цикле по дням:
1) файлы дня последовательно открываются как фреймы пандас, делается фильтрация и простой общий препроцессинг. работает 1 ядро. занимает 30 секунд.
2) обработанные файлы направляются в joblib.Parallel уже на все ядра с указанием, какой кусок данных просчитывать конкретному воркеру (ядру). работают все ядра, фаза занимает на текущем железе 10 минут. как происходит направление файлов: 2 передаются просто как параметры, их numpy прозрачно memmap-ит (в течение нескольких секунд). третий содержит столбец массивов (dtype=object), не родной тип numpy, поэтому memmap не происходит. приходится обработанный файл сохранять как временный(в паркет, это оказалось быстрее всего), и уже изнутри каждого рабочего потока открывать по ссылке. как и при сериализации, здесь дублируется RAM, но работает быстрее.
Неизбежно какие-то ядра заканчивают работу быстрее остальных, и в итоге утилизация процессора на какое-то время падает со 100% до, скажем, 30%. Ну и пока файлы готовятся, утилизация составляет жалкие проценты. Рабочие потоки, кстати, возвращают результаты как фреймы панадас, которые потом сливаются в 1 фрейм в главном потоке (2сек) и дампятся в файл (15сек). Итого выходит, что до 10% времени железо простаивает.
Как бы лучше организовать непрерывную подачу файлов и обеспечить постоянную загрузку поближе к 100%? Интуитивно, ближе к концу батча уже есть ресурсы, чтобы независимо подготовить следующий батч, и потом сразу наачать исполнять его на всех ядрах, но как это реализовать в коде?
Пока думаю в отдельном потоке готовить файлы и складывать в очередь, если её длина меньше 3. иначе спать минуту. А уже в основном потоке брать из очереди и засылать на параллельное выполнение. Да, вспомогательный поток уменьшит на 1 число рабочих потоков, но так кодить будет проще, утилизация повысится с 90% до 99%. Также надо подумать об асинхронном мёрдже и сохранении результатов. Может, как раз в тот же вспомогательный поток результаты засылать? Пока остальные молотят расчёты, этот пусть будет завхозом, который файлы открывает, готовит, результаты собирает и сохраняет...
Возникла архитектурная задача. Мне нужно рассчитывать признаки на большом количестве дней. Сырые данные по дню лежат в 3 отдельных файлах. Что делается сейчас в цикле по дням:
1) файлы дня последовательно открываются как фреймы пандас, делается фильтрация и простой общий препроцессинг. работает 1 ядро. занимает 30 секунд.
2) обработанные файлы направляются в joblib.Parallel уже на все ядра с указанием, какой кусок данных просчитывать конкретному воркеру (ядру). работают все ядра, фаза занимает на текущем железе 10 минут. как происходит направление файлов: 2 передаются просто как параметры, их numpy прозрачно memmap-ит (в течение нескольких секунд). третий содержит столбец массивов (dtype=object), не родной тип numpy, поэтому memmap не происходит. приходится обработанный файл сохранять как временный(в паркет, это оказалось быстрее всего), и уже изнутри каждого рабочего потока открывать по ссылке. как и при сериализации, здесь дублируется RAM, но работает быстрее.
Неизбежно какие-то ядра заканчивают работу быстрее остальных, и в итоге утилизация процессора на какое-то время падает со 100% до, скажем, 30%. Ну и пока файлы готовятся, утилизация составляет жалкие проценты. Рабочие потоки, кстати, возвращают результаты как фреймы панадас, которые потом сливаются в 1 фрейм в главном потоке (2сек) и дампятся в файл (15сек). Итого выходит, что до 10% времени железо простаивает.
Как бы лучше организовать непрерывную подачу файлов и обеспечить постоянную загрузку поближе к 100%? Интуитивно, ближе к концу батча уже есть ресурсы, чтобы независимо подготовить следующий батч, и потом сразу наачать исполнять его на всех ядрах, но как это реализовать в коде?
Пока думаю в отдельном потоке готовить файлы и складывать в очередь, если её длина меньше 3. иначе спать минуту. А уже в основном потоке брать из очереди и засылать на параллельное выполнение. Да, вспомогательный поток уменьшит на 1 число рабочих потоков, но так кодить будет проще, утилизация повысится с 90% до 99%. Также надо подумать об асинхронном мёрдже и сохранении результатов. Может, как раз в тот же вспомогательный поток результаты засылать? Пока остальные молотят расчёты, этот пусть будет завхозом, который файлы открывает, готовит, результаты собирает и сохраняет...