Процесс компиляции программы схема

Трансляторы бывают двух типов:
компиляторы (compiler) и интерпретаторы (interpreter). Процесс
компиляции можно представить как анализ (analysis) и синтез (synthesis).
Анализирующая часть компилятора разбивает исходную
программу на составляющие ее элементы (конструкции языка) и
создает промежуточное представление исходной программы.
Синтезирующая часть из промежуточного представления создает
новую программу, которую компьютер в состоянии понять. Такая
программа называется объектной программой. Объектная
программа может в дальнейшем выполняться без перетрансляции
Для простого исходного языка промежуточное представление не
нужно, и тогда вместо компиляции используется интерпретация –
это простой цикл обработки конструкций языка.
Интерпретатор выбирает очередную инструкцию языка из входного

Компиляция. Как работает компилятор

потока, анализирует и выполняет ее. Затем выбирается следующая
инструкция и т.д. пока не встретится инструкция завершения
программы.

3.

Программа на входном языке – цепочка символов, составляющая
исходную программу на языке программирования L1.
Объектная программа – код программы на целевом языке L2.
Компилятор K отображает множество L1 в множество L2, используя язык
реализации L3 – т.е.
L1 ➾ K L2
Джон Бэкус (англ. John Backus)

4.

Интерпретатор
В отличие от компилятора интерпретатор не создает никакой новой
программы. Входными данными интерпретатора является не только
исходная программа, но и входные данные самой исходной программы.
Интерпретация позволяет выполнить более гибкую и лучшую диагностику
ошибок, чем компиляция. В современных трансляторах часто
используются как элементы компиляции, так и интерпретации.

5.

Объектная программа
Объектная программа может быть:
последовательностью абсолютных машинных
команд
последовательностью перемещаемых
машинных команд
программой на языке ассемблера
программой на некотором другом языке

6.

Трансляция в ассемблер
Генерация кода для платформы .NET выполняетсяется
виртуальной машиной MSIL, которая представляет собой
высокоуровневый ассемблер, максимально
абстрагированный от конкретных целевых платформ

7.

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

Как работает язык программирования(Компилятор)? Основы программирования.

ассемблера A и компьютер K с языком ассемблера A1.
Есть компилятор P языка ассемблер для компьютера K (P ➾ K A1), а сам
компьютер М по каким-то причинам не доступен либо пока ещё не
существует компилятор P языка ассемблер для компьютера M (P ➾ M A).
Нам необходимо создать компилятор L для компьютер M (L ➾ K A).
В такой ситуации мы можем использовать K в качестве
инструментальной машины и написать компилятор L для компьютера M
(L ➾K A), который принято называть кросс-транслятором (crosscompiler).
На основе его можно разрабатывать программы, вплоть до операционной
системы для целевого компьютера M. Как только машина M станет
доступной, он и разработанное на его основе ПО можно перенести на M.

8.

Виртуальная машина
Концепция виртуальной машины (virtual machine) предполагает, что
исходный язык транслируется в коды некоторой специально
разработанной машины, которую никто не собирается реализовывать «в
железе». Затем для каждой целевой платформы пишется интерпретатор
виртуальной машины.
Никлаус Вирт (нем. Niklaus Wirth)

9.

Компиляция «на лету» (Just-In-Time compiling)
Байт-код интерпретируется виртуальной машиной –
Java Virtual Machine (Java VM, JVM) — виртуальная машина Java —
основная часть исполняющей системы Java, так называемой Java
Runtime Environment (JRE)
Microsoft Intermediate Language (MSIL, «Промежуточный
язык фирмы Майкрософт») в Visual Studio

10.

Фазы процесса трансляции (compilation phases)
Процесс создания компилятора можно свести к решению нескольких
задач, которые распределяются между фазами компиляции. Обычно
компилятор состоит из следующих фаз:
лексический анализ
синтаксический анализ
семантический (видозависимый) анализ
оптимизация
генерация кода.
Дополнительно могут быть использованы фазы перевода в
промежуточное представление, семантического анализа компонент
промежуточного представления, анализа корректности и оптимизации
промежуточного представления
Интерпретатор отличается тем, что фаза генерации кода обычно
заменяется фазой эмуляции элементов промежуточного
представления или объектной модели языка. Кроме того, в
интерпретаторе обычно не проводится оптимизация
промежуточного представления, а сразу же осуществляется его
эмуляция.

11.

Лексический анализатор
выполняет распознавание лексем языка и замену их соответствующими кодами
Лексический анализатор читает поток символов, составляющих исходную
программу, и группирует эти символы в значащие последовательности,
называющиеся лексемами. Для каждой лексемы анализатор строит
выходной токен (token) вида:

