как сравнивать два слова без стрсмп

[Yuri Gendelman]

Munin в сообщении #1393366 писал(а):

В какой кодировке у вас исходный файл? Если что, Unicode в char не помещается.

Скорее всего ANSI 1251.

[Dmitriy40]

feedinglight в сообщении #1393352 писал(а):

Если в стеке хранить то ещё не очень плохо. Если массив где-то далеко в куче, то локальность ухудшается, а это плохо, ну там у кэша вроде всего несколько блоков-окошек в память, которые сплошные.

В любом случае таблица вряд ли превысит четверть размера кэша L2 (обычно 256К/4=64К), т.е. вся таблица займёт не более одного из четырёх ассоциативных блока. Второй блок на стек, третий и четвёртый на исходные строки, если переменные будут в регистрах, то больше обращений в память и не надо (на время сравнения строк). Собственно стек и не нужен во время сравнения строк, так что один блок кэша можно оставить на локальные переменные в памяти. Хватает, замедления не будет.

-- 16.05.2019, 17:03 --

Оптимизировать сравнение Unicode строк вообще считаю бессмысленно, т.к. там 95% времени будет получение кода каждого символа и лишь <5% займут все операции сравнения строк. Unicode символы мало того что не помещаются даже в short (16 битов), так они даже в int (32 бита) могут не поместиться - если будут комбинированными (из нескольких кодов), а не базовыми (из одного кода). И если чуть более миллиона базовых кодов ещё можно уместить в табличку, то с комбинированными табличка распухает неприлично. Конечно если делать "максимально универсально", а не ограничиться например сравнением лишь русского и английского алфавитов.

[feedinglight]

Dmitriy40 в сообщении #1393387 писал(а):

обычно 256К/4=64К

Тогда да, вроде хватит (плюс код программы ещё надо как-то считывать).

[Dmitriy40]

feedinglight в сообщении #1393390 писал(а):

плюс код программы ещё надо как-то считывать

Не надо, он весь (часть сравнения строк) поместится в 1.5К декодированных инструкций (µop cache by Intel). Плюс вряд ли процедура сравнения строк будет выравнена на границу 64К (а коды символов почти все в начале таблицы), ну или просто вряд ли совпадут (по модулю 64К) смещения процедуры сравнения и используемых символов, так что в L2 код и таблица вероятно уложатся в один ассоциативный блок. Или строки будут размещены с разным смещением по модулю 64К и тоже обе попадут в один блок. Или код и стек так попадут. Или проц с write-back L1 и код будет сидеть весь в L1I (без дублирования в общем L2).
Более того, уже давно и L1 и L2 8-ми канальные (8-ми ассоциативные), так что всё легко влезет.
Впрочем это уже ненужные в данной задаче тонкости.