Я не планировал, если есть такой запрос то думаю это вопрос больше к представителям издательства. На самом деле технологии и библиотеки развиваются стремительно и практическая часть так же быстро теряет актуальность. Базовое использование С++ в машинном обучении я сейчас стараюсь большое освещать в общедоступных статьях и докладах.
Вы в предыдущем посте правильно обратили внимание на момент с расчетом элементов в глобальном NDRange, дело в том, что в OpenCL global_range должен задавать общее количество элементов сетки, и local_range будет использоваться для определения количества групп. Т.е. не так как в CUDA когда задается количество блоков. Я действительно не упомянул про это в статье, сейчас добавил. Спасибо что обратили внимание. И у меня используются матрицы в column-major формате это немного запутывает индексацию.
#define TS 32
#define TSM 128 // The tile-size in dimension M
#define TSN 128 // The tile-size in dimension N
#define TSK 16 // The tile-size in dimension K
#define WPTM 8 // The amount of work-per-thread in dimension M
#define WPTN 8 // The amount of work-per-thread in dimension N
#define RTSM (TSM / WPTM) // The reduced tile-size in dimension M (== number of threads)
#define RTSN (TSN / WPTN) // The reduced tile-size in dimension N (== number of threads)
...
В файле optim_gemm.cc находится реализация ядра со всеми оптимизациями, в тут запуск ядер.
Спасибо за развернутый комментарий и найденные неточности. Я действительно допустил ошибки в индексации для простых реализаций. В более сложных все правильно. Также я специально опустил проверку размерностей для упрощения и уменьшения количества кода, т.е. примеры работают только с квадратными матрицами в формате column-major. С размером регистрового файла и локальной памяти тоже было написано неверно. И под стриминг процессором я понимаю Streaming Processor(SP) а не Streaming Multiprocessor(SM), т.е. четвертую часть как вы и написали. Методика измерения производительности использовалась самая простая - просто N раз запустил и усреднил, конечно для серьезных измерений такое не подходит так есть много нюансов, включая плавающую частоту. Но думаю для демонстрации такой подход вполне приемлем учитывая разницу производительности в несколько порядков. Еще раз спасибо что обратили внимание на ошибки, я внес изменения в статью.
В моем понимании, для того чтобы воспользоваться преимуществом широкой шины надо что бы приложение могло за такт обеспечить требуемое количество запросов к памяти. Если доступ не сгруппированный то будет много отдельных транзакций которые забьют этот размер шины и пропускная способность упадёт. Или если SM недостаточно загружены, или много синхронизаций то тоже не получиться сформировать нужное количество запросов. Для более точного ответа нужно наверное начать с профилирования и определить узкие места.
Спасибо за комментарий, насчет квантованной версии, и устаревших архитектур вы правы. Но основная цель статей была показать как используя в основном С++ работать с камерой, обрабатывать изображения и подключить ML библиотеки. Приведенное сравнение производительности было сделано с только целью посмотреть как использование GPU влияет на производительность в рамках выбранных инструментов. А для решения конкретных задач конечно нужно проводить дополнительные исследования, учитывать особенности доступного железа, и по возможности применять актуальные архитектуры моделей.
В целом вы правы. Но так как libtorch это конкретный артефакт(библиотека) который компилируется из репозитория PyTorch то я предпочитаю говорить про PyTorch.
Здравствуйте, в общем случае увеличения производительности не будет, так используется одно и тоже ядро библиотеки. Получить выигрыш в скорости можно, например если будут использоваться специальные методы обработки данных оптимизированные c использованием C/С++/SIMD и таким образом можно исключить преобразование/передачу данных в структуры Python. Такая обработка может быть как в начале pipeline так внутри сети если использовать динамический граф. Ещё как вариант если сеть/pipeline описана на C++ может быть проще работать со специализированными расширениями для того же PyTorch, например если нужен прямой доступ к тензорам(их памяти), так не надо прокидывать специализированную функциональность через python bindings.
Здравствуйте, да думаю увеличение количества направлений может улучшить результат. Решение с HOG было в основном использовано для демонстрации одного из классических вариантов решения, сейчас можно использовать решения на базе NN которые будут более точными и функциональными, и возможно сравнимыми по производительности.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Я не планировал, если есть такой запрос то думаю это вопрос больше к представителям издательства. На самом деле технологии и библиотеки развиваются стремительно и практическая часть так же быстро теряет актуальность. Базовое использование С++ в машинном обучении я сейчас стараюсь большое освещать в общедоступных статьях и докладах.
Да,
, вот ссылка на спецификацию.
Вы в предыдущем посте правильно обратили внимание на момент с расчетом элементов в глобальном NDRange, дело в том, что в OpenCL global_range должен задавать общее количество элементов сетки, и local_range будет использоваться для определения количества групп. Т.е. не так как в CUDA когда задается количество блоков. Я действительно не упомянул про это в статье, сейчас добавил. Спасибо что обратили внимание. И у меня используются матрицы в column-major формате это немного запутывает индексацию.
Посмотрите пожалуйста исходный код проекта https://gitverse.ru/kolkir/clgemm думаю вы там найдете ответы. Вот описания констант:
В файле optim_gemm.cc находится реализация ядра со всеми оптимизациями, в тут запуск ядер.
Спасибо за развернутый комментарий и найденные неточности. Я действительно допустил ошибки в индексации для простых реализаций. В более сложных все правильно. Также я специально опустил проверку размерностей для упрощения и уменьшения количества кода, т.е. примеры работают только с квадратными матрицами в формате column-major. С размером регистрового файла и локальной памяти тоже было написано неверно. И под стриминг процессором я понимаю Streaming Processor(SP) а не Streaming Multiprocessor(SM), т.е. четвертую часть как вы и написали. Методика измерения производительности использовалась самая простая - просто N раз запустил и усреднил, конечно для серьезных измерений такое не подходит так есть много нюансов, включая плавающую частоту. Но думаю для демонстрации такой подход вполне приемлем учитывая разницу производительности в несколько порядков.
Еще раз спасибо что обратили внимание на ошибки, я внес изменения в статью.
В моем понимании, для того чтобы воспользоваться преимуществом широкой шины надо что бы приложение могло за такт обеспечить требуемое количество запросов к памяти. Если доступ не сгруппированный то будет много отдельных транзакций которые забьют этот размер шины и пропускная способность упадёт. Или если SM недостаточно загружены, или много синхронизаций то тоже не получиться сформировать нужное количество запросов. Для более точного ответа нужно наверное начать с профилирования и определить узкие места.
Спасибо за комментарий, насчет квантованной версии, и устаревших архитектур вы правы. Но основная цель статей была показать как используя в основном С++ работать с камерой, обрабатывать изображения и подключить ML библиотеки.
Приведенное сравнение производительности было сделано с только целью посмотреть как использование GPU влияет на производительность в рамках выбранных инструментов. А для решения конкретных задач конечно нужно проводить дополнительные исследования, учитывать особенности доступного железа, и по возможности применять актуальные архитектуры моделей.
Ссылка в начале статьи, проект опубликован тут https://gitflic.ru/project/kolkir/androidobjectdetection
В целом вы правы. Но так как libtorch это конкретный артефакт(библиотека) который компилируется из репозитория PyTorch то я предпочитаю говорить про PyTorch.
А как выбираются соседние элементы для конкретной точки? С помощью knn и деревьев разбиений?
Здравствуйте, в общем случае увеличения производительности не будет, так используется одно и тоже ядро библиотеки. Получить выигрыш в скорости можно, например если будут использоваться специальные методы обработки данных оптимизированные c использованием C/С++/SIMD и таким образом можно исключить преобразование/передачу данных в структуры Python. Такая обработка может быть как в начале pipeline так внутри сети если использовать динамический граф. Ещё как вариант если сеть/pipeline описана на C++ может быть проще работать со специализированными расширениями для того же PyTorch, например если нужен прямой доступ к тензорам(их памяти), так не надо прокидывать специализированную функциональность через python bindings.
Здравствуйте, да думаю увеличение количества направлений может улучшить результат. Решение с HOG было в основном использовано для демонстрации одного из классических вариантов решения, сейчас можно использовать решения на базе NN которые будут более точными и функциональными, и возможно сравнимыми по производительности.