Продолжая разговор о производительности

В этом блоге мы неоднократно обсуждали вопрос производительности. Да и в Интернете на этот счет написано немало. Пришло время рассмотреть этот вопрос с практической точки зрения и поведать о идеях, которыми мы руководствуемся при разработке Windows 7. Стоит отметить, что эта тема касается многих, включая и меня, поскольку в последнее время я тоже использую сравнительно маломощные компьютеры. Хотя эту статью я пишу с только что подаренного мне компьютера, оснащенного четырехъядерным CPU, дискретным графическим адаптером, 8Гб памяти и RAID-контроллером, который, к слову сказать, работает под управлением свеженькой сборки Windows 7. Авторами данной публикации являемся мы с Майклом Фортином (Michael Fortin) . --Стивен

Несмотря на тот факт, что мы еще не выпустили бета-версию Windows 7, многие уже отыскали в закоулках своих жестких дисков тестовые пакеты и приступили к оценке производительности. Мы, со своей стороны, настоятельно рекомендуем отказаться от оценки производительности тестовых сборок. Мы, конечно, ожидали, что такое может случиться и привести к тому, что пользователи могут сделать неверные выводы, поэтому крайне благодарны тем, кто неустанно напоминает энтузиастам о статусе ОС. Тем не менее, мы рады тем результатам, о которых пишут в СМИ. Хотя, стоит сказать, что мы пока не добились ранее намеченных целей, поскольку работа над фундаментальными возможностями и новыми функциями Windows 7 на текущий момент не окончена.

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

• Хочу, чтобы приложения загружались мгновенно! И без этих новомодных четырехъядерных процессоров и GPGPU!
• Если пользователям нужна скорость, то в чем же дело – дайте скорости!
• Хочу, чтобы производительность Windows 7 на моем Acer Aspire one с процессором 1.5 ГГц и 1 Гб памяти была высокой без необходимости отказываться от привлекательного интерфейса.
• Надеюсь, что в дополнение к изменениям в графической оболочке и общему увеличению производительности (поддержка многоядерных процессоров + 64-разрядные вычисления + Directx 11) Windows 7 вы доработаете функцию Flip 3d, сделав ее более эффективной.
• Надеюсь, что с точки зрения времени загрузки, скорости работы оболочки и общего удобства UI новая ОС принесет что-то новое и инновационное. Мне представился случай поработать с новым HP TouchPC и должен признать, что для первого раза вышло отлично.
• Скрещиваю на удачу пальцы, чтобы Windows 7 была в значительной степени более производительной, чем Windows Vista.
• Все, что нужно большинству пользователей – это производительность.

Как видно из сообщений, производительность для каждого пользователя имеет свой смысл. Опытные пользователи понимают, что ощущаемая и реальная производительность – это разные вещи. Я [Стивен] вспоминаю тот день, когда работал над фрагментом Windows UI в Visual C++. Тогда я решил протестировать код Visual C++ и код Borland C++. На тот момент наша реализация казалась более шустрой и отрыв измерялся секундами. Тем не менее, сетевые СМИ все время указывали, что Borland гораздо более быстрый, ссылаясь на скорость компиляции строк кода. После этого я написал небольшой счетчик, который показывал прогресс компиляции строк. С этой точки зрения мы оказались «медленнее», но при этом рецензенты начали отмечать, что наша реализация стала более грамотной. Поэтому в некоторых случаях более медленно означает более быстро.

Еще одним примером из прошлого может послужить скорость прокрутки в Microsoft Word for DOS. Билл Гейтс всегда делал упор на визуальную производительность, поэтому с его точки зрения скорость прокрутки всегда была недостаточно быстрой. Опытным программистам удалось увеличить скорость прокрутки до небывалого значения и, как следствие, мы были вынуждены искусственно ее снижать во избежание ситуаций, когда нажатие на кнопку Page Down приводило к прокрутке в конец документа. Высокая скорость – это плюс, но порой скорость бывает слишком высокой.

Основная часть отзывов показывает, что пользователи постоянно ищут, что можно было бы отключить и что поднастроить. Мы видим, что они пытаются разобраться в причинах, почему производительность системы не отвечает ожиданиям. Недавно я вел переписку с пользователем, который пытался решить проблемы с производительностью его нового ноутбука. Из разговора стало ясно, что система оказалась сравнительно чистой (~40 запущенных процессов, добрая половина 1 Гб системной памяти свободна, загрузка CPU при простое менее 5%). В итоге выяснилось, что основной проблемой стало модемное соединение с Интернетом. Многие предлагают нам отключить анимацию, графику, темы, ошибочно полагая, что в этом кроется причина низкой производительности. Мы уже говорили о реестре, занимаемом дисковом пространстве и даже о глубине цвета с точки зрения их влияния на общую производительность системы.

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

