не такое уж и сложное дело, берем обычный процессор, который у вас есть, далее пишем какой-нибудь не сложный вычислительный код и смотрим, сколько нужно времени для double, сколько для предложенной реализации. Если окажется, что предложенная реализация быстрее, но при этом выдает приемлемую точность, то можно было бы попробовать использовать этот тип в более серьезных приложениях. У меня интерес есть к этому, так как в CFG коде не всегда можно "нормально" перейти с FP64 на FP32, если бы получилось что то интересное с предложенным кодом, то можно было бы попробовать использовать его, так как точности в FP32 не всегда хватает.
Самое главное, какая производительность этого дела? Сравнима ли она с double, float? Было бы интересно это увидеть, иначе смысл этого всего немного теряется. И насколько быстро растёт погрешность, например, при выполнении редукции по сумме скажем 1000000 чисел?
приведите хотя бы один компилятор, который так не делает и будет выдано false? в статье не сказано, что может быть выдано или true, или false, утверждается, что только false, при этом если взять и скомпилировать самыми распространенными компиляторами, то получим совершенно иную картину.
Не знаю, писал ли кто то здесь про это, но если в статье это не исправлено, значит нет: <<< Однако код"abrakadabra" == "abrakadabra"вернет false, ведь это два разных массива >>>
тут явно ерунда написана, так как в С++ будет возвращено значение true, можете проверить это на коде printf("%d\n", "abrakadabra" == "abrakadabra");
Одно дело, пишутся какие то тестовые программы, другое дело — реальные приложения. Попробуйте написать на своем питоне один из тестов NAS NPB, например BT или LU для газодинамики, и посмотрим, как быстро он будет выполняться на ГПУ, благо результатов очень много, в том числе мною оптимизированные версии под высокоуровневую модель DVMH, где не нужно писать ни строчки на языке C-CUDA. Думаю, что на питоне даже с такими библиотеками и близко не достичь нормальных результатов, а времени на разработку будет потрачено не мало.
А что как не по русски то написано, читать как то не приятно. Очень плохо объясняется, даже узко специализированному читателю мне кажется на очень то и ясно. Самое главное очень размыта именно сама суть алгоритма — откуда же там берется место и как это вообще работает.
Если честно сказать, то он адаптирован для ГПУ и ЦПУ мой + я придумал, как надо организовать данные, чтобы алгоритм работал максимально эффективно. Причем положение данных позволяет выполнять обработку большинства алгоритмов намного быстрее, чем если бы граф находился в произвольном состоянии.
Безусловно, текущий алгоритм это совершенно новый и намного лучший алгоритм, чем был ~5 лет назад, опубликованный мной.
На счет моделирования — надо понять какой процент от общего времени занимают переходы и для чего при переходе использовать BFS ?
Алгоритм не может быть точным или не точным. Алгоритм фильтрации либо корректный, либо не корректный. Последний Алгоритм 3 вообще не правильный, так как он не даст корректного результата. На счет 2го — вопрос.
специально для этого комментария в статье присутствует уточнение. На данный момент нет фиксированной скорости передачи данных между ГПУ и ЦПУ. Также в данном направлении постоянно идет развитие. К примеру, сейчас есть стандарты PCIe 2.0/3.0 и готовится к релизу 4.0. Скорость у них вполне себе известная, для 2.0 — 8 ГБ/сек, для 3.0 — 15ГБ/сек. И я думаю не трудно посчитать самому сколько это будет передаваться. Другое направление — NVlink со скоростью порядка 40-80 ГБ/с.
Но как бы ни была быстра шина между ГПУ-ЦПУ, скорость работы ГПУ все равно будет быстрее и если посмотреть текущие тенденции развития ГПУ и ЦПУ, можно заметить, что ГПУ повышает вычислительную мощность с каждым новым поколением гораздо больше, чем ЦПУ.
Ну и в данном случае предполагалась либо потоковая обработка, либо последовательность фильтров или обработки изображения. Ясное дело, что только одну картинку обрабатывать на ГПУ нет смысла, да и написано это все было ради того, чтобы показать простоту разработки под ГПУ, по отношению к использованию AVX.
а amd_median5 или amd_median7 там есть? И на сколько мощный там ГПУ? + вы не учитываете, что там обращения идут в ЦПУшную память, которая очень медленная.
В данной статье тестируется 300к матриц размером 4х4, я думаю, что на ГПУ это будет тоже быстро. Могу попробовать оптимизировать такое легкое ядро ради интереса (если это вам интересно конечно).
Раз уж я пишу про CUDA, то имею право использовать вендорно зависимые функции. Вы лучше не просто так ссылки пишите, а приведите пример производительности всего того, что упомянули. А так — это голые слова.
На счет буфера А ничего не понял. Может быть имелось в виду то, что повторные загрузки, начиная со второй линии не повторяются — так это и так оптимизируется компилятором и для этого не надо уродовать код.
Про pragma unroll и так было сказано, а описанные вами оптимизации компилятор сделает и так.
Если вы думаете, что тернарная операция сработает быстрее if, то советую обратиться к профилировщику. Видимо для AMD и openCL еще не придумали нормальных инструментов. А вот у Nvidia все по человечески.
Кому нужны ваши 5%? Если бы это были разы, то другое дело.
Если очень интересно реально то показать, то напишите ваш очень оптимизированный код на openCL и запустите на ГПУ Nvidia и посмотрите что получится.
не такое уж и сложное дело, берем обычный процессор, который у вас есть, далее пишем какой-нибудь не сложный вычислительный код и смотрим, сколько нужно времени для double, сколько для предложенной реализации. Если окажется, что предложенная реализация быстрее, но при этом выдает приемлемую точность, то можно было бы попробовать использовать этот тип в более серьезных приложениях. У меня интерес есть к этому, так как в CFG коде не всегда можно "нормально" перейти с FP64 на FP32, если бы получилось что то интересное с предложенным кодом, то можно было бы попробовать использовать его, так как точности в FP32 не всегда хватает.
Опробовать можно на методе Якоби, например, хотя бы на последовательной реализации. Например, на таком коде, нужно только выкинуть наши директивы распараллеливания, если смущают, а так - ни будут проигнорированы. http://dvmh-server.ddns.net:3000/Alexander_KS/SAPFOR/src/branch/master/dvm/tools/tester/trunk/test-suite/Performance/jac3d.cdv
Самое главное, какая производительность этого дела? Сравнима ли она с double, float? Было бы интересно это увидеть, иначе смысл этого всего немного теряется. И насколько быстро растёт погрешность, например, при выполнении редукции по сумме скажем 1000000 чисел?
даже в таком варианте будет true
где в статье так написано?
приведите хотя бы один компилятор, который так не делает и будет выдано false? в статье не сказано, что может быть выдано или true, или false, утверждается, что только false, при этом если взять и скомпилировать самыми распространенными компиляторами, то получим совершенно иную картину.
Не знаю, писал ли кто то здесь про это, но если в статье это не исправлено, значит нет:
<<< Однако код"abrakadabra" == "abrakadabra"вернет false, ведь это два разных массива >>>
тут явно ерунда написана, так как в С++ будет возвращено значение true, можете проверить это на коде
printf("%d\n", "abrakadabra" == "abrakadabra");
А зачем писать с# приложение, нельзя напрямую запустить программу из консоли и вывести время её работы, как это было сделано чуть выше?
Более того, в фортране есть операции над массивами, которые заменяют циклы, например, А=В+С, где А, В, С — массивы.
Одно дело, пишутся какие то тестовые программы, другое дело — реальные приложения. Попробуйте написать на своем питоне один из тестов NAS NPB, например BT или LU для газодинамики, и посмотрим, как быстро он будет выполняться на ГПУ, благо результатов очень много, в том числе мною оптимизированные версии под высокоуровневую модель DVMH, где не нужно писать ни строчки на языке C-CUDA. Думаю, что на питоне даже с такими библиотеками и близко не достичь нормальных результатов, а времени на разработку будет потрачено не мало.
А что как не по русски то написано, читать как то не приятно. Очень плохо объясняется, даже узко специализированному читателю мне кажется на очень то и ясно. Самое главное очень размыта именно сама суть алгоритма — откуда же там берется место и как это вообще работает.
Если честно сказать, то он адаптирован для ГПУ и ЦПУ мой + я придумал, как надо организовать данные, чтобы алгоритм работал максимально эффективно. Причем положение данных позволяет выполнять обработку большинства алгоритмов намного быстрее, чем если бы граф находился в произвольном состоянии.
Безусловно, текущий алгоритм это совершенно новый и намного лучший алгоритм, чем был ~5 лет назад, опубликованный мной.
На счет моделирования — надо понять какой процент от общего времени занимают переходы и для чего при переходе использовать BFS ?
Присоединяюсь к поздравлениям. Времени убито гораздо больше, чем у меня =) Но, возможно, оно того стоит.
Здесь это тоже хорошо смотрится) особенно для тех, кто ищет реализацию из поисковиков.
Алгоритм не может быть точным или не точным. Алгоритм фильтрации либо корректный, либо не корректный. Последний Алгоритм 3 вообще не правильный, так как он не даст корректного результата. На счет 2го — вопрос.
а применить то как median_5 к нахождения медианы в квадрате 5х5?
специально для этого комментария в статье присутствует уточнение. На данный момент нет фиксированной скорости передачи данных между ГПУ и ЦПУ. Также в данном направлении постоянно идет развитие. К примеру, сейчас есть стандарты PCIe 2.0/3.0 и готовится к релизу 4.0. Скорость у них вполне себе известная, для 2.0 — 8 ГБ/сек, для 3.0 — 15ГБ/сек. И я думаю не трудно посчитать самому сколько это будет передаваться. Другое направление — NVlink со скоростью порядка 40-80 ГБ/с.
Но как бы ни была быстра шина между ГПУ-ЦПУ, скорость работы ГПУ все равно будет быстрее и если посмотреть текущие тенденции развития ГПУ и ЦПУ, можно заметить, что ГПУ повышает вычислительную мощность с каждым новым поколением гораздо больше, чем ЦПУ.
Ну и в данном случае предполагалась либо потоковая обработка, либо последовательность фильтров или обработки изображения. Ясное дело, что только одну картинку обрабатывать на ГПУ нет смысла, да и написано это все было ради того, чтобы показать простоту разработки под ГПУ, по отношению к использованию AVX.
а amd_median5 или amd_median7 там есть? И на сколько мощный там ГПУ? + вы не учитываете, что там обращения идут в ЦПУшную память, которая очень медленная.
В данной статье тестируется 300к матриц размером 4х4, я думаю, что на ГПУ это будет тоже быстро. Могу попробовать оптимизировать такое легкое ядро ради интереса (если это вам интересно конечно).
Раз уж я пишу про CUDA, то имею право использовать вендорно зависимые функции. Вы лучше не просто так ссылки пишите, а приведите пример производительности всего того, что упомянули. А так — это голые слова.
На счет буфера А ничего не понял. Может быть имелось в виду то, что повторные загрузки, начиная со второй линии не повторяются — так это и так оптимизируется компилятором и для этого не надо уродовать код.
Про pragma unroll и так было сказано, а описанные вами оптимизации компилятор сделает и так.
Если вы думаете, что тернарная операция сработает быстрее if, то советую обратиться к профилировщику. Видимо для AMD и openCL еще не придумали нормальных инструментов. А вот у Nvidia все по человечески.
Кому нужны ваши 5%? Если бы это были разы, то другое дело.
Если очень интересно реально то показать, то напишите ваш очень оптимизированный код на openCL и запустите на ГПУ Nvidia и посмотрите что получится.