Гибкий разум

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

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

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

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

Описанные ранее знания абсолютно необходимы для достижения любой из целей программирования на ассемблере. Но эти знания не могут за вас встретить необходимость написать код, который соответствует требованиям приложения и работает настолько эффективно, насколько это возможно в среде PC. Знание делает это возможным, но происходит это благодаря вашим навыкам программирования. Именно эта интуитивная, мгновенная интеграция спецификаций программы и моря фактов о PC является сердцем оптимизации ассемблера Дзен-класса.

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

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

Простая логика диктует, что никакой компилятор не может так много знать о назначении фрагмента кода или так хорошо приспосабливаться к его потребностям, как человек, который этот код пишет. Обладая большей информацией и большей приспосабливаемостью, программист на ассемблере может создавать лучший код, чем компилятор, тем более что компилятор ограничен рамками языка высокого уровня и процессом преобразования из языка высокого уровня в машинный язык. Следовательно, тщательно оптимизированный ассемблер, это не только выбранный язык, но и единственный выбор для кода, — обычно занимающего от 1 до 10 процентов общего объема кода программы, и состоящего из небольших, хорошо описанных процедур, — который определяет общее быстродействие программы, и единственный выбор для кода, который должен быть настолько компактен, насколько это возможно. Не имеет смысла бесплодно тратить силы и время на написание оптимизированного ассемблерного кода для обычных, не критических по времени частей ваших программ — вместо этого сосредоточьте усилия на циклах и аналогичных фрагментах; но в тех областях, где необходимо превосходное качество кода, никакие замены не допускаются.

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

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

С чего начать?

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