Технология Клиент-Сервер 2004'1

Home

Поиск

Издания

Контакты

k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

От редакции

Ни для кого не секрет, что Microsoft делает ставку на managed-код. Более того, некоторые PR-акции Microsoft привели к тому, что некоторые журналисты, далекие от программирования, начали говорить, что в новой версии Windows (Longhorn) WinAPI будет заменен на managed API и так далее. Из-за таких заявлений в форумах типа RSDN.RU появились вопросы наподобие:

"Я как правильно понял Longhorn будет целиком на .Net а win32 будет в режиме эмуляции? Следовательно виртуальная машина win32 тоже на .Net ?"

Вопрос, конечно, был незамедлительно отправлен в юмор, но, тем не менее, тенденция налицо. :) Конечно, ничего подобного не произойдет, по крайней мере в ближайшее время. Однако в Longhorn действительно будет довольно много managed-кода, порожденного компилятором C#. Многие программисты, долго и плодотворно писавшие на C++, сомневаются, можно ли на .NET, и особенно, с помощью таких языков, как C# и VB .NET добиться той же (или близкой) производительности кода. Наши эксперименты (серия статей "Кто сегодня самый шустрый", см. http://www.k-press.ru/cs, 3-4 квартал 2001 года и 1 квартал 2002 года, а также http://www.rsdn.ru/?summary/590.xml), а также готовящиеся к публикации аналогичные тесты новой версии .NET Framework (2.0), говорят о том, что производительность кода, порождаемого JIT-компилятором, немногим ниже достигаемой на оптимизирующих компиляторах C++. Но все же разница есть, и тем большая, чем более сложная оптимизация требуется. Скорость вычислений с плавающей точкой не столь высока, многие виды оптимизации выполняются менее эффективно.

Потенциально проблемы с оптимизацией решаемы. Это подтверждается хотя бы тем, что некоторые тестовые примеры, написанные на managed С++, работают не менее эффективно, чем примеры на обычном C++ – благодаря оптимизации, производимой компилятором. Вот, например, результат теста QuickSort (быстрая сортировка 100 МB целых чисел):

unmanaged C++	6.28
managed	6.30
C#	6.80

Но, к сожалению, это не всегда так. Скомпилированный с помощью компиляторов, входящих в поставку VS.NET 2003 (7.1), тест на вычисления с плавающей точкой strange attractor показывает следующие результаты:

unmanaged C++	0.39
managed	1.84
C#	2.35

И, хотя такой большой разрыв наблюдался только в этом тесте, налицо четкая зависимость. Unmanaged-код быстрее порождаемого JIT. MSIL, порождаемый компилятором managed C++ в принципе быстрее порождаемого C#.

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

Видимо, осознав это, Microsoft создал третью группу. :) Точнее, поручил Microsoft Research разработать проект, позволяющий объединить усилия этих двух групп, выделив оптимизирующую часть компилятора в отдельный, относительно независимый проект. Этот проект получил гордое название Phoenix (это наводит на подозрение, что это далеко не первая попытка такого рода :) ) Первое упоминание проекта появилось в 2003 году, а в 4 квартале этого года обещается первая бета. Выпуск продукта ожидается в 2005 году.

Phoenix должен послужить основой для будущих поколений компиляторов от Microsoft. В основе фреймворка Phoenix лежит расширяемая система, которую можно заставить писать или читать как бинарные, так и MSIL-сборки (исполняемые файлы). После считывания исполняемых файлов код, содержащийся в них, превращается в так называемый IR (Intermediate Representation), нечто, похожее на MSIL, но более подходящее для программной обработки. Из IR можно сгенерировать как двоичный исполняемый файл, так и MSIL.

В то время, когда код находится в IR, с ним можно производить разнообразные манипуляции: проверки, оптимизацию, инструментирование кода и так далее.

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