12.

Лексический анализ
position = position + rate*60;
Лексический
анализ
id1 = id2 + id3*60;
Лексический анализатор читает поток символов, составляющих исходную программу,
и группирует эти символы в значащие последовательности, называющиеся лексемами.
Для каждой лексемы анализатор строит выходной токен (token)
Создание токенов и таблицы лексем

13.

Синтаксический анализатор (syntax analyzer, parser)
необходим для того, чтобы выяснить, удовлетворяют ли предложения, из
которых состоит исходная программа, правилам грамматики этого языка.
Он получает на вход результат работы лексического анализатора и
разбирает его в соответствии с некоторой грамматикой.
Синтаксический анализ
id1 = id2 + id3*60;
Syntax analysis
=
id1
+
id2
*
id3
60
В дереве разбора программы внутренние узлы соответствуют
операциям, а листья представляют операнды.

14.

Видозависимый анализ (type checking),
также называемый семантическим анализом (semantic analysis), обычно
заключается в проверке правильности типа и вида всех идентификаторов
и данных, используемых в программе.
Видозависимый анализ
=
+
id1
id2
*
id3
int_to_real
60

15.

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

16.

Фаза генерации кода (code generator)
Генератор кода получает в качестве входных данных промежуточное
представление исходной программы и отображает его в целевой язык
Генерация кода
temp1 = id3* 60.0
id1 = id2 + temp1
Генератор
ldsfld
ldc.r8 60.
mul
stloc
ldsfld id2
ldlo с
add
stsfld id1
кода
id3
temp
temp

17.

Под просмотром (или проходом) компилятора
понимается процесс обработки всего, возможно, уже преобразованного,
текста исходной программы.
Одна или несколько фаз компиляции могут выполняться на одном просмотре.
Например, лексический анализ и синтаксический анализ часто выполняются на
одном просмотре, т.е. синтаксический анализатор может обращается к
лексическому анализатору за очередной лексемой лишь по мере необходимости.
С другой стороны, некоторые оптимизации могут выполняться на нескольких
просмотрах.

18.

Обобщенная структура транслятора
Учитывая схожесть компилятора и интерпретатора, рассмотрим фазы,
существующие в компиляторе. В нем выделяются:
Фаза лексического анализа.
Фаза синтаксического анализа, состоящая из: распознавания
синтаксической структуры; семантического разбора, в процессе
которого осуществляется работа с таблицами, порождение
промежуточного семантического представления или объектной модели
языка.
Фаза генерации кода, осуществляющая: семантический анализ
компонент промежуточного представления или объектной модели
языка; перевод промежуточного представления или объектной модели
в объектный код.
Наряду с основными фазами процесса трансляции возможны также
дополнительные фазы:
Фаза исследования и оптимизации промежуточного
представления, состоящая из:
— анализа корректности промежуточного представления;
— оптимизации промежуточного представления.

19.

Обобщенная структура компилятора

20.

Обобщенная структура интерпретатора

21.

Обобщенная схема синтаксического анализатора

22.

Варианты взаимодействия блоков транслятора
Организация процессов трансляции, определяющая реализацию
основных фаз, может осуществляться различным образом.
Это определяется различными вариантами взаимодействия блоков
транслятора: лексического анализатора, синтаксического анализатора и
генератора кода. Несмотря на одинаковый конечный результат,
различные варианты взаимодействия блоков транслятора
обеспечивают различные варианты хранения промежуточных данных.
Можно выделить два основных варианта взаимодействия блоков
транслятора:
многопроходную организацию, при которой каждая из фаз является
независимым процессом, передающим управление следующей фазе
только после окончания полной обработки своих данных;
однопроходную организацию, при которой все фазы представляют
единый процесс и передают друг другу данные небольшими
фрагментами.
На основе двух основных вариантов можно также создавать их

23.

Многопроходная схема взаимодействия блоков компилятора

24.

Однопроходная схема взаимодействия блоков компилятора при
управлении, инициируемом лексическим анализатором

25.

Однопроходная схема взаимодействия блоков компилятора при
управлении, инициируемом синтаксическим анализатором

Источник: ppt-online.org

Русские Блоги

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

Схема процесса выглядит следующим образом:

1. Препроцессор: конвертируйте файлы .c в файлы .i, используется команда gcc: gcc -E, что соответствует команде предварительной обработки cpp;
2. Компилятор: конвертируйте файлы .c / .h в файлы .s, используется команда gcc: gcc –S, что соответствует команде компиляции cc –S;
3. Ассемблер: конвертируйте файлы .s в файлы .o, используется команда gcc: gcc -c, соответствующая команде сборки:
4. Компоновщик: преобразуйте файл .o в исполняемую программу, используется команда gcc: gcc, которая соответствует команде ссылки ld;
5. Загрузчик: загружает исполняемые программы в память и запускает их, загрузчик и ld-linux.so.

