Разные операционные системы дают нам разные ответы и применяют иногда довольно противоречивые способы оптимизации энергопотребления. Мы рассмотрим системы Microsoft® Windows™ 7 и Microsoft® Windows™ 8 Consumer Preview. Сразу предупредим, что детальное описание эксперимента, методов измерения и анализа полученных результатов, а также факторов, влияющих на точность измерений, – это тема для отдельной, полноценной статьи и здесь излагаться не будет. Отметим только, что практически все измерения проведены с помощью профилировщика Intel® VTune™ Amplifier XE.

Итак, есть ультрабук на базе процессора Intel® Core™i5 (кодовое имя архитектуры – Sandy Bridge), программа, загружающая все доступные процессоры на 100%, и две операционные системы (Windows 7 и Windows 8), которые мы заставляем переходить в экономный режим методом отключения внешнего питания.

Система Windows 8 сразу же применила нестандартный подход к решению проблемы и после запуска нашей программы повысила частоту процессора в 1,2 раза относительно номинальной. Время работы программы в этом случае было менее 26 секунд. Условное время жизни компьютера от батареи (мы измерили его как время уменьшения заряда аккумулятора на 1%, умноженное на 100) при этом составило 100 минут.

Система Windows 7 пошла по очевидному пути экономии: она уменьшила частоту в 2,12 раза. Время работы при этом составило 75 секунд, а условное время жизни – 250 минут.

То есть время жизни компьютера от батареи (при большой вычислительной нагрузке) под Windows 7 в два с половиной раза больше, чем под Windows 8. Но время работы самой программы почти в три раза больше. Иными словами, если для кодирования вашего видео или «сшивки» панорамы под Windows 8 требуется час и при этом аккумулятор полностью истощается, то под Windows 7 он истощится через два с половиной часа, но для получения результата вам нужно еще минут 30, а батарейка уже «села»!

Вот такая интересная экономия.

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

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

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

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

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

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

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

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

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

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

Однако по моему личному мнению, кашу маслом не испортишь: чем интенсивнее информационный обмен, тем быстрее продвигаются исследования, а качество работы и внутренняя конкуренция – дело совести каждого уважающего себя исследователя.

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

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

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

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

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

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

Вывод: продукты как технические решения развиваются за счет исследований, и исследования «подпитываются» проблемами, порожденными новыми техническими решениями. Достаточно однажды начать – и издержки на последующие исследования становятся все меньше, а фронт работ возрастает. Но справедливо и другое: исследования без практического результата не имеют смысла и не должны иметь продолжения. Нельзя постоянно доказывать, что что-то сделать нельзя – нужно хотя бы один раз показать, что же сделать можно. И если положительного результата долгое время не наступает, возможно, исчерпана область исследования, а может быть, и возможности самого исследователя.

]]> http://software.intel.com/ru-ru/blogs/2008/08/07/74/feed/ 4