В тему применимости CLR и C++ в больших проектах, работающих с большими объемами данных.
Итак. При загрузке скомпилированного в IL код приложения среда CLR проверяет наличие сгенерированного NGen.exe файла с машинным кодом. При наличии этого файла и успешной проверки ряда его характеристик JIT-компиляция методов производится не будет и среда будет подгружать скомпилированные методы из этого источника. Какие минусы мы имеем при использовании NGen файлов.
1. Пожалуй самый основной недостаток — это потеря времени на модификации базового адреса и приявязки.
В связи с тем, что продукт, который мы делаем, ввиду специфики отличается излишней прожорливостью и стремится при возможности отожрать максимум предоставляемой памяти эта проблема встает довольно остро. Было бы любопытно провести тесты по модификации базовых адресов в модулях на 60 тысяч строчек.
2. Утилита NGen ввиду отсутствия некоторой информации о среде выполнения создает усредненный код.
Но поскольку в C++ мы сталкиваемся в общем-то с такой же проблемой детально этот момент мы рассматривать не будем.
Теперь что касается работы JIT-компилятора при отсутствии NGen файла. При первом обращении к методу приложения среда CLR обращается к указанному участку IL кода и выполняет Just-In-Time компиляцию метода. При компиляции используется оптимизация в зависимости от текущей аппаратной конфигурации машины. Помимо всего прочего во время компиляции происходит IL-верификация используемых типов и вызываемых методов. После компиляции JIT-компилятор возвращается к внутренней структуре данных и заменяет адрес метода в IL-коде на адрес блока машинных команд и передает управление коду. Теперь этот блок будет храниться в памяти до завершения работы программы и все последующие вызовы будут переадресовываться на этот блок памяти.
Все это прекрасно и в идеале может давать очень хорошую производительность за исключением случаев, когда в проекте используется большое количество методов и время ожидания при первом прогоне алгоритма может значительно увеличиться.
Итак. При загрузке скомпилированного в IL код приложения среда CLR проверяет наличие сгенерированного NGen.exe файла с машинным кодом. При наличии этого файла и успешной проверки ряда его характеристик JIT-компиляция методов производится не будет и среда будет подгружать скомпилированные методы из этого источника. Какие минусы мы имеем при использовании NGen файлов.
1. Пожалуй самый основной недостаток — это потеря времени на модификации базового адреса и приявязки.
В связи с тем, что продукт, который мы делаем, ввиду специфики отличается излишней прожорливостью и стремится при возможности отожрать максимум предоставляемой памяти эта проблема встает довольно остро. Было бы любопытно провести тесты по модификации базовых адресов в модулях на 60 тысяч строчек.
2. Утилита NGen ввиду отсутствия некоторой информации о среде выполнения создает усредненный код.
Но поскольку в C++ мы сталкиваемся в общем-то с такой же проблемой детально этот момент мы рассматривать не будем.
Теперь что касается работы JIT-компилятора при отсутствии NGen файла. При первом обращении к методу приложения среда CLR обращается к указанному участку IL кода и выполняет Just-In-Time компиляцию метода. При компиляции используется оптимизация в зависимости от текущей аппаратной конфигурации машины. Помимо всего прочего во время компиляции происходит IL-верификация используемых типов и вызываемых методов. После компиляции JIT-компилятор возвращается к внутренней структуре данных и заменяет адрес метода в IL-коде на адрес блока машинных команд и передает управление коду. Теперь этот блок будет храниться в памяти до завершения работы программы и все последующие вызовы будут переадресовываться на этот блок памяти.
Все это прекрасно и в идеале может давать очень хорошую производительность за исключением случаев, когда в проекте используется большое количество методов и время ожидания при первом прогоне алгоритма может значительно увеличиться.
