0ralo,
1. Нет, не правильно. В реальной жизни в си будет как минимум -O2 стоять.
Хотя если ты ставишь целью сравнить именно поведение в стоке, то можно и так, но ценность такого бенчмарка будет стремиться к нулю.
Это всё равно что делать сравнение скорости легковушки и болида формулы и говорить, что легковушка быстрее из-за того что болид на дороги общего пользования не пустят.
Оптимизации по умолчанию не включены из-за того что они требуют много ресурсов и времени компиляции и при этом не нужны на этапе разработки.
А ещё может быть в каком-то древнем компиляторе их и вовсе не было, а по тому и в новых версиях по-умолчанию их нет (для обратной совместимости)
xotkot, в данном случае никакого распараллеливания не будет в го, даже если будет запущено несколько потоков.
Выигрыш в скорости исключительно из-за выключенных в си оптимизаций
Drno, если условный злоумышленник получил доступ к диску, то он вырежет sleep, дабы ускорить подбор нужного пароля => для реального усложнения надо по честному увеличивать необходимое количество вычислений
Если криптографически, то можно взять хэш пароля и от него потом хэш много-много раз.
Тогда при проверке придётся это повторить.
+ можно взять какой-нибудь алгоритм хэширования, который долго считается.
Это только вариант, как это можно сделать. В исходники keepass не смотрел
0ralo, у go мало флагов (вроде нельзя вообще оптимизации включить/выключить)
В случае си я бы не сказал, что это минус, так как все си-программисты и так знают об этом. Поменять поведение нельзя, так как обратную совместимость нужно поддерживать.
Просто прежде чем писать бенчмарки - нужно ещё хотябы теоретическую базу какую-то знать.
А выигрыш в 400 раз выглядит как аномалия. Покажешь?