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

• Название: Журнал «Компьютерра» № 42 от 14 ноября 2006 года
• Автор: Компьютерра
• Жанр: Прочая околокомпьтерная литература

---

Очевидная ставка лидеров микропроцессорной индустрии на мультиядерные решения ставит перед индустрией еще одну, почти не разрешимую в сегодняшних условиях, задачу. Производители сегодня умеют проектировать двух-, четырех— и даже восьмиядерные процессоры, но эффективного инструментария для создания и тестирования процессоров, состоящих, например, из 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. А кто его будет проектировать — дело уже десятое.

ГОЛУБЯТНЯ: Лебединый ракощук

Автор: Сергей Голубицкий

В Архангельской области в замечательном городке Северодвинске поселилось паскудство по имени «Алмеза Рисёч». Так задолбать, как это умудряется сделать «Алмеза Рисёч», по злому умыслу невозможно, только — по простоте душевной. С упорством, достойным ловли вшей, мой почтовый ящик отравляется посланиями «Алмезы Рисёч» такого вот содержания: "Здравствуйте, sgolub! Предлагаю статью для вашего журнала. Статья новая, еще ни где не публиковалась. Если что не понравится — могу отредактировать. Тема статьи — «Создание универсального диска для автоматической установки ПО».

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

Не прошло, однако, и месяца, как назойливые слепни снова залудили идентичное письмо: лови, типа, чувак, статью-свежак, нигде не издавалась, имей за счастье опубликовать. И снова я повелся. В оправдание лишь скажу, что мысль о спаме отверг по соображениям здравого смысла: кому придет в голову в 2006 году заниматься подобным несусветством? Это же прямое уничтожение репутации компании. Да и спамерский стереотип не срабатывал: вместо «Дмитрия Сергеевича» и «Изольды Бордулаевны» с обратным адресом [email protected] от «Алмезы» шли внешне нормальные письма с корпоративным почтовым адресом. Разве что в имени подписанта легкий налет апории — Иван Абрамовский. Терпеливо отвечаю: «Иван, вы не по адресу — пишите сюда: [email protected]». «Иван» неожиданно прорезался, снизошел до ответа: «Ок, спасибо». Немногословные люди, северяне, чего уж там. С тех пор «Алмеза» с Ваней аки пендюлюм Фуко бомбардирует мой почтовый ящик своим чертовым спамом, не удосуживаясь даже сменить пластинку — лепит по-старому: «Предлагаю статью для вашего журнала. Статья новая, еще ни где не публиковалась. Если что не понравится — могу отредактировать» и т. д.