Насколько быстрее встроенная реализация криптографических хэшей в Windows, чем версия .Net Managed?

Я предоставляю хеши для наборов данных, чтобы отпечатать данные и идентифицировать их с помощью хэша - это основной вариант использования быстрых хэшей, таких как SHA1 и MD5.

В .Net есть возможность пойти с родными или управляемыми реализациями некоторых из этих хэшей (варианты SHA, во всяком случае). Я ищу управляемую MD5 реализацию, и, похоже, она не существует в .NET Framework, но задавалась вопросом, будет ли завершенный собственный CSP в любом случае быстрее, и если я просто буду использовать его контент, проблемы с его использованием. Ответ на Почему нет управляемой реализации MD5 в .NET Framework? указывает, что более высокая производительность может быть причиной того, что управляемый вариант не существует.

Это правда, и если да, то насколько быстрее будет собственный CSP?

Ответ 1

К сожалению, обернутый собственный CSP для MD5 - MD5CryptoServiceProvider - значительно медленнее, чем чистая управляемая реализация. Это упорная точка зрения, которая утверждает, что собственный код недвусмысленно быстрее управляемого кода: во многих случаях верно обратное. Это такой случай, по крайней мере, в измерениях "голова к голове".

Используя переведенную ссылку MD5, сделанную Дэвидом Ансоном, я построил быстрый тест производительности (источник), целью которого является измерение любых больших различий в производительности между двумя реализациями. В то время как для небольших массивов данных разница незначительна, как и ожидалось, примерно в 16 кБ, нативная реализация начинает показывать потенциально значительную задержку - порядка миллисекунд. Это может показаться не очень большим, но на порядок медленнее, чем чисто управляемая реализация. Эта разница сохраняется по мере увеличения размера хэшируемых данных, а в самом большом массиве данных - ~ 250 МБ - разница в времени процессора составляет около 8,5 секунд. Учитывая, что хеш, подобный этому, часто используется для отпечатки очень больших файлов, эта дополнительная задержка станет заметной даже против часто значительно больших задержек от ввода-вывода.

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

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