Может ли управляемый код (в частности, .NET) когда-либо стать «неуправляемым»? - PullRequest
3 голосов
/ 02 апреля 2009

Недавно я разговаривал с моим другом, который начал заниматься C ++ пару месяцев назад (его первое знакомство с программированием). Мы попали на тему C # и .NET в целом, и он указал мне, что, по его мнению, он «обречен» на все часто упоминаемые проблемы (низкая скорость, байт-код с возможностью взлома и т. Д.). Я согласился с ним по всем этим вопросам, но я сдержался, сказав, что он обречен только потому, что чувствовал, что со временем такие языки, как C #, могут вместо этого стать нативным кодом (если Microsoft решит изменить реализацию .NET с байт-код, среда выполнения JIT, которая компилируется непосредственно в нативный код, как ваша программа на C ++).

У меня вопрос, я здесь на обед? Я имею в виду, что это может занять много работы (и может сломать слишком много вещей), но не существует какого-то магического барьера, который препятствует компиляции кода C # изначально (если кто-то хотел это сделать), верно? Было время, когда C ++ считался языком очень высокого уровня (который он все еще есть, но не так много, как в прошлом), но теперь это основа (наряду с C) для нативных API Microsoft. Идея о том, что однажды .NET может быть на одном уровне с C ++ в этом отношении, кажется мне вопросом времени и усилий, а не фундаментальным недостатком в дизайне языка.

РЕДАКТИРОВАТЬ : Я должен добавить, что если возможна собственная компиляция .NET, почему Microsoft решает не идти по этому пути? Почему они выбрали путь байт-кода JIT?

Ответы [ 7 ]

28 голосов
/ 02 апреля 2009

Java использует байт-код. В C #, хотя он использует IL в качестве промежуточного шага, всегда компилируется в собственный код. IL никогда напрямую не интерпретируется для выполнения, как байт-код Java. Вы можете даже предварительно скомпилировать IL перед распространением, если действительно хотите (подсказка: производительность обычно лучше в долгосрочной перспективе , если вы этого не сделаете).

Идея, что C # медленен, смешна. Некоторые из компонентов winforms работают медленно, но если вы знаете, что делаете, сам C # - очень быстрый язык. В наше время все сводится к алгоритму; Выбор языка не поможет вам, если вы внедрите плохую пузырьковую сортировку. Если C # поможет вам использовать более эффективные алгоритмы более высокого уровня (и по моему опыту это обычно делает), это превзойдет любые другие проблемы со скоростью.


На основании ваших правок я также хочу еще раз объяснить (типичный) путь компиляции.

C # компилируется в IL. Этот IL распространяется на локальные машины. Пользователь запускает программу, и эта программа затем JIT-компилируется в собственный код для этой машины один раз . В следующий раз, когда пользователь запускает программу на этом компьютере, он запускает полностью нативное приложение. Есть также оптимизатор JIT, который может немного запутать, но это общая картина.

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


Относительно декомпиляции:

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

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

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


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

1 голос
/ 02 апреля 2009

чувак, к вашему сведению, вы всегда можете скомпилировать ваши сборки c # в собственное изображение, используя ngen.exe

а вы предлагаете .net - это ущербный дизайн? это был .net, который вернул мс обратно в игру с их дерьмовых vb 5, vb 6, com дней. это была одна из их самых больших ставок

Java делает то же самое - значит, вы предполагаете, что Java тоже ошибка?

рег. крупные поставщики - обратите внимание. .net был чрезвычайно успешным среди компаний всех размеров (кроме тех парней с открытым исходным кодом - в этом нет ничего плохого) Все эти компании внесли значительный объем инвестиций в .net Framework.

и сравнивать скорость c # с c ++ - по моему мнению, безумная идея. С ++ дает вам управляемую среду вместе с мощным фреймворком мирового класса?

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

речь не идет о c ++ v / s c #, управляемые v / s неуправляемые. оба одинаково хороши и одинаково сильны в своих доменах

1 голос
/ 02 апреля 2009

C # может быть изначально скомпилирован с использованием такого инструмента, как NGEN, а команда MONO (open source .net framework) разработала полную AOT (заблаговременную) компиляцию, которая позволяет запускать c # на IPhone. Однако полная компиляция является трудоемкой, поскольку она разрушает кросс-платформенную совместимость, и некоторые машинные оптимизации не могут быть выполнены. Однако важно также отметить, что .net - это не интерпретируемый язык, а скомпилированный язык JIT (как раз вовремя), что означает, что он работает на компьютере.

1 голос
/ 02 апреля 2009

Вы предполагаете, что тот факт, что C # является управляемым кодом, является недостатком дизайна?

0 голосов
/ 02 апреля 2009

Обреченные? Из-за предполагаемых проблем с производительностью? Как насчет сравнения цены:

  • час программиста
  • аппаратные компоненты

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

Как насчет сравнения проблем с обслуживанием при попытке найти утечки памяти в коде C ++ по сравнению с кодом C #, собираемым мусором?

«Аппаратные средства дешевы, программисты дорогие»: http://www.codinghorror.com/blog/archives/001198.html

0 голосов
/ 02 апреля 2009

Конечно, может, но реальный вопрос - почему? Я имею в виду, конечно, что это может быть медленно (э), но в большинстве случаев любые существенные различия в производительности сводятся к проблемам проектирования (неправильные алгоритмы, конфликты потоков, перегрузка ресурсов и т. Д.), А не к проблемам с языком. Что касается «бьющегося» байт-кода, то, похоже, он не вызывает особого беспокойства у большинства компаний, учитывая скорость принятия.

Что на самом деле сводится к тому, что является лучшим инструментом для работы? Для некоторых это C ++; для других - Java; для других - C #, Python или Erlang.

0 голосов
/ 02 апреля 2009

C # может быть изначально скомпилирован, но вряд ли библиотека базовых классов когда-нибудь пойдет туда. С другой стороны, я действительно не вижу большого преимущества для выхода за рамки JIT.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...