|
Исполнение кода сборки (часть 3)
Разработчики с опытом программирования на неуправляемых C/C++, вероятно, задумаются над производительностью. В конце концов неуправляемый код
компилируется для конкретного процессора и при вызове просто исполняется.
В управляемой же среде компиляция производится в две фазы. Сначала компилятор проходит исходный код и переводит его в IL. Но для исполнения сам IL-код
нужно перевести в команды процессора в период выполнения, что требует дополнительной памяти и процессорного времени.
Поверьте: я сам из тех, кто программирует на C/C++, и, переходя на CLR, я достаточно скептически рассматриваю все эти дополнительные накладные расходы.
Вторая стадия компиляции, имеющая место в период выполнения, снижает скорость
и требует дополнительной динамической памяти — с этим не поспоришь. Однако
Microsoft проделала большую рабо гу, чтобы свести эти издержки к минимуму.
Если вы тоже скептик, сами создайте приложение и проверьте его производительность. Кроме того, можете взять какое-нибудь нетривиальное приложение от
Microsoft или другого разработчика и измерить его производительность. Я думаю,
вас удивит, насколько она высока на самом деле.
Трудно поверить, но многие (включая меня) считают, что управляемые приложения производительней неуправляемых, и тому есть масса подтверждений.
Например, когда JIT-компилятор компилирует IL-код в команды процессора в
период выполнения, он располагает более полными сведениями о среде выполнения в сравнении с компилятором неуправляемого кода. Вот некоторые способы, которые позволяют управляемому коду «опередить» неуправляемый,
• JIT-компилятор может обнаружить, что приложение запускается на процессоре Pentium 4 и сгенерировать процессорный код, полностью использующий
все преимущества особых команд Pentium 4- Неуправляемые приложения обычно компилируются в расчете на процессор, являющийся «наименьшим общим
знаменателем», избегая специфических команд, которые заметно повышают
производительность приложения на новейших процессорах.
• JIT-компилятор может обнаружить, что некоторая проверка всегда приводит
к отрицательному результату на конкретной машине
Этот код указывает JIT-компилятору, что для машины с одним процессором
не нужно генерировать никакие команды процессора. В этом случае собствен-
ный код процессора оптимизирован для конкретной машины: он короче и
выполняется быстрее.
• CLR может проанализировать выполнение кода и перекомпилировать IL-код в
команды процессора при выполнении приложения. Перекомпилированный код
может быть реорганизован с учетом обнаруженных некорректных прогнозов
ветвления.
Это лишь малая часть аргументов в пользу того, что управляемый код будущего будет исполняться лучше сегодняшнего неуправляемого. Как я сказал, производительность и сейчас очень неплохая для большинства приложений, а со временем ситуация только улучшится.
Если ваши эксперименты покажут, что JIT-компилятор CLR не обеспечивает
нужную производительность, можете использовать утилиту NGen.exe, поставляемую с .NET Framework SDK. NGen.exe компилирует весь IL-код некоторой сборки
в процессорный и сохраняет результирующий код процессора в дисковом файле. При загрузке сборки в период выполнения. CLR автоматически проверяем наличие предварительно скомпилированной версии сборки и, если она есть, загружает скомпилированный код, так что компиляция в период выполнения не производится.
Предыдущая стр.
Оглавление
Следующая стр.
Средняя оценка:   (1 - 1 голосов)
Для оценки необходимо зарегистрироваться
Только зарегистрировавшиеся пользователи могут оставлять комментарии
|
|