Добрый вечер всем. Придумал я велосипед (криптографический естественно, дасть Бог еще много таких напишу), чтобы его превратить в респектабельный програмный продукт, необходимо его описать и документировать, рекламировать. Главный вопрос - как оценить скорость работы моего монстра и основных конкуренов. Только фишка в том что скорость не в Мб/с, ибо она на разных машинах будет разная, и нечто вроде количества тактов процесора необходимого для шифрования одного кило/мегабайта. Этот вопрос не является новым, я пытался найти инфу в интернете, но находил услуги разных центров, и разный специализированный софт. А как сделать это в доашних услвиях подручными средствами. Была авангардная идея, анализировать программы конкурентов отладчиком, ставить бряки на кнопки и тд, потом вспомнил что софт скорее всего упакованый, а распаковывать, модифицировать -дело трудоемкое. Жду ваших идей господа. Огромная просьба депресивные замечания, вида -зачем оно тебя надо, или твой софт -пурга и тд, оставить за пределами этой темы.
А количество тактов будет различаться на разных типах процессоров. Так что -- именно мегабайты в секунду на одинаковой конфигурации железа.
Просто интересно: как в отладчике можно оценить скорость шифрования (да вообще какую либо скорость)? Замерять время между двумя бряками?
можно пропатчить, и сделать джамп на свой таймер в начале и конце. -------- а скорость можно определить просто протестировав всё на одной машине. та прога которая быстрее всех справилась с заданием та и быстрее...
rodger: тут на днях Enrupt оптимизировали, посмотри на форуме. Там и пример кода на С++ есть. Идея простая: замеряешь время, делаешь много-много циклов зашифровки известного количества данных, замеряешь время. Количество зашифрованных байт поделенное на время и будет твое искомое значение.
предпочитаю еще то, что между вызывами таймера, обернуть в цикл на несколько десятков тысяч/сотен тысяч оборотов
Береш огромный файл 2-4 Gb шифруеш его и замеряеш время. Для заданного железа. А такты приводить в рекламе блажь ... Юзверь обычный вообще может и не знать что такое такты. Да и опять же такт такту рознь возьми 8086 и Duo Core. Количество кеша и его частота + частота шины + тип чипсета все это может сильно влиять.
Только поаккуратней с шифрованием больших файлов. Тут кто-то пытался md5 померить для большого файла, так там происходило что-то типа кеширования. И при повторном вычислении скорость возрастала более чем в 4 раза afair
rodger Мерять и сравнивать скорость шифра даже сложнее, чем его сделать. До сих пор нет никакого согласования. Пользователям интересно знать килобайты в секунду, а академикам нужны такты. Разница при этом гигантская в зависимости от процессора, его скорости, типа памяти, её скорости, размера кейша, его скорости, компилятора, его настроек, inline это код или отдельная функция, даже от её положения в программе зависит... Мерять надо много раз, отбрасывая всплески слишком медленных измерений – это другие процессы и прерывания пакостят. Надо обязательно указывать все эти детали – как и на чём мерял. Килобайты в секунду из тактов легко посчитать, а вот такты из килобайтов никак, поэтому считай такты на байт. Самый надёжный способ – меряешь шифрование случайных входов много раз через RDTSC между вызовами, отбрасывая все измерения, которые очевидно слишком медленны (больше 100 тактов на байт например), и считаешь среднее. Затем меряешь то же самое точно так же, только шифруя 2 раза. Опять считаешь среднее и вычитаешь разницу между двумя значениями – получишь скорость самого шифрования не считая стоимости измерения. Сами вызовы RDTSC и их обработка добавляет около 70-120 тактов – их надо отрезать. Я лично люблю сохранять все измерения в таблице и считать какое сколько раз встречается чтобы было видно сколько именно тактов оно занимало и вероятность всех разных измерений. Желательно чтобы больших отклонений не было. В лучшем случае получится 1-3 разных измерений со стабильной вероятностью, если только в шифре нет сдвигов по данным как в RC5 или таблиц как в AES – тогда отклонения будут огромные в зависимости от входных данных [что позволяет ломать шифр через cache attacks и т.д.]. Я ещё согласен с подходом Даниела Бернштайна, который включает загрузку ключа и считает скорость шифрования 1 блока, двух, трёх и т.д. до длинного потока и строит кривую. Тогда хорошо видна стоимость шифрования маленьких пакетов в сравнении с длинным непрерывным потоком. Загрузка ключа в большинстве шифров очень дорого обходится. Её нельзя игнорировать. А файлы шифровать – это оставь пользователям играться после того как шифр отлажен, опубликован, проанализирован и уже в использовании.
rodger можешь указывать коэффициент относительно известных сиферов (кстати, хорошо тестить скорость на заведомо слабой машине). но вообще - то на эту тему можешь особо не заморачиваться: скорость зависит от конкретной реализации алгоса, а вот самый важный вопрос, на который за частую не способен ответить и разработчик, надёжность шифра
Спасибо всем за внимание и информацию, узнал много нового. Пока думаю так -поставить под виртуальной машиной Винду без антивируса и прочих ресурсоемких приложений, так сказать в базовой комплектации, и там тестировать разные программы.Нужно вспомнить статистику. Вспоминаю много лет назад, один знакомый написал свой архиватор, алгоритм Хафмана использовал, и чуток его модифицировал, а потом защищал это в качестве научной работы. Сравнывал его с распространенными архиваторами. Так его архиватор отставал буквально на пару процентов от Винрара и Зипа. Так ему сказали а где статистическая характеристика исследований? Обьем выборки? Погрешности и тд? Пока собираю колекцию программ конкурентов, а также изучаю рейтинги популярности.
Ruptor 2 раза нельзя - начнется эффект кеширования. Надо просто выключить шифрование и получим "накладные расходы" в чистом виде.
