Считаю, что прозвучавший внутри сайта комментарий заслуживает вынесения на главную страницу. Как и вообще, целочисленные приложения на 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 получилось несколько веселее.
Comments
А теперь BarsWF работает и на AMD
GTX280: 721 Mhash
4870: 1260 MHash :-)
Поздравляю MikeMonster'a. Очень хорошая утилита получилась. Практически максимум из карты выжимает.
круто! а это на дуальной (X2) или на обычной 4870?
Это на обычной. Пока несколько карт поддерживается крайне криво (1 приложение - 1 карта), но это обещают поправить в следющем релизе SDK
Дорвался до 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 - 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 - мне не кажется разумным (если я правильно догадался как увас запускается 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 block - ровно столько сколько указывается параметром
Просесть может когда не попадает обновление экрана и завершение вычисления очередного вызова kernel, обновление асинхронное 2 раза в секунду.
По моим ощущениям, если сделать двумерный grid, чтобы можно было делать реально много блоков (тысячи), то будет счастье. Сами блоки, конечно, должны считать поменьше при этом.
Разумное количество блоков - несколько тысяч. Как я понимаю, у вас к global memory ходить незачем, латентность вы тут не спрячете, но планировщику реально лучше от большого числа блоков.
Впрочем, я сужу по задачам, которые используют global memory.
Ну, двумерный грид 100x100 = одномерный 10'000 так что дело не в размерности, а просто в кол-ве блоков :-) Если уменьшать работу на блок сильно выростет объем работы с глобальной памятью.
Ну так у меня не получается задать одномерный больше чем 512 с большим количеством тредов. С малым - 32t/513g создается, но считает фигню.. Где-то у вас что-то не то.
Версия - 0.7
А про глобальную память не понял - вы оттуда что берете? Казалось бы, там совсем немного данных (диапазон для перебора), это все не должно быть заметно.
Так больше 512 надо грид а не тред.
В смысле фигню? Медленно?
а 224t/512-1024г что получается?
Да, оттуда только диапазон, но даже одна операция чтения - это операция :-) И делать её в 30 раз чаще нехорошо ИМХО :-)
Экстраполяция с 9600GT показывает что должно быть 672 MHash на GTX280
ну nvidia рекомендует тысячи блоков и по моим ощущениям они правы.
Что касается нескольких чтений - их действительно несколько, это будет не видно, причем там же можно схитрить с текстурным кэшом или с constant memory
А 672 мегахэша - это хорошо, но хочется больше. У меня же своя - 8800gtx и я надеялся в 224/128-х больше получить (правда частота чуть ниже)
441 тактов на само вычисление, это получается 224*1296/441 = 658 MHash/sec, что близко к практическому результату. "У меня же своя - 8800gtx и я надеялся в 224/128-х больше получить" - так вроде так и получается особенно если учесть частоту у 280 1296Mhz. По крайней мере если я экстраполирую свою 9600GT, то получается на GTX280 в соответствии с расчетом.
BarsWF - это крайне частный случай вычисления MD5 (кто в теме, тот поймет). Так давно уже никто программы не пишет, жестко вшит брут (последовательный неразрывный интервал) в код вычисления MD5, поэтому и быстрее "конкурентов". Практической ценности не представляет. В качестве курсовой работы весьма неплохо.
Ну я не знаю, вшит или не вшит, но в качестве практического теста по подбору паролей по реальной базе (без salt, что конечно ошибка приложения от которого база) - сработал отлично.
Понятно, что совсем практическая реализация должна еще уметь
- принять md5 списком
- суметь поделить работу на N машин
Ну так такое уже за деньги продается.
Это планируется в версии 1.0, которая будет иметь CUDA код, генерируемый на лету :-)
И работа над распределенной версией тоже идет, но это будет не standalone версия, а аналог freeranbowtables.com - рапределенный супер компьютер с тысячами(надежда умирает последней) нод. :-)
Неверно. Не знаем - не говорим :-)
Ни чарсет, ни интервал не вшит, все передается как положено с каждым вызовом.