Это понятно, и если данные будут отсортированы хотя бы по первому значению, это уже значительно упростит поиск вне зависимости от выбора хранилища, особенно если разделить данные по этому признаку (к примеру - разные файлы, или для СУБД - разделы)

Ой, блин, сорри... 
Да, я реально помешан на этом синхронайзе=(
Убрал все обращения к форме, убрал секцию синхронайз...
Теперь 34Кб данных (3000000 одиннадцатибайтовых чисел) генерируются за 2.8 секунды! 34 года надо разделить на 500   

Вы так и не опровергли мои расчеты   
Если исходить из Ваших скоростей "генерации" 11-байтных значений, то в создании базы нет смысла - проще использовать "онлайн"-расчет.

Это сообщение отредактировал(а) kami - 15.1.2014, 12:43

Плюс еще разделить на количество компов, хозяева которых просто не дождутся когда придется считать 
В принципе если уменьшить базу до 5 терабайт(способом который я описал выше),  уже можно хотя бы делать онлайн базу, что честно говоря не очень бы хотелось, ну и как поведет себя сервер с поиском если например будут одновременно 100-500 запросов.
Так что все таки придется изучать эти rainbow tables

Добавлено через 4 минуты и 19 секунд

Не совсем понял про что вы, но создание базы пусть хоть и займет много времени, но создавать она будет только один раз.
Потом только поиск по ней, а это уже в разы быстрее.


Это сообщение отредактировал(а) кмс - 15.1.2014, 12:46

kami, я не спорю, потому как не знаю скорость поиска по такой базе... Вполне возможно, что искать будет дольше, чем генерировать.
Я просто говорил о том, что сама генерация не займет 34 года. Гораздо, гораздо меньше.

Осталось собрать RAID на 11Тб

Это сообщение отредактировал(а) boobie - 15.1.2014, 12:55

Да как поиск может занять больше времени чем генерирование?
Наоборот на много быстрее.

Смотря как его реализовать   

Да даже если вести поиск простым перебором по базе, все равно быстрее.

Легко. Время поиска зависит от объема данных (тут вступает в силу организация хранения данных и сами алгоритмы поиска, но тем не менее - зависит).
А вот генерация чаще всего имеет стабильное время на одно значение (ок, в Вашем (кмс) коде это не так).

Дело в не организации поиска. Генерация пусть хоть и имеет "стабильное время на одно значение", но оно отнимает слишком много времени на расчеты.

Добавлено @ 13:25
Там же не просто генерируются случайные значение, а именно идут расчеты при двух входных параметров каждый по 5  байт. А так как на выходе мы имеем результат из 3 байт, то получается не очень маленький процент совпадений, по этому приходится считать по 2 раза(один из входных параметров меняем). В итоге получаем что для одной записи в базу нужно вести 2 расчета.

Это сообщение отредактировал(а) кмс - 15.1.2014, 13:27

Какой то у вас полупредметный разговор выходит.

кмс, напиши, сколько времени уходит на одну генерацию. Минимум, максимум, в среднем (чаще всего).

Агрох, я чуть выше выложил прогу, там можно примерно посмотреть сколько ведется расчет.
Там нету сохранения в файл, просто чистый расчет.

Добавлено @ 13:40
Вот перебор 10000 значений.

4 ядра, 4 потока, проц i5

для 100000


Это сообщение отредактировал(а) кмс - 15.1.2014, 13:42

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

UPD. Только учтите, что индексы увеличат объем базы, так что к первоначальным 5Тб (я про "сокращенный вариант базы) добавится еще ... а вот сколько - зависит от СУБД. 

Это сообщение отредактировал(а) kami - 15.1.2014, 14:17

 не проще бесплатную радужную таблицу скачать ?
типа такого http://www.project-rainbowcrack.com/table.htm

Это сообщение отредактировал(а) DYUMON - 18.1.2014, 17:25