Журнал «Компьютерра» N 38 от 17 октября 2006 года

Что же нам предлагают? По правде говоря, для меня стало откровением, что несмотря на отсутствие поддерживающего ее программного обеспечения, первая на рынке технология виртуализации VT-x, которую процессоры Intel поддерживают уже около года, за это время несколько раз оптимизировалась по быстродействию, так что производительность использующих ее программ на Core 2 Duo будет заметно выше, чем на первых Pentium D (даже с учетом разницы в производительности самих этих процессоров). Впрочем, сегодня ведущие производители виртуальных машин уже поддерживают VT-x, хотя и не реализуют всех ее потенциальных возможностей, что, впрочем, неудивительно, если учесть, что необходимый для полного раскрытия технологии объем работ сопоставим по сложности с созданием новой операционной системы, да и ОС в идеале должны бы пройти соответствующую оптимизацию. Камень преткновения в данном вопросе - это необходимость реализации работающих на уровне виртуальной машины драйверов для железа и их поддержки операционной системой. Дело в том, что все нынешние ОСи попросту не умеют совместно с другими ОСями одновременно использовать одно и то же оборудование - скажем, общую видеокарту, и приходится либо реализовывать средствами виртуальной машины виртуальный же графический адаптер, жертвуя производительностью и функциональностью, либо ставить, грубо говоря, две видеокарты - по одной на каждую из ОСей, что тоже едва ли можно назвать удачным выходом. Кроме того, если мы собираемся использовать VMM не только для одновременного запуска Linux и пары копий Windows на одной машине, а для более «прогрессивных» схем, в которых, например, предлагается каждому критичному приложению выделять по собственной копии операционной системы, то без поддержки со стороны ОС и запустить это приложение - проблема (потребуется ждать создания новой виртуальной машины и загрузки в ней ОСи, после чего вручную запускать нужную программу), и работать с ним (было бы лучше, если б запущенная на другой виртуальной машине программа выглядела как обычное приложение, а все технические тонкости были спрятаны), и ресурсов на это уйдет слишком много (о быстродействии во многих случаях можно забыть). Словом, объем работы огромен, он наверняка займет еще несколько лет. Так что первые ее по-настоящему интересные плоды мы, вероятно, увидим тогда же, когда и второе поколение виртуализации от Intel, известное сейчас под кодовым названием VT-d.
Для разработчиков VT-d - большой шаг вперед. Например, в этой технологии появится аппаратная поддержка двойной трансляции виртуальной памяти, что позволит обойтись в виртуальных машинах без реализации ее функциональности чисто программным путем, довольно медленным и требующим большого непроизводительного расхода оперативной памяти. Появится возможность предоставления быстрого, без участия VMM доступа к выбранным MSR-регистрам процессора [Эта фича уже реализована в VT-x процессоров архитектуры Intel Core]; появится возможность не сбрасывать при каждом переключении между виртуальными машинами таблицу трансляции виртуальной памяти TLB, - все это тоже должно сильно увеличить быстродействие VT-d по сравнению с VT-x. Появится защита DMA-операций, улучшится поддержка прерываний - что, в свою очередь, повысит безопасность, закрыв некоторые потенциальные дыры. Кстати, интересно, что почти все из вышеперечисленного предлагает в своей технологии Pacifica компания AMD, незадолго до Форума начавшая поставки соответствующих процессоров. Так что Intel, безоговорочно лидировавшая в этой области, рискует на полгода-год - до выхода процессоров и чипсетов с поддержкой VT-d - остаться в хвосте. Впрочем, решение AMD не совместимо с решением Intel, и решатся ли разработчики на «оптимизацию» своего ПО «под AMD» - пока непонятно.
Любопытный доклад был посвящен созданию виртуальной машины «от Intel». В свое время, когда еще только появлялись первые процессоры VT-x, я спрашивал на московском Форуме представителей Intel о перспективах создания компанией собственного ПО, дабы потребители могли воспользоваться этой технологией (как известно, Intel разрабатывает и продает довольно много программных продуктов для собственного железа, начиная с компиляторов и заканчивая средствами отладки), но тогда мне сказали, что создание VMM ляжет на плечи сторонних разработчиков (в числе которых, кстати, фигурирует Microsoft), а Intel в лучшем случае поддержит OpenSource-проекты, но уж никак не станет создавать собственный стандарт. Однако ситуация, похоже, меняется, и вместо разговоров о довольно невнятном опенсорсном проекте Xen, на котором демонстрировалась работа VT-x, но который, на мой взгляд, страшно далек был не только от «народа», но и от подавляющего большинства сисадминов [Хотя Novell, включившая Xen в свои версии Linux, пожалуй, со мной не согласится], на Форуме разговор шел уже о более чем понятном и весьма многообещающем Open Virtual Iron, реализующем полноценную, удобную и довольно «навороченную» виртуализацию. Сама Virtual Iron - стартап, предлагающий коммерческое ПО, и подобный поворот в сторону «открытости», да еще и подробно освещенный Intel, выглядит как попытка установить некую собственную «стандартную платформу» в виртуализации.
Что касается более отдаленных перспектив, то Intel уже давно обещает появление поддержки виртуализации на уровне самих устройств, что снимет многие проблемы с их использованием в виртуализированных системах. Но в отличие от VT-d, здесь все зависит не только от Intel, поскольку соответствующие усовершенствования придется вносить во все многообразие современного компьютерного оборудования (помнится, года два назад речь шла даже о специальных клавиатурах, мониторах и мышах!), что потребует перестройки на новый лад огромного количества разработчиков. Оглянитесь вокруг в поисках тотального перехода на давным-давно вышедший PCI Express, который прославляли как безусловный стандарт самого ближайшего будущего, - и вы увидите, что подавляющее большинство разработчиков как использовали старый добрый PCI и более быстрый PCI-X, так и продолжают использовать. Тем не менее комитет PCI-SIG продолжает работу над выработкой спецификаций на устройства, в которых виртуализация будет поддерживаться аппаратно, и наверняка включит их в очередную версию стандарта PCI.
Четырехъядерные процессоры и HPC
После двухъядерных процессоров, о которых столько говорили в прошлом году, четырехъядерники этого года уже не являются чем-то сильно новым с технологической и маркетинговой точек зрения. Так что вместо отдельных сессий для специалистов они удостоились лишь упоминаний в паре докладов, в которых в очередной раз было подтверждено, что «четыре ядра» от Intel будут объединением двух обычных двухъядерных процессоров в общем корпусе, примерно таким, каким было второе поколение Pentium D, набиравшееся из пары одноядерных кристаллов CedarMill. С одной стороны, это очень выгодно для Intel, поскольку с ее хорошо отлаженной технологией производства подобных «гибридов» она может представить эти «камни» в самые кратчайшие сроки и по минимальной себестоимости. С другой - разделение на «пары» ядер хорошо далеко не для всех приложений, и по некоторым сообщениям, даже оптимизированное параллельное ПО к Kenthsfield’у отнесется равнодушно, в отличие от по-настоящему прорывных в этом отношении Yonah и Conroe. Кроме того, два ядра - это удвоение тепловыделения и нагрузки на схемы питания процессорного сокета, что отрицательно скажется и на только-только завоеванном звании «самых холодных процессоров», и на совместимости с материнскими платами. Главный конкурент - AMD - сейчас активно «играет» на обоих моментах, заявляя, что у нее этих проблем, благодаря использованию «монолитного» четырехъядерного чипа и переходу на 65-нм технологический процесс, не будет. Правда, не стоит забывать, что у нее все это будет после, а у Intel пусть даже «неидеальный», но работающий четырехъядерник - уже сейчас, и не исключен даже такой вариант, что первые четырехъядерные «камни» от AMD выйдут к тому моменту, когда Intel подготовит 45-нм технологический процесс и выпустит на его основе находящиеся сейчас в разработке собственные «монолитные» квады, с перспективой их объединения по той же схеме «двух кристаллов в одном корпусе» в октеты.