Глубокое знание IL важно для разработки .net - PullRequest
14 голосов
/ 08 февраля 2010

Когда я делал в основном c ++, я знал, что важно знать ассемблер, и написал некоторый не пробный асм-код, чтобы я мог действительно понять, что происходит. Сейчас я делаю в основном .net, и хотя у меня есть некоторое понимание IL, я ни в коем случае не опытный.

Является ли IL навыком, о котором нужно знать, или будет изучать IL более полно, чтобы сообщить, как я использую и пишу код .net?

Ответы [ 7 ]

21 голосов
/ 08 февраля 2010

Полное изучение IL во многом похоже на изучение ассемблера.

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

Однако для большинства «повседневных» задач программирования я не думаю, что действительно необходимо понимать IL, так же как большинству программистов на C ++ не нужно , чтобы знать, как писать ассемблер .

При этом, если вы понимаете ассемблерный код с фоном C ++, получить общее представление о IL будет очень и очень просто ...

8 голосов
/ 08 февраля 2010

Если вы просто пытаетесь написать приложение .NET, вам не нужны какие-либо практические знания по IL-коду. Большинство разработчиков .NET не знают, как писать в коде IL.

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

5 голосов
/ 08 февраля 2010

Помимо очевидного (реализация виртуальной машины), определенные типы задач требовали довольно глубокого понимания IL.

  • Написание динамического кода. Это было довольно хорошо заменено API-интерфейсом System.Linq.Expressions, особенно с учетом его возможностей в .NET 4.
  • Написание компилятора для нового языка для CLI. Такие проекты, как Общая инфраструктура компилятора , нацелены на уменьшение количества фактических писателей компилятора кода CIL.

Один из самых интересных для меня аспектов лично - это изучение влияния языка IL на компилятор, работающий точно в срок. Одним примечательным примером, сравнивающим JVM и CLI, является то, что CLI имеет понятие не виртуальных методов и прямой диспетчеризации, что позволяет неоптимизирующему (базовому) компилятору генерировать особенно эффективные вызовы. Этот анализ более затратен в JVM, поэтому базовый компилятор не может оптимизировать столько случаев.

В ответ на оригинальный вопрос:

Как правило, разработчикам .NET не нужно беспокоиться об изучении CIL. Если в вашей работе используются динамические / динамически генерируемые методы, вам следует оценить способность API-интерфейса Expressions удовлетворять ваши потребности, поскольку он чрезвычайно более удобен в использовании / обслуживании. Я провел несколько недель, испуская CIL с ILGenerator. Мне потребовалось всего один рабочий день, чтобы преобразовать в Expressions, сэкономив более ста строк кода и исправив старые ошибки, которые я просто не обнаружил.

Детальное знание CIL очень важно для любого, кто внедряет виртуальную машину CLI или пишет компиляторы (AOT или JIT). Я нахожу это и интересным, и полезным, но с точки зрения «важных вещей, которые нужно знать, чтобы быть продуктивным разработчиком», это просто не так высоко.

3 голосов
/ 08 февраля 2010

На самом деле в .NET Framework есть только одно место, где у вас есть , чтобы узнать IL, классы в пространстве имен System.Reflection.Emit. Он позволяет генерировать код на лету, что может быть полезно в некоторых случаях.

Лучший способ получить воздействие IL - это средство Ildasm.exe, Reflector также может работать. Очень удобный способ запустить его - добавить его в меню «Инструменты». Инструменты + Внешние инструменты, Добавить.

  • Название = Ildasm
  • Command = c: \ Program Files \ Microsoft SDKs \ Windows \ v6.0A \ Bin \ ildasm.exe
  • Аргументы = $ (TargetPath)
  • Начальный каталог = $ (TargetDir)

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

Следующий шаг - посмотреть, как IL переводится в машинный код. Начните отладку, щелкните правой кнопкой мыши код и выберите «Перейти к разборке». Помните, что вы не увидите реальный машинный код, если не запустите сборку Release и не включите оптимизацию JIT. Инструменты + Параметры, Отладка, снимите флажок «Подавить оптимизацию JIT при загрузке модуля».

1 голос
/ 08 февраля 2010

Знание ассемблера было очень хорошо для C / C ++ в Visual Studio. Вы всегда можете пойти на разборку, чтобы увидеть, что происходит.

Если вы попробуете то же самое в C #, т. Е. "Перейти к разборке", вы все равно перейдете к собственному коду, а не к IL. В этом смысле IL не так полезен, как реальная сборка.

Но IL хорош для просмотра внутренних сборок, в которых у вас тоже нет исходного кода. (Но вы можете использовать для этого отражатель )

1 голос
/ 08 февраля 2010

Зависит. Знание IL, вероятно, поможет вам понять, во что превращается ваш код. Если у вас есть хорошие знания о IL, вы даже можете создавать новые компоненты во время выполнения (если вам нужно). Это важно? Вероятно, нет.

0 голосов
/ 08 февраля 2010

Нет, как сказал большинство. Плюс, чтобы добавить к их комментариям, посмотрите, почему вы используете C / C ++ и почему вы используете .NET и его языки (lik C #):

C / C ++ был создан для того, чтобы дать вам возможность управлять компьютером приятным абстрактным способом. Он конвертируется ПОЧТИ непосредственно в язык ассемблера и дает вам большую силу добра (и зла). Такие вещи, как указатели, поощряются, а сбор мусора отсутствует. Следовательно, вы должны знать, что делает код на ассемблере, из-за того, что вы можете сделать.


.NET языки были созданы для быстрого создания отличных приложений и ограничения ущерба, который вы можете нанести этим приложениям. Это отговаривает вас использовать реальную власть над процессором (как не рекомендуется указателям, и вам больше не нужно беспокоиться о сборке мусора.) По сути, ущерб, который вы можете нанести, ограничен приложением; и мало что связано с процессором (если вы не балуетесь небезопасным кодом, который используется только в редких случаях [по моему опыту]). Кроме того, код .NET преобразуется в IL, затем IL преобразуется в ассемблер и т. Д. Вы не имеете прямого отношения к языку ассемблера в любом случае.


Тем не менее, полезно знать ИЛ по знаниям о голове и может вам немного помочь. Но знание этого не сильно поможет вам в создании отличного приложения, которое является основой языков .NET для большинства разработчиков, не работающих в Microsoft.

...