В Windows 7 мы сконцентрировали свое внимание на измерении и увеличении производительности системы на нескольких «уровнях»: микротестах, особых сценариях, настройке системы. Любой из них играет критическую роль в разработке Windows 7 и, несмотря на то, что производительность любого может быть измерена, это не тот случай, когда окончательные выводы о производительности системы могут быть сделаны исключительно на основе измерений.

Микротесты. Под микротестами мы понимаем такой тип тестов, который по максимуму нагружает определенную подсистему. Как правило, это участки кода, чью производительность в ходе каждодневного использования ОС практически невозможно заметить, поскольку они исполняются почти мгновенно. Среди систем, регулярно подвергающихся микро-тестированию, следует отметить и файловую систему, и сетевой стек, и систему управления памятью, а также подсистему 2D и 3D-графики. Наглядным примером может послужить работа, которую мы проделали для ускорения копирования файлов. Было написано огромное количество низкоуровневого кода, охватывающего значительную часть состояний при копировании файлов, при этом весь код выполнялся через функцию XCOPY в командном окне (или через API). Конечно, львиная доля операций копирования проходят через Windows Explorer, а сам процесс копирования сопровождается индикацией, возможностью отказа от копирования и отсчетом количества не скопированных байтов информации. Эти возможности, хотя и имеют массу преимуществ, не даются бесплатно. Микро-тестирование призвано помочь нам лучше понять конкретный случай и впоследствии сравнить его с наиболее распространенными. Опытные пользователи всегда применяли консоль, поскольку она обеспечивала более широкие возможности, полный контроль и гибкость. Возможность измерять производительность системы на базе микро-тестов выглядит довольно заманчивой, но каждая попытка их использовать доказывает лишь их ограниченность, поскольку каждодневное использование ОС пользователем охватывает гораздо больший сегмент кода в различных элементах системы. В блоге разработчиков Internet Explorer 8, кстати, есть статья по поводу производительности, а также влияния производительности скриптов на общую производительность браузера. С другой стороны, мы понимаем, что производительность в микротестах некоторых подсистем может и должна быть учтена. Так, к примеру, следует с вниманием отнестись к производительности DirectX-графики, поскольку это крайне важно для геймеров. Стоит отметить, что многие микротесты в большой степени зависят от комбинации Windows, устройств и драйверов.

Особые сценарии. Большинство пользователей оценивают производительность компьютера с точки зрения некоторых высокоуровневых операций, среди которых загрузка, сон/пробуждение, запуск приложений. Об этом мы уже говорили в ранее опубликованных статьях. При разработке Windows 7 каждая команда сфокусирована на определенном наборе сценариев, которые пытается улучшить. Эта работа всегда предполагает настройку кода с точки зрения количества исполняемых инструкций, распределяемых ресурсов и осознания всех вызовов API. На ум сразу приходит пример - работа, которую мы проделали, чтобы сократить время переподключения USB-устройства. Ее результаты особенно заметны при использовании USB-накопителей или карточек памяти. К слову сказать, в Windows есть драйвера для огромного количества схожих кард-ридеров и USB-накопителей, поскольку в этом преимущество Windows – в разнообразии поддерживаемых устройств. В самом начале проекта мы пристально взглянули на профиль кода, запускаемого при подключении USB-накопителей, и проверили этот сценарий на наличие проблем, которые впоследствии одну за другой устранили. Еще одним примером является воспроизведение DVD-фильмов, которое предполагает интенсивное использование не только подсистемы хранения информации, но и графики. Подводным камнем является необходимость оптимизации загрузки CPU, на которую при просмотре фильма пользователи в принципе не обращают внимания, но которая диктует потребление электроэнергии.

Настройка системы. Серьезная роль в обеспечении производительности ложится на плечи настройки системы. Чтобы оценить проделанную работу, мы регулярно сравниваем новые сборки с ранее выпущенными и предыдущими релизами Windows. Мы всегда стремимся избавиться от операций, которые занимают много времени/пространства/ресурсов, и тех, которые со временем увеличиваются в одном из названных измерений. Тестирование и сравнение с ранее выпущенными сборками дает уверенность, что мы добиваемся прогресса. От пристального взгляда разработчиков не ускользнет ни одна возможность для дальнейшего улучшения. Пользователи уже успели заметить в Windows 7 build 6801 значительное снижение потребления памяти (через менеджер задач) DWM. Этого удалось достичь благодаря тому, что в Windows 7 большинство архитектурных изменений направлено на сокращение количества системных ресурсов, потребляемых различными подсистемами. Нам удалось сохранить совместимость с драйверами, созданными для Windows Vista. Аналогичную работу мы проделали и с поисковым механизмом –добились не только сокращения величины занимаемой системной памяти, но и интенсивности ввода/вывода. Одной из сложнейших областей для работы стала панель задач и меню Start. Изменения в них подразумевали серьезную работу над критическими секциями («блокировку» фрагментов кода), реестром ввода/вывода, а также путями кода в целом. Это придало уверенности в том, что эти элементы UI всегда доступны и просты в работе.

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