Во-вторых, процесс компиляции

Процесс компиляции можно разделить на два этапа: компиляция и сборка.

2.1 Компиляция

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

Процесс компиляции исходных файлов состоит из двух основных этапов:

Первый этап — этоЭтап предварительной обработки выполняется перед этапом формальной компиляции. На этапе предварительной обработки содержимое исходного файла будет изменено в соответствии с инструкциями предварительной обработки, которые были помещены в файл.

В основном занимаются следующими аспектами:

1. Инструкции по определению макроса, такие как #define a b. Для этого типа псевдо-инструкций перед компиляцией необходимо заменить все a в программе на b, но строковая константа a не заменяется. Также есть #undef, он отменяет определение определенного макроса, так что вхождение строки не будет заменено в будущем.
2. Инструкции условной компиляции, такие как #ifdef, #ifndef, #else, #elif, #endif и т. Д. Введение этих псевдо-инструкций позволяет программистам решать, какие коды компилятор будет обрабатывать, определяя различные макросы. Предварительный компилятор отфильтрует ненужные коды по соответствующим файлам.
3. Заголовочный файл содержит инструкции, такие как #include «FileName» или #include и т. Д. Эта директива добавляет все определения из файла заголовка в выходной файл, который он создает для обработки компилятором.
4. Специальные символы, предварительный компилятор может распознавать некоторые специальные символы. Например, логотип LINE в исходной программе будет интерпретироваться как текущий номер строки (десятичное число), а FILE будет интерпретироваться как имя исходной программы C, которая в настоящее время компилируется. Предварительно скомпилированная программа заменит эти строки, появляющиеся в исходной программе, соответствующими значениями.

Основная цель файла заголовка — сделать определенные определения доступными для нескольких различных исходных программ на языке C. Это включает в себя расположение файла заголовка, то есть путь поиска. Правила поиска в заголовочном файле следующие:

1. Все поиски файла заголовка будут начинаться с -I
2. Затем найдите путь, указанный в переменных среды C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, OBJC_INCLUDE_PATH
3. Найдите каталог по умолчанию (/ usr / include, / usr / local / include, /usr/lib/gcc-lib/i386-linux/2.95.2/include . )

Второй этап — этап компиляции и оптимизации,Работа компилятора заключается в прохождении лексического анализа и грамматического анализа, после подтверждения того, что все инструкции соответствуют грамматическим правилам, он переводится в эквивалентное промежуточное представление кода или ассемблерный код.

2.2 Сборка

Ассемблер фактически относится к процессу перевода ассемблера (как) кода языка ассемблера в целевые машинные инструкции. В целевом файле хранится машинный код целевой программы, эквивалентной исходной программе. Целевой файл состоит из сегментов. Обычно объектный файл состоит как минимум из двух разделов:

• Сегмент кода: этот сегмент содержит в основном программные инструкции. Этот раздел обычно доступен для чтения и выполнения, но не для записи.
• Сегмент данных: в основном хранит различные глобальные переменные или статические данные, которые будут использоваться в программе. Как правило, сегменты данных доступны для чтения, записи и выполнения.

2.3 Целевой файл (исполняемый и связываемый формат)

1. Перемещаемые файлы: генерируются компилятором и ассемблером и могут быть объединены с другими перемещаемыми объектными файлами для создания исполняемого или общего объектного файла;
2. Общий объектный файл: особый тип перемещаемого объектного файла, который может быть добавлен в объектный файл при компоновке (статическая разделяемая библиотека) или динамически загружен в память и выполнен во время загрузки или во время выполнения (динамическая разделяемая библиотека);
3. Исполняемый (Executable) файл: он создается компоновщиком и может быть напрямую загружен в память загрузчиком, чтобы действовать как файл для выполнения процесса.

2.4 Статические и динамические библиотеки

Статическая библиотека — это отдельный файл, сформированный путем упаковки связанных целевых модулей. Используйте команду ar.

Преимущества статических библиотек:

• Программисту не нужно явно указывать все целевые модули, которые необходимо связать, потому что спецификация — это трудоемкий и подверженный ошибкам процесс;
• При компоновке компоновщик копирует из статической библиотеки только целевой модуль, на который ссылается программа, тем самым уменьшая размер исполняемого файла на диске и в памяти.

Динамическая библиотека — это специальный объектный модуль, который может быть загружен по любому адресу памяти во время выполнения или связан с любой программой.

