Оптимизация кодов для любого языка всегда заставляет идти на компромиссы. Такими компромиссами являются:

1) сокращение используемого объема памяти в результате снижения быстродействия;

2) увеличение быстродействия в результате ухудшения возможностей сопровождения и доступности текста программы для чтения;

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

следующая требует больше времени, чем предшествующая. Рассмотрим эти операции: регистр/регистр, операции с памятью, операции с диском и операции взаимодействия с пользователем. Так что не стоит тратить силы на сокращение нескольких машинных циклов в программе, когда скорость ее исполнения ограничена операциями обращения к дисковым файлам. Взамен можно применить сокращение числа таких операций. А после выполнения того, что, в принципе, могло бы быть оптимизацией, следует осуществить тщательную проверку полученных результатов.

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

Если программа удовлетворяет всем приведенным критериям, то на самом деле ее объем и скорость выполнения чаще всего будут вполне приемлемыми без каких-либо дальнейших усовершенствований. Но только применение ассемблера само по себе приводит к повышению скорости выполнения программы в 2–3 раза и примерно к такому же уменьшению размера по сравнению с такой же программой на языке высокого уровня. Кроме того, если что-то делает проще чтение программы и ее сопровождение, то обычно при этом увеличивается скорость исполнения. Можно отказаться от «макаронных» кодов со многими ненужными переходами и вызовами подпрограмм, а также предпочтение простых прямолинейных машинных команд похожим сложным.

Кроме того, самой главной заботой должны быть ощущения потенциального пользователя при работе с данной программой: насколько производительной покажется программа ему? Если о полученной программе складывается мнение, как о неуклюжей, то есть вероятность, что она не будет должным образом оценена. Примером является судьба пакета ToolBook.

Для операции умножения и деления необходимы значительные усилия от почти любого центрального процессора, так как они должны быть осуществлены (аппаратно или программно) через сдвиги и сложения или сдвиги и вычитания соответственно. Традиционные 4-разрядные и 8-разрядные процессоры не имели машинных команд для умножения или деления, так что данные операции приходилось осуществлять при помощи длинных подпрограмм, где явно осуществляются сдвиги и сложения или вычитания. Первые 16-разрядные процессоры, среди которых 8086, 8088 и 68000, действительно дают возможность осуществить операции умножения и деления аппаратными средствами, но соответствующие процедуры были очень медленными: в процессорах 8086 и 8088, например, для деления 32-разрядного числа на 16-разрядное было необходимо около 150 тактов.

Поэтому небольшие хитрости для увеличения скорости или устранения операций умножения и деления были и остаются одними из первых приемов, которые рассматривает каждый программист, который стремится к совершенству. Большинство из данных хитростей относится к категории, которую именуют «отказ от универсальности». Это замена рассчитанных на общий случай команд умножения и деления (или вызов соответствующих подпрограмм) рядом сдвигов и сложений или вычитаний для конкретных операндов.

Рассмотрим одну из простых процедур оптимизации умножения. Для умножения числа на степень двойки его следует просто сдвинуть влево на необходимое число двоичных (битовых) позиций. Вот такой, например, имеет вид некоторая общая, но медленная последовательность команд для умножения значения переменной MyVar на 8:

mov ax,MyVar mov bx,8 mul bx

mov MyVar,ax

Применение отказа от универсальности при выполнении деления несколько более ограничено. Деление на степень двойки, безусловно, очень просто. Для этого следует сдвинуть число вправо, следя только за выбором соответствующей команды сдвига для желаемого типа деления (со знаком или без знака). Определение остатка от деления на степень двойки для чисел без знака еще проще. Для этого следует осуществить просто одну команду операции логического И над операндом и непосредственным значением, которое должно быть записано в виде уменьшенного на единицу значения делителя. Деление чисел со знаком не так просто, так как знак остатка от деления должен соответствовать знаку делителя и не зависит от знака делимого. Реализация данных операций потребует непременного присутствия условных переходов, а это уже плохо.

Программы, которые изобилуют ветвлениями и переходами во всех направлениях, нежелательны во всех смыслах, а в случае работы с процессорами серий 80 х 86 и 80 х 88 – особенно. Это является напутствием, цель которого – побудить программистов на ассемблере и тех, кто оптимизирует компиляторы, должным образом структурировать программы. В этом случае существуют свои проблемы, но сначала рассмотрим некоторые особенности процессоров фирмы Intel.

Быстродействие данных процессоров в значительной мере зависит от их архитектуры, основанной на простой конвейерной схеме, которая содержит три компоненты: шинный интерфейс (BIU – Bus Interface Unit), очередь упреждающей выборки и исполнительный модуль (EU – Execution Unit). Если шина памяти в нерабочем состоянии, например в случае выполнения команды из многих циклов, с операндами, находящимися в регистрах, шинный интерфейс получает байты команд из памяти и располагает их в очередь упреждающей выборки, последовательно продвигаясь дальше от текущего расположения командного счетчика центрального процессора. Когда исполнительный модуль заканчивает выполнение очередной команды, он ищет следующую команду в ряде упреждающей выборки: если она есть, к ее расшифровке можно приступать непосредственно, не обращаясь лишний раз к памяти.