Компиляция или усложнение .NET-кода?

Question

Q1) Почему C # изначально компилируется в IL, а затем во время выполнения выполняется JIT и запускается поверх виртуальной машины (?).Или это JIT, соответствующий машинному коду?

Q2) Если верно второе (JIT соответствует машинному коду), то где находится .Сетевая изолированная среда, в которой выполняется код?

Q3) Кроме того, почему код вообще компилируется в IL?Почему бы просто не постоянно компилироваться в машинный код?Для этого есть инструмент от MS под названием ngen, но почему это необязательно?

Answer 1

IL компилируется в формате JIT (JIT = Just In Time) в собственный машинный код во время выполнения процесса.

Использование уровня виртуальной машины позволяет .NET вести себя одинаково на разных платформах (например,int всегда имеет размер 32 бита, независимо от того, работаете ли вы на 32- или 64-битной машине, в C++ это не так).

JIT-компиляция позволяет оптимизации динамически адаптироваться к коду во время его выполнения (например,примените более агрессивную оптимизацию к частям кода, которые вызываются часто, или используйте аппаратные инструкции, доступные на конкретной машине, например SSE2), что невозможно сделать с помощью статического компилятора.

Answer 2

A1) JIT компилируется в машинный код

A2) В .net нет такого термина, как песочница.Вместо этого есть AppDomains .И они запускаются как часть среды CLR (т. е.как часть исполняемого процесса)

A3) Недостатки NGen от Джеффри Рихтера:

• Файлы NGEN'd могут быть не синхронизированы.Когда среда CLR загружает файл NGEN'd, она сравнивает ряд характеристик ранее скомпилированного кода и текущей среды выполнения .Если какая-либо из характеристик не совпадает, файл NGEN'd не может быть использован, и вместо него используется обычный процесс компиляции JIT.

• Низкая производительность во время загрузки (перебазирование / привязка).Файлы сборки являются стандартными файлами Windows PE, и, как таковые, каждый из них содержит предпочтительный базовый адрес.Многие разработчики Windows знакомы с проблемами, связанными с базовыми адресами и перебазированием.При JIT-компиляции кода эти проблемы не вызывают беспокойства, поскольку правильные ссылки на адреса памяти вычисляются во время выполнения.

• Низкая производительность во время выполнения.При компиляции кода NGen не может делать столько предположений о среде выполнения, сколько это может сделать JIT-компилятор.Это вызывает NGen.exe чтобы произвести уступает код.Например, NGen не оптимизирует использование определенных инструкций процессора;это добавляет косвенные ссылки для доступа к статическим полям, потому что фактический адрес статических полей неизвестен до времени выполнения.NGen вставляет код для вызова конструкторов класса везде, потому что он не знает порядка, в котором будет выполняться код и был ли уже вызван конструктор класса.

Answer 3

Вы можете использовать НГЕН для создания собственных версий ваших сборок .NET.Это означает, что JIT не придется делать это во время выполнения.

.NET сначала компилируется в IL, а затем в собственный формат, поскольку JIT был разработан для оптимизации кода IL для текущего процессора, на котором выполняется код.

Код .NET компилируется в IL для обеспечения совместимости.Поскольку вы можете создавать код с использованием C#, VB.NET и т. д., JIT необходим общий набор команд (IL) для компиляции в собственный код.Если бы JIT должен был знать о языках, то JIT необходимо было бы обновлять при выпуске нового языка .NET.

Я не уверен насчет вопроса об песочнице, я думаю, что приложение .NET работает с тремя доменами приложений.Один домен содержит среды выполнения .NET (mscorlib, system.dll и т. д.), другой домен содержит ваш код .NET, и я не могу вспомнить, для чего предназначен другой домен.Проверить http://my.safaribooksonline.com/9780321584090

Answer 4

1. C # компилируется в CIL (или IL), потому что он использует общую платформу с остальными .NET languages (именно поэтому вы можете написать DLL на C # и использовать ее в VB.NET или F # без проблем).Тот самый CLR затем JIT скомпилирует код в машинный код.

.NET также может быть запущен на нескольких платформах (Mono на * NIX и OS X).Если бы C # компилировался в машинный код, это было бы и близко не так просто.

2. Здесь нет песочницы.

3. Описано в ответе на вопрос № 1

Answer 5

A1) Таким образом, он не зависит от платформы (Windows, Linux, Mac), а также может использовать определенные оптимизации для вашего текущего оборудования.Когда он компилируется JIT, он преобразуется в машинный код.

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

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

Answer 6

Скомпилированный код .Net становится IL, который является промежуточным языком точно так же, как и объектный код Java.Да, можно генерировать собственный машинный код, используя НГен инструмент.NGen привязывает полученный собственный образ к машине, поэтому копирование двоичного файла ngen в другую систему не даст ожидаемых результатов.Компиляция в промежуточный код позволяет принимать решения во время выполнения, которые в противном случае невозможно (легко) принять с помощью статически типизированного языка, такого как C++, а также позволяет функционировать коду на различных аппаратных архитектурах, поскольку тогда код становится описательным в смысл того, что он также описывает цель того, что должно произойти, независимо от бита (например, 32 или 64), в отличие от машинно-специфичного кода, который работает только в 32-битных или 64-битных системах, но не в обоих случаях.

Кроме того, NGen не является обязательным, потому что, как я уже сказал, он привязывает двоичный файл к системе, он может быть полезен, когда вам нужна производительность скомпилированного машинного кода с гибкостью динамически типизированного языка, и вы знаете, что двоичный файл не будет перемещаться в система, к которой она не привязана.