Преимущества динамических библиотек:

• Обновите динамическую библиотеку без повторного связывания; для больших систем повторное связывание — очень трудоемкий процесс;
• Он может использоваться несколькими программами во время работы, требуется только одна копия в памяти, что экономит память.

В-третьих, процесс ссылки

Компоновщик в основном соединяет связанные объектные файлы для создания загружаемых и исполняемых объектных файлов. Основная работа компоновщика — разрешение и перемещение таблицы символов.

3.1 Время перехода по ссылке:

1. При компиляции, когда исходный код компилируется в машинный код (отвечает статический компоновщик);
2. При загрузке, то есть при загрузке программы в память (отвечает загрузчик);
3. Во время выполнения это реализуется приложением (за это отвечает динамический компоновщик).

3.2 Роль ссылок (повторное использование программного обеспечения):

1. Сделайте возможной отдельную компиляцию;
2. Динамическая привязка (привязка): раздельное определение, реализация и использование

3.3 Путь поиска в статической библиотеке (отвечает статическим компоновщиком)

1. gcc сначала ищет от -L;
2. Найдите путь поиска, указанный в переменной среды LIBRARY_PATH;
3. Затем найдите каталог по умолчанию / lib / usr / lib / usr / local / lib, который был написан в программе, когда изначально была написана компиляция gcc.

3.4 Путь поиска в динамической библиотеке (отвечает динамический компоновщик)

1. Путь поиска динамической библиотеки, указанный при компиляции целевого кода -L;
2. Путь поиска динамической библиотеки, указанный переменной среды LD_LIBRARY_PATH;
3. Путь поиска динамической библиотеки, указанный в файле конфигурации /etc/ld.so.conf;
4. Путь поиска динамической библиотеки по умолчанию / lib / usr / lib / / usr / local / lib

3.5 Статическая ссылка (во время компиляции)

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

Чтобы создать исполняемый файл, компоновщик должен выполнить основные задачи:

1. Анализ символов: свяжите определение и ссылку на символы в целевом файле;
2. Перемещение: соотнесите определение символа с адресом памяти, а затем измените все ссылки на символ.

Последующее исследование таблицы символов и анализа символов и анализа перемещений.

3.6 Динамическая ссылка (загрузка, время выполнения)

Таким образом, определение функции находится в объектном файле библиотеки динамической компоновки или совместно используемого объекта. На этапе компоновки компиляции библиотека динамической компоновки предоставляет только таблицу символов и небольшой объем другой информации, чтобы гарантировать, что все ссылки на символы определены, чтобы гарантировать беспрепятственное прохождение компиляции. Компоновщик динамического компоновщика (ld-linux.so) динамически загружает разделяемую библиотеку в соответствии с записанным определением символа разделяемого объекта во время работы, а затем завершает перемещение. Когда этот исполняемый файл выполняется, все содержимое библиотеки динамической компоновки будет отображаться в виртуальное адресное пространство соответствующего процесса во время выполнения. Программа динамической компоновки найдет соответствующий код функции в соответствии с информацией, записанной в исполняемой программе. Чтобы

В-четвертых, процесс загрузки

Загрузчик загружает исполняемый файл из внешней памяти в память и выполняет его. Образ памяти при выполнении процесса в Linux выглядит следующим образом:

Процесс загрузки следующий:

Загрузчик сначала создает образ памяти, как показано на рисунке выше, а затем копирует целевой файл в сегменты данных и кода в памяти в соответствии с таблицей заголовков сегментов. Затем загрузчик переходит к точке входа в программу (адрес символа _start) и выполняет код запуска.Последовательность вызова кода запуска следующая:

Пять общих инструментов для достижения целей

Система UNIX предоставляет ряд инструментов, помогающих понять и обработать целевые файлы. Пакет GNUbinutils также предоставляет большую помощь. Эти инструменты включают:

• AR: создание статической библиотеки, вставка, удаление, список и извлечение членов;
• СТРОКИ: Список всех печатаемых строк в целевом файле;
• STRIP: удалить информацию таблицы символов из целевого файла;
• NM: перечислить символы, определенные в таблице символов целевого файла;
• РАЗМЕР: укажите имя и размер раздела в целевом файле;
• READELF: отображение полной структуры целевого файла, включая всю информацию, закодированную в заголовке ELF.
• OBJDUMP: отображает всю информацию о целевом файле.Самая полезная функция — дизассемблировать двоичные инструкции в разделе .text.
• LDD: список общих библиотек, которые требуются исполняемому файлу во время выполнения.

Интеллектуальная рекомендация

mapReduce-slice (разделить)

