На практике подобная задача выглядит почти неподъемной. Даже беря в расчет финансовые, трудовые и маркетинговые резервы Microsoft, очевидно, что подобное самообслуживание может обойтись очень дорого. Кроме того, для такого шага должны быть веские причины, заметные невооруженным глазом. А таких причин нет.
Профессор Паттерсон уверен в обратном. Компьютерная индустрия, по его мнению, находится в глубоком кризисе, и дело тут не в Microsoft или Intel, а во взаимоотношениях программистов и создателей железа. Переход производителей процессоров на мультиядерные архитектуры — казалось бы, многообещающий — эти и без того непростые взаимоотношения только усугубил. Раньше увеличение скорости работы процессоров проходило для софтмейкеров почти безболезненно — конечно, в каждом новом поколении процессоров были значимые архитектурные изменения, однако старые программы, рассчитанные на предыдущие архитектуры, все равно работали на новом железе заметно быстрее. Переход на мультиядерные архитектуры эту ситуацию изменил. Чтобы добиться от такой системы максимальной производительности, необходимо иметь софт, умеющий пользоваться новыми возможностями.
А чтобы писать софт под новые процессоры, необходимо эти самые процессоры или хотя бы их прототипы иметь под рукой. В результате процесс перехода на новые рельсы выглядит так: производитель процессоров создает новый чип и присылает прототип или даже полностью готовый сэмпл конечного продукта производителю ПО. Перед последним стоит, мягко говоря, нетривиальная задача: ему необходимо в очень сжатые сроки существенно переделать код своих продуктов. Проходит три месяца. Ничего, конечно, еще не сделано — за столь короткое время та же Microsoft не успеет перевести под новую архитектуру даже свои основные тайтлы. Но за это время софтверная компания успевает понять, что ее не устраивает в новом чипе, и отправить свои замечания производителю. Тот, если это возможно, вносит требуемые коррективы и приступает к массовому производству (это если повезет — не исключена ситуация, в которой на рынок поступает полный аналог последнего прототипа, а предложенные улучшения запоминаются и будут учтены при создании процессоров следующего поколения). На рынок новый процессор поступает в гордом одиночестве: программное обеспечение, способное использовать его возможности по максимуму, попросту не готово. Через несколько месяцев, не торопясь, начинают появляться первые «правильные» программные продукты. Полный цикл софтверно-хардверной перестройки занимает сегодня четыре года. Это плохо и для пользователей, и для производителей софта, и для производителей процессоров.
Очевидная ставка лидеров микропроцессорной индустрии на мультиядерные решения ставит перед индустрией еще одну, почти не разрешимую в сегодняшних условиях, задачу. Производители сегодня умеют проектировать двух-, четырех— и даже восьмиядерные процессоры, но эффективного инструментария для создания и тестирования процессоров, состоящих, например, из 64 или даже 1024 ядер попросту не существует. Больше того, многие проблемы, с которыми дизайнерам процессоров придется столкнуться в будущем, сегодня — на относительно простых двухъядерных и так далее моделях — просто незаметны.
Существующие решения моделирования работы процессоров (софтверные или софтверно-аппаратные) для эмулирования параллельных систем подходят плохо по следующим причинам:
— они работают слишком медленно, в тысячи раз медленнее, чем будущий процессор, что, мягко говоря, отладку не облегчает и почти всегда исключает прогон на новом процессоре не отдельных конструкций, а реальных программных продуктов. В большинстве случаев масштабирование, то есть увеличение количества ядер в прототипе, либо еще больше замедляет работу модели, либо вообще невозможно;
— они плохо подходят для моделирования процессоров с другой архитектурой. Иными словами, если вам нужна точность результатов, то микропроцессор, на котором построена эмулирующая система, должен быть максимально приближен к микропроцессору, который на этой системе моделируется;
— по разным причинам (скорость работы, стоимость, легкость подстройки) создатели эмуляторов вынуждены упрощать свои системы, что снижает точность результатов тестирования. Проще говоря, во время отладки «софтверного процессора» нет уверенности, что выполненный в железе прототип будет вести себя именно так — есть лишь некая, впрочем, довольно высокая вероятность, что его поведение будет примерно таким, как показала модель;
— многие инструменты для эмулирования работы процессоров либо дороги сами по себе, либо недешево обходятся при эксплуатации (в первую очередь из-за высокого энергопотребления).