А затюнингованная под камень прога работает чуть медленней даже, чем женерик код. Чо за хуйня?

Думал вздрючить гэцэцэ, налабав ядро той задачи на асме. Компилятор ведь железный, читай, тупой.

Переписал ядровую функцию на асме. И раз в моём проце добавили специализированные битовые инструкции, заюзал их. Конкретно BEXTR из BMI. Особые инструкции это ведь круто и быстро, не так ли?

Хуяк - в 2 раза медленнее, чем gcc. Блядь, чо за хуйня? Смотрю, что гцц сгенерил, и вижу, что он не использует никакого BMI, хотя тюнинг под нативную архитектуру включен.

Пиздец, нахуя нужны эти специализированные наборы команд? Если они работают медленней, чем эквивалентный набор женерик команд? Эти, блядь, маркетологи валят и валят новые наборы в процы. Похоже, это больше чтоб очки втирать гикам. Типа, наш новый проц поддерживает новый набор, всё выше, быстрее, сильнее. А на деле хуйня выходит. Ёбаная реклама и лапша на уши, сука.

Ладно, переписал на женерик битовые шифты. Быстрее, да. Но не быстрее, чем gcc. В полтора раза медленней. Бляяяядьь. Опять втыкаю в дизассемблер (ну, точнее, в gcc -S), сравниваю. Нету разницы! Только, блядь, порядок инструкций. В общем, сосанул у gcc - робот победил человека.

Скорее всего, гцц знает (интересно, по результатам экспериментов или по мануалам на процы, или у них кооперация с АМД?) как надо под out of order execution оптимизировать. Ёбаный OoOE, даже малейшее переставление инструкций играет роль. Ёбаные современные процы с их пайплайнами, не поймёшь ни хрена. Разве что 5 тысяч страниц мануалов их прочесть. И то, не уверен, что OoOE полность описан, скорее всего, коммерческая тайна.