1. Связь между маской карты и фрагментом. Количество задач карты определяется количеством срезов.Существует столько задач карты, сколько срезов. Срез — это логическая концепция, которая относится к ди.

Источник: russianblogs.com

Введение в платформу .NET Framework и ASP.NET

Как мы разобрались в предыдущей лекции, процесс компиляции и исполнения приложений . NET отличается от процесса исполнения традиционных ( native ) приложений. При компиляции приложения . NET на выходе получается бинарный файл , который содержит команды на языке MSIL , а не инструкции для центрального процессора. Этот факт отличает процесс функционирования приложений . NET . Фактически, приложения . NET компилируются в два этапа:

• Исходный код (на языке C#, Visual Basic или др.) преобразуется в MSIL;
• Код на языке MSIL преобразуется в машинный код.

Теоретически, программный код, разработанный на разных языках программирования в среде . NET (C#, Visual Basic . NET и др.) и преобразованный в код на языке MSIL , в конечном счете, будет иметь одинаковый вид. Кроме того, после преобразования программного кода в MSIL будет затруднительно определить исходный язык программирования .

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

При этом при игнорировании особенностей разработки под конкретную платформу могут быть как некритические последствия (например, в виде снижения производительности), так и критические (например, неработоспособность приложения). В связи с этим зачастую можно видеть два типа пакетов распространения приложения (32- и 64-разрядных).

Более того, для более эффективной работы приложения нередко требуется оптимизация его кода. Все эти задачи имеют непростую природу и могут отнимать у разработчика приложения много времени. Разработчик в этом случае должен тратить свое время не на улучшение логики программы, а заботиться об инфраструктурных задачах. Однако, несмотря на всю сложность этого процесса, существуют алгоритмы, которые способны выполнить большую часть работы по оптимизации кода под конкретную платформу без участия человека. Именно этой идеологии придерживается платформа . NET Framework.

При запуске кода на языке IL происходит его преобразование в машинный код. При этом весь процесс преобразования происходит в той среде, где приложение должно быть запущено (на компьютере конечного пользователя, где исполняется приложение ). Этот факт позволяет оптимизировать конечный машинный код, который получается в процессе преобразования, для той платформы, в рамках которой он будет исполняться. Также при таком подходе нет необходимости иметь две различных сборки для разных сред (32- и 64-разрядных) – конечный машинный код будет получен с учетом специфики платформы. Поскольку преобразование » MSIL – машинный код» требует определенного времени, среда исполнения записывает полученный машинный код в системных папках и при последующем запуске приложения, которое запускалось ранее, используется уже готовый код. Общий процесс компиляции выглядит следующим образом.

Механизм, который занимается преобразованием кода MSIL в машинный код, называется компилятором JIT (» just-in-time «). Этот компилятор преобразует код MSIL в машинный код «на лету». Это позволяет сделать процесс запуска приложений более «прозрачным». При запуске исполняемого файла . NET компилятор автоматически определяет, была ли эта сборка скомпилирована.

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

Несмотря на то, что подобный способ позволяет более гибко подойти к разработке и распространению приложения, он обладает недостатком – для запуска приложения требуется несколько больше времени, нежели для запуска традиционного приложения. Это вытекает из того, что приложению требуется время на получение машинного кода. Этот недостаток компенсируется тем, что при запуске приложение компилируется в машинный код не полностью, а только те части, которые исполняются; также после первого запуска приложения оно будет скомпилировано и время на компиляцию больше не потребуется.

В случае, когда необходимо выполнить предкомпиляцию приложения до его запуска (для предотвращения ситуации компиляции приложения «на лету»), можно воспользоваться утилитой NGen ( native image generator ), которая поставляется в составе . NET Framework. Утилита NGen использует аналогичные методы компиляции приложения, что и компилятор JIT . Однако, от компилятора JIT эту утилиту отличает три аспекта:

• преобразование кода MSIL в машинный код производится перед выполнением приложения, а не в момент исполнения;
• преобразовываются сразу вся сборка, а не отдельные методы;
• полученный машинный код сохраняется в кэше образа машинного кода в виде файла на жестком диске.

Утилита NGen является консольным приложением и запускается из командной строки. Она позволяет сделать несколько различных действий:

• скомпилировать сборку и установить ее в кэш сборок (ключ install );
• удалить сборку из кэша сборок (ключ uninstall );
• обновить сборку в кэше сборок (ключ update );
• отобразить состояние процесса компиляции (ключ display );
• управлять очередью выполнения компиляции (ключ queue ).

Общий процесс компиляции приложений . NET представлен на следующей схеме.

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

Краткие итоги

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

Источник: intuit.ru