Важно понимать, что для нас основной целью при разработке Windows 7 является создание ОС, которая в полной мере отвечает нуждам и потребностям пользователей. Восприятие производительности играет в этом ключевую роль, поэтому нам крайне важно использовать как можно более широкий набор инструментов для ее оценки, чтобы мы могли оперировать полной картиной.

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

• Мы самостоятельно разрабатываем методики тестирования и осуществляем измерение производительности различных элементов ОС до того, как они проходят проверку у разработчиков, при этом производительность и отзывчивость элементов должна быть выше допустимого уровня. Наличие неких рамок гарантирует достаточно высокий уровень производительности и отзывчивости при компиляции ежедневных сборок и, как следствие, многие пользователи считают их пригодными для своей ежедневной работы.
• Мы стремимся снизить используемый объем памяти, упростить обслуживание, улучшить эффективность ключевых путей кода, улучшить масштабируемость, снизить число подвисаний, увеличить эффективность операций ввода/вывода и многое другое. Все эти сценарии основаны на реальных путях исполнения, полученных от наших пользователей через систему телеметрии.
• Мы тесно сотрудничаем с крупнейшими OEM-производителями, ISV- и IHV-компаниями. Наши инструменты доступны всем желающим, мы регулярно проводим обучение и сконцентрированы на разработке систем, отвечающим нуждам конечных пользователей, в частности с точки зрения производительности и времени работы от аккумуляторов.
• В команде разработчиков Windows на компьютере каждого сотрудника установлена небольшая утилита, позволяющая осуществлять замеры производительности в непрерывном режиме. Если какой-то из элементов ОС проявляет нерасторопность, утилита делает снимок системы и направляет его на сервер для автоматического анализа. Кроме того, разработчики осматривают снимки на наличие новых проблем, которые не поддаются расшифровке нашей автоматизированной системой. Такого рода работа позволяет установить первопричину наиболее распространенных проблем.
• Для пользователей Pre-Beta, Beta и RTM мы разработали новую форму инструментария, которая используется в более чем в 500 установках ОС и встроенных в нее приложений. Концепция новой утилиты очень проста, но и революционна одновременно. Утилита, названная PerfTrack, помогла нам подтвердить, что клиентские оценки не очень информативны с точки зрения диагностирования реально существующих проблем с производительностью.

PerfTrack – это очень гибкая и динамически конфигурируемая телеметрическая система. Для ключевых сценариев Windows 7 предусмотрены события “Start” и “Stop”, которые ограничивают сценарий с двух сторон. Сценарии могут быть любыми: открытие файла, просмотр веб-страницы, открытие панели управления, поиск документа или загрузка компьютера. Для бета-версии Windows 7 предусмотрено около 500 сценариев.

Очевидно, что время между событиями Stop и Start является индикатором отзывчивости сценария, именно поэтому наша система телеметрии собирает такие данные и направляет их для анализа. Уникальность PerfTrack заключается не только в том, что она измеряет, а в том, что она позволяет выйти за пределы простого наблюдения частоты возникновения проблем.

Давайте рассмотрим конкретный сценарий открытия XYZ. Для него перед разработчиками поставили задачи по достижению определенного уровня отзывчивости. Зеленый отражает время, которое разработчики посчитали приемлемым, желтый – которое по их мнению находится на грани допустимости, а красный – недопустимым. Время, указанное в миллисекундах, отражено по оси X. По оси Y расположен счетчик.

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

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

В результате тщательного изучения статистики и устранения первопричин обнаруженных проблем нам удалось достичь значительного увеличения отзывчивости Windows 7 и, как следствие, массы положительных отзывов от первых тестеров.

Этой статьей мы хотели продемонстрировать пользователям наше мышление относительно производительности, а также привести примеры используемых нами способов оценки производительности в ходе разработки Windows 7. Мы верим, что грядущее бета-тестирование поможет нам достичь наших целей при разработке Windows 7 – производительность новой системы должна отвечать ожиданиям пользователей.

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

Стивен и Майкл


Источник: http://blogs.msdn.com/e7ru
Перевод: deeper2k