Цена невежества

Сколь прилежен не был автор, он совершил основной грех программирования на языке ассемблера x86: предположил, что доступная ему информация и правильная и полная. Хотя время выполнения инструкций, указанное Intel для своих процессоров действительно правильно, эта информация неполная; другая, и зачастую более важная, часть быстродействия кода — это время выборки команды, тема к которой я вернусь в следующих главах.

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

		Здесь вы видите важный принцип оптимизации ассемблера: после создания наилучшего из возможных вариантов кода, проверьте его в действии и убедитесь, что он действительно работает так, как вы думали. Если код ведет себя не так как ожидалось, из этого тоже можно извлечь пользу — решение загадок это путь к знанию. Ручаюсь, что таким образом вы узнаете гораздо больше, чем из любого руководства или учебника по ассемблеру.

Ничего не предполагайте. Я не могу подчеркнуть это достаточно настоятельно — если вы заботитесь о быстродействии, старайтесь улучшать код, а затем измеряйте улучшение. Если вы не измеряете быстродействие, то вы всего лишь предполагаете, а раз вы предполагаете, то, скорее всего, вы не сможете написать первоклассный код.

Невежество об истинном быстродействии может обойтись очень дорого. Когда я писал видеоигры, то тратил целые дни, пытаясь выжать максимум быстродействия из своих графических драйверов. Я переписывал целые блоки кода только для того, чтобы сохранить несколько тактов, манипулировал регистрами и полагался на обманчиво быстрые сдвиги и сложения с операндами в регистрах процессора. Во время написания последней игры я обнаружил, что программа выполняется значительно быстрее, если для вычислений вместо сдвигов и сложений применяются таблицы просмотра. Согласно моему подсчету тактов такой вариант не должен был работать быстрее, но он работал. По правде говоря, как это часто бывает, во всем опять оказалась виновата выборка команд. В моем случае выборка команд сдвигов и сложений занимала в четыре раза больше времени, чем их исполнение.

Невежество может также привести к пустой трате значительных усилий. Я вспоминаю дебаты в колонке писем одного компьютерного журнала, посвященные тому, насколько быстро можно выводить текст в видеоадаптере CGA без возникновения видимых помех. Как и в истории, которой начиналась эта глава, авторы письма считали каждый такт в своих циклах синхронизации. И точно также они не приняли во внимание очередь предвыборки. Фактически, они также пренебрегли эффектами состояний ожидания видеоадаптера, и обсуждаемый код был намного медленне, чем их оценки. Необходимым испытанием, конечно, является запуск кода, чтобы увидеть прекратились ли помехи, поскольку единственной истинной мерой быстродействия кодя является наблюдение его в действии.