Симулятор для Microsoft

Автор: Владимир Гуриев
Опубликовано в журнале "Компьютерра" №42 от 15 ноября 2006 года

Отправной точкой для этой заметки стала статья Джона Маркоффа (John Markoff) в New York Times о том, что Microsoft собирается проектировать процессоры самостоятельно и займется этим специально созданная исследовательская лаборатория Computer Architecture Group, которую возглавит легендарный Чарльз "Чак" Тэкер (Charles "Chuck" Thacker).

Удивительно, но текст Маркоффа оказался единственным источником информации об этом сенсационном решении. Новостные агентства, сама Microsoft и, разумеется, производители процессоров, которых такие известия должны были бы обеспокоить, хранили стойкое молчанье. Один из топ-менеджеров европейского отделения Intel, с которым я разговаривал на прошлой неделе, о радикальном шаге Microsoft попросту не знал. Складывалось впечатление, что текст Маркоффа случайно проник в New York Times из какой-то другой, хоть и похожей на нашу, реальности.

Газета New York Times рассчитана на людей, считающих, что Java - это остров, поэтому никаких технических подробностей в тексте не было. Чтобы уточнить детали, мы связались с профессором Беркли Дэвидом Паттерсоном (David Patterson), который о новой инициативе Microsoft отозвался в высшей степени одобрительно. Если одобрительно - стало быть, он точно должен знать, о чем речь.

Для компьютерной индустрии Паттерсон такая же знаковая фигура, как и Тэкер. Если последний прославился, работая в Xerox Palo Alto над персональным компьютером Alto (а затем поучаствовал еще в паре десятков проектов, оказавших непосредственное влияние на компьютерную индустрию), то Паттерсон известен тем, что стоял у истоков архитектуры RISC. Нынешние проекты Паттерсона пока не привлекли пристального внимания прессы, и широкой публике он известен главным образом как соавтор монументального труда "Computer Architecture: A Quantitative Approach", выдержавшего уже четыре издания. В этой книжке содержатся все основные идеи Паттерсона на тему, куда должна двигаться компьютерная индустрия. И надо сказать, что частенько профессор из Беркли слегка обгоняет время: многие предложения не получили практического воплощения до сих пор, хотя в целом компьютерное сообщество относится к изысканиям Паттерсона очень положительно.

Профессор не является сотрудником Microsoft, поэтому он не хотел, да, наверное, и не мог дать комментарии о планах компании. Зато рассказал, какой именно неупомянутый в статье Маркоффа проект Беркли заинтересовал корпорацию. Проект называется RAMP, Research Accelerator for Multiple Processors.

Мультиядерный тупик

Но сначала пару слов о Microsoft. Компанию часто называют софтверным гигантом, и это, конечно, справедливо: весь бизнес Microsoft построен на успехе операционных систем и (в последние десять лет) комплекта программ для выживания в офисе. Однако корпорация уже давно перестала быть "мягкой" и всерьез интересуется разработками в области железа, будучи наряду с Intel одним из главных двигателей прогресса на рынке ПК. И даже если не обращать внимания на то, что творится в исследовательских лабораториях, а учитывать лишь рыночные удачи, Microsoft и здесь есть чем гордиться - компанию, продавшую несколько десятков миллионов Xbox, c полным правом можно причислить к успешным производителям компьютеров.

Microsoft тесно сотрудничает с Intel, однако времена Wintel постепенно уходят в прошлое, и компания печется прежде всего о своих интересах. Когда в Microsoft пришли к выводу, что для Xbox 360 лучше подойдет PowerPC от IBM, то особенно расшаркиваться перед старым партнером, поставлявшим процессоры для первого поколения приставок, не стали. И теоретически, конечно, можно предположить, что в компании считают сотрудничество с Intel, AMD или IBM недостаточно продуктивным. Но настолько непродуктивным, что выгоднее проектировать и, возможно, даже производить процессоры самостоятельно?

На практике подобная задача выглядит почти неподъемной. Даже беря в расчет финансовые, трудовые и маркетинговые резервы Microsoft, очевидно, что подобное самообслуживание может обойтись очень дорого. Кроме того, для такого шага должны быть веские причины, заметные невооруженным глазом. А таких причин нет.

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

