Журнал «Компьютерра» № 42 от 14 ноября 2006 года

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

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

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

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

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

— по разным причинам (скорость работы, стоимость, легкость подстройки) создатели эмуляторов вынуждены упрощать свои системы, что снижает точность результатов тестирования. Проще говоря, во время отладки «софтверного процессора» нет уверенности, что выполненный в железе прототип будет вести себя именно так — есть лишь некая, впрочем, довольно высокая вероятность, что его поведение будет примерно таким, как показала модель;

— многие инструменты для эмулирования работы процессоров либо дороги сами по себе, либо недешево обходятся при эксплуатации (в первую очередь из-за высокого энергопотребления).

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

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

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