Вы привели отличный пример, спасибо! Но, я понимаю, если вы заказываете специализированное оборудование, имеет (может быть) смысл все потактово считать, но если вы хотите сравнить, какой алгоритм, например, сортировки быстрее работает на CPU, теоретически, вы можете все потактово разложить, но на сколько результат будет близок к реальности, и на сколько это трудоемко сделать?
>> Вашем ответе пока не дает мне возможностей писать программы и понимать в ограничения ресурсов
В статье есть ссылка на книгу по CUDA, там большинство ограничений расписано, но это опять же актуально для конкретной архитектуры, а не для всех GPU. Честно говоря, не очень понятно насколько детально вы хотите разобраться, ведь эти ограничения будут отличаться для каждой модели карты, если лезть в детали.
Боюсь, я не тот, кто сможет в данный момент помочь с таким описанием, у разработчиков плат это выйдет однозначно лучше.
В тестах для агрегации я использовал std::accumulate. Как оказалось, он примерно в четыре раза хуже обычного цикла, и результаты приведены для одного потока. К сожалению, если данных еще нет на карте, тогда оверхед на пересылку данных для 700 MB из вашего примера составит примерно 100 ms, а расчет займет около 6 ms, поэтому при текущей имплементации, для небольшого объема данных, агрегация не лучший пример для Tesla k80. Хотел попробовать запустить пример на Tesla v100, там пропускная способность и производительность выше, но, к сожаления пока не получилось поднять инстанс.
Наверное, в самом простом виде, вот эта картинка описывает, что происходит при работе с GPU:
Processing flow on CUDA
Про узкие места 1 и 4 по пересылке данных написано в статье и есть графики для оценки оверхеда на пересылку данных
2 — это загрузка исполняемой программы (ядра) на видеокарту. Перед тем как запустить программу на видеокарте, ее нужно туда загрузить.
3 — это то самый SIMD (или SIMT для NVIDIA), много параллельных потоков, одни и те же инструкции, разные данные — в статье так же есть примеры. Этот пункт, наверное, ключевой для оценки эффективности алгоритма. Но, яркие примеры — сортировка и трансформация. Трансформация хорошо параллелится, но, тем не менее, работает медленнее на GPU, а сортировка на GPU выглядит очень сложно, по сравнению с CPU, но работает быстрее. Как оценить теоретически, какой алгоритм быстрее на GPU, или GPU vs CPU, я не нашел общепринятого способа. Оценка O-большое здесь не работает, как вы понимаете.
Вообще, цель статьи как раз и была, дать теоретический минимум для того, чтобы подступиться к GPU, но вместо теоретической оценки, попробовать на практике с минимальными трудозатратами.
> график зависимости размера данных от времени перекачки приведен далее в статье
поправил, спасибо, привольно — «времени перекачки от размера данных»
> на графике указаны миллисекунды
да, 0.318 миллисекунд — 318 ~ 350 микросекунд
> от 350 в какую сторону
в большую, конкретно для Tesla k80
> может не хватить?
здесь именно смысл «хватить», у каждого свое представление о low latency, в моем представлении это 1-3 мс, поэтому я пишу «хватить»
Мое личное мнение, может быть и не столь компетентное, что OpenCL будет еще долго жить, т.к.
1. Как минимум, развивается, есть таргет на 2020 год
2. Уже поддерживается многими производителями (жаль что Apple депрекейтят)
3. Есть спрос на кроссплатформенный фреймворк, если речь идет о массовом продукте с поддержкой GPU, то покупателя сложно убедить, что вдобавок ему нужно еще и карту конкретную купить. А с OpenCL о вендоре карты можно не особо переживать.
4. Не стоит забывать о конкурирующих решения на FPGA (которые я не упомянул в статье). В описании OpenCL заявлена поддержка FPGA, что теоретически должно позволить легко мигрировать на эти железяки (хотя не очень верится, что легко), это так же должно поддерживать «жизнь» OpenCL
Да ещё и ограничение на вывод BTC ввели в 0.05. т.е. при текущей доходности майнинга, для того чтобы вывести доход хотя бы через месяц, мощностей должно быть примерно 23 Th (~$2300). Это прямой обман пользователей. Учитывая текущую волатильность курса биткоина, хотелось бы выводить намайненное ежедневно. Да и сам майнинг то давно уже не окупается. За 3 года на вашем сервисе, только за счёт резкого скачка курса в + вышел. А тут ещё бессрочные контракты ограничили сроком в 1 год. Интересно, вы своим пользователям другого проекта, под названием Polybius Bank такие же условия обслуживания предложите?
>> Вашем ответе пока не дает мне возможностей писать программы и понимать в ограничения ресурсов
В статье есть ссылка на книгу по CUDA, там большинство ограничений расписано, но это опять же актуально для конкретной архитектуры, а не для всех GPU. Честно говоря, не очень понятно насколько детально вы хотите разобраться, ведь эти ограничения будут отличаться для каждой модели карты, если лезть в детали.
Боюсь, я не тот, кто сможет в данный момент помочь с таким описанием, у разработчиков плат это выйдет однозначно лучше.
Про узкие места 1 и 4 по пересылке данных написано в статье и есть графики для оценки оверхеда на пересылку данных
2 — это загрузка исполняемой программы (ядра) на видеокарту. Перед тем как запустить программу на видеокарте, ее нужно туда загрузить.
3 — это то самый SIMD (или SIMT для NVIDIA), много параллельных потоков, одни и те же инструкции, разные данные — в статье так же есть примеры. Этот пункт, наверное, ключевой для оценки эффективности алгоритма. Но, яркие примеры — сортировка и трансформация. Трансформация хорошо параллелится, но, тем не менее, работает медленнее на GPU, а сортировка на GPU выглядит очень сложно, по сравнению с CPU, но работает быстрее. Как оценить теоретически, какой алгоритм быстрее на GPU, или GPU vs CPU, я не нашел общепринятого способа. Оценка O-большое здесь не работает, как вы понимаете.
Вообще, цель статьи как раз и была, дать теоретический минимум для того, чтобы подступиться к GPU, но вместо теоретической оценки, попробовать на практике с минимальными трудозатратами.
поправил, спасибо, привольно — «времени перекачки от размера данных»
> на графике указаны миллисекунды
да, 0.318 миллисекунд — 318 ~ 350 микросекунд
> от 350 в какую сторону
в большую, конкретно для Tesla k80
> может не хватить?
здесь именно смысл «хватить», у каждого свое представление о low latency, в моем представлении это 1-3 мс, поэтому я пишу «хватить»
1. Как минимум, развивается, есть таргет на 2020 год
2. Уже поддерживается многими производителями (жаль что Apple депрекейтят)
3. Есть спрос на кроссплатформенный фреймворк, если речь идет о массовом продукте с поддержкой GPU, то покупателя сложно убедить, что вдобавок ему нужно еще и карту конкретную купить. А с OpenCL о вендоре карты можно не особо переживать.
4. Не стоит забывать о конкурирующих решения на FPGA (которые я не упомянул в статье). В описании OpenCL заявлена поддержка FPGA, что теоретически должно позволить легко мигрировать на эти железяки (хотя не очень верится, что легко), это так же должно поддерживать «жизнь» OpenCL
Да ещё и ограничение на вывод BTC ввели в 0.05. т.е. при текущей доходности майнинга, для того чтобы вывести доход хотя бы через месяц, мощностей должно быть примерно 23 Th (~$2300). Это прямой обман пользователей. Учитывая текущую волатильность курса биткоина, хотелось бы выводить намайненное ежедневно. Да и сам майнинг то давно уже не окупается. За 3 года на вашем сервисе, только за счёт резкого скачка курса в + вышел. А тут ещё бессрочные контракты ограничили сроком в 1 год. Интересно, вы своим пользователям другого проекта, под названием Polybius Bank такие же условия обслуживания предложите?