А чтобы писать софт под новые процессоры, необходимо эти самые процессоры или хотя бы их прототипы иметь под рукой. В результате процесс перехода на новые рельсы выглядит так: производитель процессоров создает новый чип и присылает прототип или даже полностью готовый сэмпл конечного продукта производителю ПО. Перед последним стоит, мягко говоря, нетривиальная задача: ему необходимо в очень сжатые сроки существенно переделать код своих продуктов. Проходит три месяца. Ничего, конечно, еще не сделано - за столь короткое время та же Microsoft не успеет перевести под новую архитектуру даже свои основные тайтлы. Но за это время софтверная компания успевает понять, что ее не устраивает в новом чипе, и отправить свои замечания производителю. Тот, если это возможно, вносит требуемые коррективы и приступает к массовому производству (это если повезет - не исключена ситуация, в которой на рынок поступает полный аналог последнего прототипа, а предложенные улучшения запоминаются и будут учтены при создании процессоров следующего поколения). На рынок новый процессор поступает в гордом одиночестве: программное обеспечение, способное использовать его возможности по максимуму, попросту не готово. Через несколько месяцев, не торопясь, начинают появляться первые "правильные" программные продукты. Полный цикл софтверно-хардверной перестройки занимает сегодня четыре года. Это плохо и для пользователей, и для производителей софта, и для производителей процессоров.

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

Существующие решения моделирования работы процессоров (софтверные или софтверно-аппаратные) для эмулирования параллельных систем подходят плохо по следующим причинам:

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

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

Эмуляторы против симуляторов

RAMP - это универсальный эмулятор, построенный на базе массива FPGA (матричная программируемая БИС). Такой подход объединяет в себе лучшее, что есть сегодня в эмуляции новых процессоров. С одной стороны, схема на перепрограммируемых БИС достаточно гибка, чтобы на ее базе можно было смоделировать любую известную параллельную архитектуру (не без ограничений, но о них чуть ниже). С другой - обладает достаточной производительностью, чтобы на RAMP можно было запускать операционные системы и приложения, проверяя работоспособность проектируемого процессора почти в реальных условиях (работать они будут в 10–20 раз медленнее, но и это очень приличный результат). Кроме того, он прекрасно масштабируется: на одной FPGA сегодня можно разместить порядка двадцати ядер (то есть на 1024-процессорную систему нужно от сорока до восьмидесяти FPGA), при этом скорость работы 1000-процессорной системы будет ненамного ниже, чем у 32-процессорной системы. Немаловажная для академических исследователей особенность - относительная дешевизна такого решения (железо для эмуляции 1000-ядерного процессора обойдется примерно в 100 тысяч долларов).

Но RAMP это не только железо, но и набор уже готовых моделей архитектур, описанных на специальном языке RDL (RAMP Description Language). В идеале исследовательское подразделение или факультет computer science, приобретая RAMP, вместе с небольшой кучкой железа, которую можно научить изображать другую кучку железа, получает почти все необходимые шаблоны. Вряд ли это очень важно для коммерческих разработчиков, а вот университетам очень пригодится.

Сегодня исследователи договорились о "портировании" на RAMP 32-битных процессоров IBM Power 405, Sun SPARC v8, Xilinx Microblaze (софт-процессор), 64-битного SPARC Niagara. Не исключено также создание моделей для 64-битного IBM Power и Tensilica, ARM, а также MIPS32 и MIPS64. Интеловских архитектур (x86, x86-64) на RAMP, видимо, не будет, хотя специалисты Intel в проекте участвуют.

Чтобы картина не получалась совсем уж радужной, упомянем и о недостатках RAMP, которые очевидны уже сегодня. Во-первых, FPGA-акселератор кое-где проигрывает софтверным симуляторам по функциональности, так как не умеет делать откаты (в случае софтверной симуляции можно отменить или пустить в обратном порядке любой набор инструкций), что, впрочем, компенсируется скоростью. Во-вторых, противники RAMP - а такие тоже есть - полагают, что заявления о точности эмуляции преждевременны, поскольку система в целом выглядит несбалансированной: быстрая память на медленных процессорах - не слишком стандартная конфигурация. Впрочем, Паттерсон к такой критике относится спокойно: по его словам, важна не относительная скорость выполнения тех или иных операций, а количество необходимых циклов процессора, а это - величина абсолютная. В-третьих, есть определенные физические ограничения, которые усложняют построение моделей процессорных архитектур. Так, например, затруднено построение эмуляторов современных процессоров с кэшем второго уровня емкостью больше 2 Мбайт, потому что объем памяти на борту стандартной FPGA меньше этого значения. Тем не менее недостающую память можно эмулировать отдельно. Кроме того, RAMP вполне работоспособен даже в том случае, когда построить полную RTL-модель не удается (например, ее просто нет - как нет модели Intel IA-32) или она слишком сложна для имплементации. В подобных ситуациях RAMP можно использовать в связке с софтверным симулятором, хотя результаты работы такого тандема и потребуют дополнительной верификации.

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

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

По сравнению с такой перспективой гипотетические планы Microsoft выйти на рынок микропроцессоров выглядят весьма прозаично. И даже если планам Чака Тэкера создать процессор для третьего поколения Xbox самостоятельно, не суждено сбыться, это ничего не значит. Наверняка новый процессор будет спроектирован с учетом многочисленных и настойчивых пожеланий Microsoft. А кто его будет проектировать - дело уже десятое.