В чем разница между управляемым/байтовым кодом и неуправляемым/машинным кодом?

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

Это пространство эквивалентно ресурсам компьютера, таким как ОЗУ, жесткий диск и т. д.

Управляемый код позволяет системе автоматически выбирать, когда и что следует очистить. Неуправляемый код делает процесс "ручным" - в том, что программист должен сказать системе, когда и что нужно очистить.

Я поражен тем, что получается из этой дискуссии (ну, не совсем, но риторически). Позвольте мне кое-что добавить, даже если я опоздаю.

Виртуальные машины (VMs) и сбор мусора (GC) являются десятилетиями и двумя отдельными концепциями. Скомпилированные языки с нативным кодом, собранные мусором, существуют, даже они десятилетиями (канонический пример: ANSI Common Lisp ; Ну, есть, по крайней мере, время компиляции сбор мусора декларативный язык, Mercury - но, по-видимому, массы кричат на Прологоподобных языках).

Вдруг сохранения мира байт-код виртуальных машин являются панацеей от всех его болезней. песочница существующих двоичных файлов (другие примеры здесь, здесь и здесь )? принцип наименьшего авторитета (POLA)/безопасность на основе возможностей ? тонкий двоичные файлы (или его современный вариант SafeTSA)? вывод области ? Нет, сэр: Microsoft & Sun не разрешает нам даже только подумайте о таких извращениях. Нет, лучше переписать весь наш программный стек для этого замечательного(???) новый(???) язык§ / API. Как говорит один из наших хозяев, это огонь и движение все сначала.

Не глупите: я знаю, что C# - не единственный язык, предназначенный для .Net / Mono, это гипербола .

Edit: особенно поучительно взглянуть на комментарии к этому ответу С. Лотта в свете альтернативных методов для памяти управление/безопасность / мобильность кода, на которую я указал.

Я считаю, что нетехнические люди не должны беспокоиться о технических деталях на этом уровне детализации.

С другой стороны, если они впечатлены маркетингом Microsoft/Sun, необходимо объяснить им, что их обманывают - виртуальные машины на основе байт-кода не являются такой новинкой, как они утверждают, они не решают волшебным образом все ИТ-проблемы, и альтернативы этим методам реализации существуют (некоторые из них являются лучше).

Правка 2: сборка мусора-это метод управления памятью, и, как и любой метод реализации, его нужно понимать, чтобы правильно использовать. Посмотрите, как в ITA Software они обходят GC, чтобы получить хорошую производительность :

4-поскольку у нас есть около 2 гигабайт статических данных, нам нужен быстрый доступ к ним . , мы используем код C++ для отображения памяти. файлы, содержащие беспредметные структуры C (о рейсах, тарифах и т. д.), а затем доступ к ним из общего Использование Lisp доступ к иностранным данным. Поле структуры доступ компилируется в два или три инструкции, так что на самом деле нет любое исполнение. штраф за доступ C, а не объекты Lisp. Поступая это, мы сохраняем мусор Lisp сборщик от просмотра данных (до Lisp, каждый указатель на объект C является просто fixnum, хотя мы часто это делаем временно оберните эти указатели в Лисповые объекты для улучшения отладочность). Наши шепелявые образы поэтому только около 250 мегов "рабочие" структуры данных и код.

...

9 - мы можем сделать 10 секунд вычисления Lisp на коробке 800 МГц и минусы менее 5 тыс. данных. Это потому что мы предварительно выделяем все структуры данных, которые мы потребность и умереть на запросы, которые превышают их. Это может заставить многих шепелявить программисты съеживаются, но с 250 мегабайт ограничения изображения и реального времени, мы не могу позволить себе генерировать мусор . Для например, вместо того, чтобы использовать минусы, мы используйте "минусы!", который захватывает клетки из один массив из 10 000 000 ячеек, которые мы имеем предварительно выделенный и который сбрасывается каждый запрос.

