D
я просто сравнил время выполнения xor от 1000 байт
Size: a a a
2020 August 12
D
в 8ми разрядной и 32 раздяной математике
D
в 4 раза быстрее
D
понятное дело xor я тоже брал 32х разрядный
BV
D
так объясните мне почему алго 32 работает с каждым байтом отдельно?
D
если версия 32х битная
MS
так объясните мне почему алго 32 работает с каждым байтом отдельно?
Какой алго
D
D
вот это зачем нужно:
(Te4[(temp >> 16) & 0xff] & 0xff000000) ^
(Te4[(temp >> 8) & 0xff] & 0x00ff0000) ^
(Te4[(temp ) & 0xff] & 0x0000ff00) ^
(Te4[(temp >> 24) ] & 0x000000ff) ^
(Te4[(temp >> 16) & 0xff] & 0xff000000) ^
(Te4[(temp >> 8) & 0xff] & 0x00ff0000) ^
(Te4[(temp ) & 0xff] & 0x0000ff00) ^
(Te4[(temp >> 24) ] & 0x000000ff) ^
D
это же побайтная обработка!
A
потому что это эквивалентно побайтной обработке, но на реальных процессорах вполне могут оказаться инструкции, которые ровно вот это делают совсем иначе
A
например на powerpc я видел инструкцию "сделать сдвиг и наложить маску". Тогда тут было бы четыре вызова этой инструкции плюс ксоры. Но эта инструкция принимает 32-битное слово, а не один байт
D
потому что это эквивалентно побайтной обработке, но на реальных процессорах вполне могут оказаться инструкции, которые ровно вот это делают совсем иначе
по твоему мнению тут оптимизация очевидна по сравнению с 8ми битной версией?
D
вот она
A
В данном случае она по крайней мере не хуже наивного побайтного подхода.
D
а именно?
A
я просто отталкиваюсь от своего опыта, когда я видел реализацию strlen для юникодных строк. Наивная реализация это просто пройтись по байтам, оптимизированная это неоновские интринсики для векторных операций.
A
но для векторных операций помимо собственно работы требовалось также сначала инициализировать нужные данные, а в конце выгрести результат. В итоге экспериментально было получено, что для строк длиной менее 13 байт наивная реализация работает быстрее