Целочисленные приложения

Считаю, что прозвучавший внутри сайта комментарий заслуживает вынесения на главную страницу. Как и вообще, целочисленные приложения на GPU, сделаю я мини-обзор по попавшимся на глаза MD5-кракерам.

BarsWF
Самый быстрый MD5 кракер, автор Михаил Сваричевский. Программа действительно необычайно быстра, когда я увидел перебор всех 8-буквенных паролей (правда на алфавите a-z) за 5 минут, а оценку времени для полного парольного алфавита всего в несколько часов - я был, мягко скажем, удивлен. Программа раздается в бинарниках, редакция данного сайта будет очень благодарна, если автор поучит всех уму-разуму (например, напишет текст с комментированными исходными текстами :).
Сравнение GPU MD5-кракеров
Сравнение интересно тем, что там есть ссылки на конкурентов
nvCuda MD5
Один из конкурентов, примерно в полтора раза медленнее, но с исходными текстами
cuMD5
Второй конкурент с исходными текстами, правда втрое медленнее BarsWF

Помимо MD5, есть и другие близкие применения, хочу обратить внимание на статью CUDA GPU as Hardware Accelerator for AES (PDF, название в сокращении). В GPU Gems 3 есть текст про ускорение AES на потоковом устройстве, но на CUDA получилось несколько веселее.

Tags: 

Comments

BarsWF - это крайне частный

BarsWF - это крайне частный случай вычисления MD5 (кто в теме, тот поймет). Так давно уже никто программы не пишет, жестко вшит брут (последовательный неразрывный интервал) в код вычисления MD5, поэтому и быстрее "конкурентов". Практической ценности не представляет. В качестве курсовой работы весьма неплохо.

Неверно. Не знаем - не

Неверно. Не знаем - не говорим :-)
Ни чарсет, ни интервал не вшит, все передается как положено с каждым вызовом.

Ну я не знаю, вшит или не

Ну я не знаю, вшит или не вшит, но в качестве практического теста по подбору паролей по реальной базе (без salt, что конечно ошибка приложения от которого база) - сработал отлично.

Понятно, что совсем практическая реализация должна еще уметь
- принять md5 списком
- суметь поделить работу на N машин

Ну так такое уже за деньги продается.

Это планируется в версии 1.0,

Это планируется в версии 1.0, которая будет иметь CUDA код, генерируемый на лету :-)
И работа над распределенной версией тоже идет, но это будет не standalone версия, а аналог freeranbowtables.com - рапределенный супер компьютер с тысячами(надежда умирает последней) нод. :-)

GTX280

Дорвался до GTX280 (не оверклоченой), получил "всего" 620 мегахэшей в секунду.
Ожидал больше.

Автору - если есть интерес, то могу что-нибудь на этом железе погонять.

Да, интерес есть, ключики

Да, интерес есть, ключики

cout << " -thread_n 128 | Might increase speed on GTX260 and later." << endl;
cout << " -grid_n 128 | Try 192, 256 for both" << endl << endl;

Пробовали? Предлагаю попробовать 224 куда-нибуть ;-)

-grid_n 224 -thread_n 224 -

-grid_n 224 -thread_n 224 - 650
-grid_n 224 -thread_n 256 - 671
-grid_n 224 -thread_n 512 - 688
-grid_n 448 -thread_n 512 - 696
-grid_n 448 -thread_n 768 - 500 (регистров не хватает?)

Но по идее, блоков вообще можно много много больше и это правильно. Или grid_n - это одно измерение квадратной сетки?

Угу, там перемножается

Угу, там перемножается получается 448*768 вызовов, в каждом штук по 500-1000 ключей, надо попробовать наоборот, thread_n кратно 224, а grid_n кратно 64-128 :-)

Насчет регистров не хватает - да :-)

ну, thread_n 224 - мне не

ну, thread_n 224 - мне не кажется разумным (если я правильно догадался как увас запускается kernel)
если на 512 производительность не падает.

t=224 g=256 - 671 мегаключ
t=256 g=256 - 672
t=288 g=256 - 690
и максимум я получил на t=608 (а дальше скачок вниз, ну да это все понятно почему)

Но что-бы чуть более предметно понять суть параметров - хочется понять про параметры вызова kernel
1) сетка одномерная или двумерная (или трехмерная?)
2) threads per block - ровно столько

Если сетка двумерная,конечно хотелось бы два параметра (grid_x/grid_y), ибо расти в квадрат раз - слишком много.

Правда с таймингами есть странность - на пустой машине (больше ничего нет разумного) может все просесть секунд на 20-30, потом вернуться обратно.

grid одномерный threads per

grid одномерный
threads per block - ровно столько сколько указывается параметром
Просесть может когда не попадает обновление экрана и завершение вычисления очередного вызова kernel, обновление асинхронное 2 раза в секунду.

По моим ощущениям, если

По моим ощущениям, если сделать двумерный grid, чтобы можно было делать реально много блоков (тысячи), то будет счастье. Сами блоки, конечно, должны считать поменьше при этом.

Разумное количество блоков - несколько тысяч. Как я понимаю, у вас к global memory ходить незачем, латентность вы тут не спрячете, но планировщику реально лучше от большого числа блоков.

Впрочем, я сужу по задачам, которые используют global memory.

Ну, двумерный грид 100x100 =

Ну, двумерный грид 100x100 = одномерный 10'000 так что дело не в размерности, а просто в кол-ве блоков :-) Если уменьшать работу на блок сильно выростет объем работы с глобальной памятью.

Ну так у меня не получается

Ну так у меня не получается задать одномерный больше чем 512 с большим количеством тредов. С малым - 32t/513g создается, но считает фигню.. Где-то у вас что-то не то.

Версия - 0.7

А про глобальную память не понял - вы оттуда что берете? Казалось бы, там совсем немного данных (диапазон для перебора), это все не должно быть заметно.

Так больше 512 надо грид а не

Так больше 512 надо грид а не тред.
В смысле фигню? Медленно?
а 224t/512-1024г что получается?

Да, оттуда только диапазон, но даже одна операция чтения - это операция :-) И делать её в 30 раз чаще нехорошо ИМХО :-)

Экстраполяция с 9600GT показывает что должно быть 672 MHash на GTX280

ну nvidia рекомендует тысячи

ну nvidia рекомендует тысячи блоков и по моим ощущениям они правы.

Что касается нескольких чтений - их действительно несколько, это будет не видно, причем там же можно схитрить с текстурным кэшом или с constant memory

А 672 мегахэша - это хорошо, но хочется больше. У меня же своя - 8800gtx и я надеялся в 224/128-х больше получить (правда частота чуть ниже)

441 тактов на само

441 тактов на само вычисление, это получается 224*1296/441 = 658 MHash/sec, что близко к практическому результату. "У меня же своя - 8800gtx и я надеялся в 224/128-х больше получить" - так вроде так и получается особенно если учесть частоту у 280 1296Mhz. По крайней мере если я экстраполирую свою 9600GT, то получается на GTX280 в соответствии с расчетом.

AMD

А теперь BarsWF работает и на AMD
GTX280: 721 Mhash
4870: 1260 MHash :-)

Это на обычной. Пока

Это на обычной. Пока несколько карт поддерживается крайне криво (1 приложение - 1 карта), но это обещают поправить в следющем релизе SDK

Поздравляю MikeMonster'a.

Поздравляю MikeMonster'a. Очень хорошая утилита получилась. Практически максимум из карты выжимает.