Edit 3: (чтобы избежать недоразумений) является ли GC лучше, чем возиться непосредственно с указателями? Большую часть времени, конечно, но есть альтернативы обоим. Есть ли необходимость беспокоить пользователей этими деталями? Я не вижу никаких доказательств, что это так, кроме того, что при необходимости развеивается некоторая маркетинговая шумиха.

Я почти уверен, что основная интерпретация такова:

• управляемый = очистка ресурсов, управляемая средой выполнения (т. е. сборкой мусора)
• неуправляемый = убирать за собой (т. е. malloc & free)

Возможно, сравнить это с инвестированием в фондовый рынок.

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

Вот мой ответ:

Управляемый (.NET) или байт-код (Java) сэкономит вам время и деньги.

Теперь давайте сравним два:

Неуправляемый или машинный код

Вам необходимо выполнить выделение и очистку собственных ресурсов (ОЗУ / памяти). Если вы что-то забудете, вы в конечном итоге получите так называемую "утечку памяти", которая может привести к сбою компьютера. Утечка памяти-это термин, обозначающий, когда приложение начинает использовать (съедать) оперативную память/память, но не отпускает ее, чтобы компьютер мог используйте if для других приложений; в конечном итоге это приводит к сбою компьютера.

Для запуска вашего приложения на различных операционных системах (Mac OSX, Windows и т. д.) вам нужно скомпилировать свой код специально для каждой операционной системы и, возможно, изменить много кода, специфичного для операционной системы, чтобы он работал на каждой операционной системе.

Управляемый код .NET или байтовый код Java

Все выделение и очистка ресурсов (ОЗУ / памяти) выполняются за вас и риск возникновения "утечек памяти" сведен к минимуму. Это позволяет больше времени кодировать функции вместо того, чтобы тратить его на управление ресурсами.

Для запуска вашего приложения на различных операционных системах (Mac OSX, Windows и т. д.) вы просто компилируете один раз, и он будет работать на каждом, пока они поддерживают данную платформу, на которой вы запускаете приложение (.NET Framework / Mono или Java).

Короче Говоря

Разработка с использованием .NET Framework (управляемый код) или Java (байтовый код) делает в целом дешевле создание приложения, которое может легко ориентироваться на несколько операционных систем, и позволяет тратить больше времени на создание богатых функций вместо обычных задач управления памятью/ресурсами.

Также, прежде чем кто-нибудь указывает, что .Net платформа не поддерживает несколько операционных систем, я должен заметить, что технически система Windows 98, относится к 32-бит, относится к 64-бит, поддерживается удаление спама не 32-разрядные, поддерживается удаление спама 64-бит и Windows сервера все разные Операционные системы, но одно и то же приложение .NET будет работать на каждой из них. И, есть также проектMono , который приносит .NET в Linux и Mac OSX.

Неуправляемый код-это список инструкций, которым должен следовать компьютер. Управляемый код-это список задач для компьютера, которые компьютер может интерпретировать самостоятельно.

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

Есть и другие отличия, но управление памятью, вероятно, самое большое.

Если бы они были все еще интересно, что я мог бы упомянуть, как много эксплойтов от переполнения буфера и что вы не получаете этого с управляемым кодом, или что повторное использование кода теперь легко, или что нам больше не нужно иметь дело с COM (Если вам все равно повезет). Я бы, наверное, держался подальше от кома, иначе разразился бы тирадой о том, как это ужасно.

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

Или используйте футбол со стенами вместо боковых линий и концевых линий, или бейсбол без задней опоры, или хоккей без сетки за воротами, или NASCAR без барьеров, или футбол без шлемов ...)

" особый термин управляемый код особенно распространен в мире Microsoft."

Поскольку я работаю в мире MacOS и Linux, это не тот термин, который я использую или встречаю.

В блоге Брэда Абрамса "What is Managed Code" есть определение, которое говорит такие вещи, как ".NET Framework Common Language Runtime".

Моя точка зрения такова: может быть, вообще не стоит объяснять это терминами. Если это ошибка, взлом или обход, это не очень важно. Конечно, нет. достаточно важная, чтобы составить сложное описание непрофессионалов. Он может исчезнуть со следующим выпуском некоторой партии продуктов MS.