Уважаемые коллеги, Обратил внимание на непонятную мне хрень. Взял вручную, побитно посчитал CRC32 с полиномом 4C11DB7 - результат не сходиться с тем что дают поблочные алгоритмы??? смотрите, например, байт 81h (вся строка 1 байт) при зеркальном алгоритме с полиномом EDB88320h должен указывать на ячейку в таблице с предрасчитанными CRC32 на значение EC63F226 (при прямом на 644FC637), а он указывает на 0B7BD5C3Bh и в результате ЦРЦ получается 48BD5C3Bh, чёта никак не вкурю? Разве ЦРЦ 81h д.б. = 48BD5C3Bh? Строка с 1-м нулевым байтом походу должна давать полином, а даёт хрен знает что? Растолкуйте тупану пачиму так?
Научись для начала сам создавать эти таблицы, а не бери готовые. Откель потвоему они берутся? Вот как рзз и делят байт*2^32 на полином.
Непонял, причём здесь "создавать таблицы"? Вопрос не в таблицах, вопрос почему ЦРЦ 81h = 48BD5C3Bh при табличном алгоритме. Т.е неполучается у меня вручную, на бумашке, насчитать ЦРЦ 48BD5C3Bh для 81h никаким образом... Понимаете?
У меня получилось, что 81h ячейка должна содержать 9ABFB3B6 =))) 00000040 xor EDB88320 = EDB88360 03B6E20D xor EDB88320 = EE0E612D 77073096 xor EDB88320 = 9ABFB3B6
Круто, но всиравно непонял почему первый раз 00000040 ???? Можешь так же расписать но с прямым вариантом (т.е. с полиномом 4C11DB7)?
Смотри, щас придут модеры и мувнут тебя в beginners! =))) Самое прикольное, что CRC32 можно ускорить зарелизив его не с одной таблой, а с четырьмя или даже восемью таблицами! С четырьмя таблицами я зарелизил и получил прирост раза в три, а с восьмью я оставил для автора 7zip'а. Не в скорости щастье у crc32!
persicum А в SSE4 так вообще команда есть : CRC32, не знаю правда сколько тактов, но наверное меньше чем таблички глядеть. Вообще красота.
