1) Как на вашем примере поможет Git? Программист зальет частично работающий код… куда? В копию репозитория верстальщика? Это возможно?
2) Что делать? Заливать в trunk закомментаренный код. Верстальщик его раскомментарит, поработает. Когда закончит, зальет в trunk. Гемор, согласен. Возможно, ваш ответ на первый пункт прояснит ситуацию, как сделать без этого гемора.
В PTX перегонял при помощи 3.0. Так как цель — поддержка всех карт на одном ядре.
Возможно, специальное ядро, созданное при помощи CUDA 4.2 исправит ситуацию, надо тестировать.
> Нет он вам вернёт 8, а не 16.
Oops, my bad… Тогда все сходится.
> Выравнивание используете?
Эм, выравнивание в памяти? Нет, так как в памяти хранятся только входные данные и записываются выходные данные. Время копирования мало. Все вычисления делаются на регистрах. Один поток использует не более 32-х регистров. Shared memory не используется, так как медленней.
> Так же попробуйте собрать с -arch=sm_30
Это можно задать только для ptxas, насколько я знаю. То есть при создании бинарного ядра. Я же компилирую в *.ptx, что должно по идее делать GPU-независимый код. При его компиляции во время исполнения программы я уже компилирую *.ptx под конкретную архитектуру.
Скажите, пожалуйста, какие преимущества может дать Git в плане merge'a функционала в основную ветку? Ведь как в SVN нужно разгребать конфликты после каждого merge'a (если они есть), зато эти конфликты видны сразу; так и в Git при push'e могут возникнуть конфликты, только в этом случае вы заливаете не маленькое изменение (как в SVN), а целую фичу. И не факт, что после этого push'a и исправления конфликтов предыдущая функциональность не разъедется…
1) Давайте разбираться. Если у GTX 680 запросить атрибут CU_DEVICE_ATTRIBUTE_MULTIPROCESSOR_COUNT, то возвращенное значение будет равно 16. По спецификации GTX 680 имеет 1536 SP. Следовательно, на один MP приходится 96 SP или 3 warp'a.
Откуда информация про «На 1 MP в SMX приходится 192 SP»?
2) Под SMX вы понимаете GPU в целом?
3) Задача — многократное хеширование, поэтому время копирования информации несоизмеримо мало по сравнению со временем обсчета.
И 16K потоков для моей задачи очень даже неплохо, поверьте. Один поток — один выходной хеш.
4) Ваше предложение по изменению параметров запуска? 16*1024 считается 1,6 секунды. Производительность при 16 блоках наивысшая именно при 1024 потоках на блок.
Печально, что не работают. Я всегда думал, что любую задачу можно выполнить по частям, если между частями сохранять внутреннее состояние.
В моей практике разбиение на части не давало падения производительности даже на процент. Но у меня узкоспециализированные вычисления…
Matlab, CST Microwave, ANSYS Mechanical, Abaqus работают на GF? Если нет, вопрос снят. Если да, то также, как и все остальные проги: разбивают задачу на подзадачи так, чтобы каждая из подзадач считалась быстро.
За наводку на Nvidia TCC driver огромное спасибо! Буду тестировать. :)
То есть, если SP = 1536, MP = 16, то на один MP приходится 96 SP или 3 warp'a.
Я запускал алгоритм с параметрами 16 блоков, 1024 потока. Как видите, перекрытие по количеству потоков очень большое, а значит ресурсы GPU должны быть загружены более-менее оптимально. Но эти параметры запуска давали производительность меньше, чем для GTX 580 (у нее были другие параметры запуска). Отличные от 16 * 1024 параметры запуска давали худшую производительность.
> с GF нельзя работать, когда приложение работает как сервис, т.е. в Session 0 (это ограничения ОС)
Спасибо за информацию, буду знать.
Если на простых карточках нет коррекции ошибок, то они возникают не так часто в целочисленных вычислениях. Я не встречался с такими ошибками. Да, накладные расходы в этом случае будут больше, чем коррекция ошибки на лету, но в рамках всей работы приложения это капля в море.
> Вы сейчас пытаетесь уложиться в 10сек, которые отведены ОС для исполнения на видеоадаптере — иначе обвал работы, в Tesla этого ограничения нет и задача может считаться столько, сколько ей надо.
Как показал мой пример выше, это не так. По-крайней мере, для Tesla C1060.
Тогда что вы имели в виду, когда говорили про сервис для Windows. Есть какие-то особенности, которые нужно учесть?
> Вы этого можете не заметить, ибо коррекция несложных ошибок делается автоматом.
То есть и на простых карточках есть корреция ошибок? :) В любом случае, у меня есть проверка на правильность подсчета каждого запуска.
> Я вам утверждаю что нет. Работать на Tesla будет столько времени — сколько надо.
Специально для вас провел сейчас тест: Tesla C1060, 30 блоков работало 1.6 секунды. Увеличил количество блоков до 90. В теории, должно было работать 4.8 секунды. Но увы, Windows срубила драйвер, так как посчитала его зависшим.
Да, то что Tesla не является видеоадаптером, я в курсе.
> Где я об этом говорил
> Правда тут другой момент, если вы укладываетесь в память GTX — то все ок, но правда не сможете заставить работать ваше приложение как сервис Windows, например.
Возможно, я не так понял.
> Error-Correction Code
Как часто ваши вычисления давали неправильный результат из-за ошибок железа во время передачи данных или самих вычислений? У меня ни разу, GPU работают по несколько дней на полную катушку.
> Вы пользовались проф. дрелью?
Нет. Только советской.
> На Tesla такого поведения нет
Не возьмусь спорить, но предел тоже вроде есть. То ли 5 секунд, то ли 8. Но оптимальные параметры запуска ядра (количество блоков и потоков) не очень часто приводят к выполнению больше 2-х секунд. А если и приводят, то прирост производительности в пределах 5%. Из моего опыта.
Я не очень понял, как связан размер памяти GPU и возможность запуска как сервиса Windows?
ECC — Eliptic Curves? Если да, то я не знаком с вычислениями ECC на GPU, поэтому не могу сказать, можно ли их реализовать на GTX. Одно могу сказать точно: если вычисления требуют больше 1 Gb памяти, то время обработки должно быть намного больше времени копирования, иначе выигрыш от использования GPU будет минимальным. А сколько же в этом случае будет работать ядро на GPU, если OS срубает видеодрайвер после 2-х секунд непрерывной работы GPU?
Профессиональная дрель стоит дороже обычной, потому что она объективно лучше. Для моих задач Tesla объективно хуже GTX из-за своей дороговизны.
2) Что делать? Заливать в trunk закомментаренный код. Верстальщик его раскомментарит, поработает. Когда закончит, зальет в trunk. Гемор, согласен. Возможно, ваш ответ на первый пункт прояснит ситуацию, как сделать без этого гемора.
Возможно, специальное ядро, созданное при помощи CUDA 4.2 исправит ситуацию, надо тестировать.
Oops, my bad… Тогда все сходится.
> Выравнивание используете?
Эм, выравнивание в памяти? Нет, так как в памяти хранятся только входные данные и записываются выходные данные. Время копирования мало. Все вычисления делаются на регистрах. Один поток использует не более 32-х регистров. Shared memory не используется, так как медленней.
> Так же попробуйте собрать с -arch=sm_30
Это можно задать только для ptxas, насколько я знаю. То есть при создании бинарного ядра. Я же компилирую в *.ptx, что должно по идее делать GPU-независимый код. При его компиляции во время исполнения программы я уже компилирую *.ptx под конкретную архитектуру.
Попробую получить профиль ядра.
Откуда информация про «На 1 MP в SMX приходится 192 SP»?
2) Под SMX вы понимаете GPU в целом?
3) Задача — многократное хеширование, поэтому время копирования информации несоизмеримо мало по сравнению со временем обсчета.
И 16K потоков для моей задачи очень даже неплохо, поверьте. Один поток — один выходной хеш.
4) Ваше предложение по изменению параметров запуска? 16*1024 считается 1,6 секунды. Производительность при 16 блоках наивысшая именно при 1024 потоках на блок.
Сделать профиль — средствами NSight? Просто я пишу на Driver API, не знаю, поддерживается ли профайлером *.ptx код.
Но я уверен, что профайлер скажет, что bottle neck'ом являются операции ALU, а не работа с памятью.
В моей практике разбиение на части не давало падения производительности даже на процент. Но у меня узкоспециализированные вычисления…
За наводку на Nvidia TCC driver огромное спасибо! Буду тестировать. :)
Я запускал алгоритм с параметрами 16 блоков, 1024 потока. Как видите, перекрытие по количеству потоков очень большое, а значит ресурсы GPU должны быть загружены более-менее оптимально. Но эти параметры запуска давали производительность меньше, чем для GTX 580 (у нее были другие параметры запуска). Отличные от 16 * 1024 параметры запуска давали худшую производительность.
Спасибо за информацию, буду знать.
Если на простых карточках нет коррекции ошибок, то они возникают не так часто в целочисленных вычислениях. Я не встречался с такими ошибками. Да, накладные расходы в этом случае будут больше, чем коррекция ошибки на лету, но в рамках всей работы приложения это капля в море.
> Вы сейчас пытаетесь уложиться в 10сек, которые отведены ОС для исполнения на видеоадаптере — иначе обвал работы, в Tesla этого ограничения нет и задача может считаться столько, сколько ей надо.
Как показал мой пример выше, это не так. По-крайней мере, для Tesla C1060.
> Вы этого можете не заметить, ибо коррекция несложных ошибок делается автоматом.
То есть и на простых карточках есть корреция ошибок? :) В любом случае, у меня есть проверка на правильность подсчета каждого запуска.
> Я вам утверждаю что нет. Работать на Tesla будет столько времени — сколько надо.
Специально для вас провел сейчас тест: Tesla C1060, 30 блоков работало 1.6 секунды. Увеличил количество блоков до 90. В теории, должно было работать 4.8 секунды. Но увы, Windows срубила драйвер, так как посчитала его зависшим.
Да, то что Tesla не является видеоадаптером, я в курсе.
> Правда тут другой момент, если вы укладываетесь в память GTX — то все ок, но правда не сможете заставить работать ваше приложение как сервис Windows, например.
Возможно, я не так понял.
> Error-Correction Code
Как часто ваши вычисления давали неправильный результат из-за ошибок железа во время передачи данных или самих вычислений? У меня ни разу, GPU работают по несколько дней на полную катушку.
> Вы пользовались проф. дрелью?
Нет. Только советской.
> На Tesla такого поведения нет
Не возьмусь спорить, но предел тоже вроде есть. То ли 5 секунд, то ли 8. Но оптимальные параметры запуска ядра (количество блоков и потоков) не очень часто приводят к выполнению больше 2-х секунд. А если и приводят, то прирост производительности в пределах 5%. Из моего опыта.
ECC — Eliptic Curves? Если да, то я не знаком с вычислениями ECC на GPU, поэтому не могу сказать, можно ли их реализовать на GTX. Одно могу сказать точно: если вычисления требуют больше 1 Gb памяти, то время обработки должно быть намного больше времени копирования, иначе выигрыш от использования GPU будет минимальным. А сколько же в этом случае будет работать ядро на GPU, если OS срубает видеодрайвер после 2-х секунд непрерывной работы GPU?
Профессиональная дрель стоит дороже обычной, потому что она объективно лучше. Для моих задач Tesla объективно хуже GTX из-за своей дороговизны.