Немного об оптимизации кода путем «свертки»

[middle]

Свертка? Или щелевая оптимизация (peephole optimization)?

[Dukarav]

В данном случае, на мой взгляд, "щелевая" - это как анализировать, а "свертка" - это что делать. Команды ведь не выбрасываются, а лишь вкладываются друг в друга как матрешки.

[middle]

Щелевая оптимизация меняет определённые паттерны команд на более оптимальные. Выбрасывать при этом не обязательно.

[Panzerschrek]

Интересно, но выглядит, как экономия на спичках.

Такого рода оптимизации, кстати, могут даже оказаться контпродуктивны (или наоборот), из-за того, что изменившийся код как-то иначе в памяти раскладывается, границы кеш-линий меняются и т. д.

[Dukarav]

Поскольку расположение кода относительно кэш-границ довольно-таки случайное, для объемных программ будет плюс-минус то же самое: где-то улучшится, где-то ухудшится.

Выигрыш в объеме невелик, зато и затраты в компиляторе мизерные. А так - здесь полкилобайтика сократили, там сократили, глядишь - в программе дописали новую возможность, а ее объем стал меньше, чем раньше. Очень приятно, и так год за годом ))

[orefkov]

Сейчас все наоборот стараются побольше инлайнить, а у вас наоборот. Возможно для каких-нибудь микроконтроллеров, где память ценный ресурс, имеет смысл. А так - ваш mov cx, 1 который вы вынесли в call, в большинстве случаев был бы бесплатным, проц бы его спараллелил с другими инструкциями. А в таком виде увы.

[Dukarav]

проц бы его спараллелил

А что мешает распараллеливать уже внутри вызова? Там же не сразу этот регистр требуется:

PUBLIC ?QB081:                  ;ВЫЗЫВАЕТСЯ ИЗ PL/1
      MOV       CH,1

PUBLIC ?QB08C:                  ;ВЫЗЫВАЕТСЯ ИЗ PL/1
      MOV       BH,AL           ;СТАРШАЯ ЧАСТЬ ЗНАЧЕНИЯ БИТОВОЙ СТРОКИ
      XOR       BL,BL           ;МЛАДШЕГО БАЙТА НЕТ
...

Сейчас все наоборот стараются побольше инлайнить

Ну и зря. В современных условиях стоимость обращения к памяти все время возрастает относительно времени выполнения команд.

Но многим кажется, что ладно данные, но уж следующие команды-то успеют скачаться, пока очередные скачанные команды выполняются. А это не факт. Поэтому уменьшение кода существенней влияет на быстродействие, чем раньше.

[marsianin]

А теперь давайте считать, сколько обращений в память и арифметики требуют инструкции call и ret, как предсказываются переходы, и какое влияние всё это оказывает на исполнение кода. Нет, серьёзно, в Intel и AMD работают весьма грамотные инженеры, которые к тому же имеют доступ к деталям реализации процессоров. Так что платформоспецифичные оптимизации для x86 никто лучше них не реализует. Достаточно посмотреть, какой код генерируют GCC и llvm, для которых x86-специфичные вещи разработаны инженерами Intel, чтобы отпало всякое желание экспериментировать с 8 и 16-битной арифметикой, выравниванием, уплотнением кода, etc.