Здравствуйте, vsb, Вы писали:
EP>>Предположу что это битность не байткода, а предпочитаемой цели. На x32/x64 разный объём доступной памяти, и разные размеры указателей (что влияет на потребление и в следствии скорость). vsb>Мне понятней не стало. Какая разница, какие там размеры указателей, это же деталь реализации.
Такая что от этого зависят характеристики конечного решения. Если на всё про всё достаточно достаточно адресного пространства x32 — то почему бы не сэкономить память и возможно увеличить быстродействие одним простым ключиком?
vsb>В Java нет ничего этого, например.
В Java и много чего другого нет. И если например рассматривать Java как язык — то вообще самый отстающий из мэйнстрима
vsb>> Плюс в x64 процесс нельзя загрузить x32 dll, которая может быть сторонней. vsb>Опять же какое дело байткоду до всего этого?
Ещё раз, причём тут байткод? Он, насколько я понял — одинаковый, меняется только соседствующий ключик
vsb>Запустишь 32-битной запускалкой — будет работать 32-битное приложение. Запустишь 64-битной запускалкой — будет работать 64-битное приложение.
Не будет работать, так как нужные .dll могут быть только под один из вариантов
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, Serginio1, Вы писали:
S>> Читаем выделенное. Net это MSIL. И он может по разному выполняться.
ARK>.NET — это VM для выполнения MSIL.
S>>>>Значит компилятор это VM? ARK>>>Нет, не значит. S>> Ну раз к >> .Net Native может и подходит
ARK>.NET и .NET Native — разные вещи, это так сложно понять? Хуже того, .NET Native не сможет даже корректно скомпилировать любой MSIL, который может сожрать CLR.
Давай разделять .NET Native и CLR. Они оба компилируют MSIL. Да у CLR больше возможностей.
Они оба являются подмножеством .Net S>> Под какой VM выполняется .Net Native
ARK>Ни под какой. Спрашиваю еще раз: какое отношение .NET Native имеет к виртуальной машине .NET, кроме возможности компилировать урезанный вариант MSIL?
Еще раз. Net это MSIL который компилируется либо в среде CLR либо сразу в машинный код.
Для того, что бы использовать рефлекссию для .NET Native нужено указать используемые классы https://msdn.microsoft.com/ru-ru/library/dn600638(v=vs.110).aspx ARK>>>Типа если человек может жрать траву, и корова может жрать траву, значит человек это корова. S>> Угу по твоей логике и ОС это вируальная машна.
ARK>Безусловно, ОС и VM имеют много общего. И в частных случаях одно может быть другим.
Ну по твоей терминалогии и Delphi это VM
1. Есть свой менеджер памяти
2. Есть динамическая компиляция MakeObjectInstance
3. Исключение и прочее.
и солнце б утром не вставало, когда бы не было меня
S>>Архитектура .NET[править | править вики-текст]
S>>Программа для .NET Framework, написанная на любом поддерживаемом языке программирования, сначала переводится компилятором в единый для .NET промежуточный байт-код Common Intermediate Language (CIL) (ранее назывался Microsoft Intermediate Language, MSIL). В терминах .NET получается сборка, англ. assembly.
S>>[q]
S>>Затем код либо исполняется виртуальной машиной Common Language Runtime (CLR), либо транслируется утилитой NGen.exe в исполняемый код для конкретного целевого процессора.
S>> Использование виртуальной машины предпочтительно, так как избавляет разработчиков от необходимости заботиться об особенностях аппаратной части. В случае использования виртуальной машины CLR встроенный в неё JIT-компилятор «на лету» (just in time) преобразует промежуточный байт-код в машинные коды нужного процессора. Современная технология динамической компиляции позволяет достигнуть высокого уровня быстродействия. Виртуальная машина CLR также сама заботится о базовой безопасности, управлении памятью и системе исключений, избавляя разработчика от части работы. S>>[/q]
S>> То есть даже NGEN это не виртуальная машина, хотя на самом деле как я уже давал ссылки
ARK>Ничего не понял. Есть такая поговорка — кто ясно мыслит, тот ясно излагает.
ARK>Вас словосочетание "Виртуальная машина CLR" в процитированном вами же тексте ни на что не наталкивает?
Ты выделенное прочитал?
Затем код либо исполняется виртуальной машиной Common Language Runtime (CLR), либо транслируется утилитой NGen.exe в исполняемый код для конкретного целевого процессора.
То есть NGET это уже не виртуальная машина. Вот и верь после этого Вики.
S>>
S>>NGEN по-прежнему полагается на полную среду CLR для таких сервисов, как загрузка сборок, удаленное и локальное взаимодействие, управление памятью, сбор мусора и, при необходимости, JIT-компиляция. В .NET Native многие из этих сервисов являются либо ненужными (JIT-компиляции), либо разрешаются во время построения и включаются в сборку приложения. Остальные сервисы, наиболее важным из которых является сбор мусора, включены в гораздо более компактную, оптимизированную среду выполнения mrt100_app.dll.
S>> Так, что верь Вики. Она тебя же и опровергает.
ARK>Где и в чем она меня опровергает?
ARK>Еще раз повторяю свою мысль: .NET — это виртуальная машина для выполнения IL, плюс библиотека классов. Что тут неясно? Тот факт, что есть отдельная вещь под названием .NET Native, ничего не доказывает и не опровергает. Любой язык можно компилировать или выполнять в виртуальной машине.
Common Language Runtime (англ. CLR — общеязыковая исполняющая среда) — исполняющая среда для байт-кода CIL (MSIL), в который компилируются программы, написанные на .NET-совместимых языках программирования (C#, Managed C++, Visual Basic .NET, F# и прочие). CLR является одним из основных компонентов пакета Microsoft .NET Framework.
Ну так по твоему компилятор это и есть VM. К чему и пришли
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, Serginio1, Вы писали:
S>> Читаем выделенное. Net это MSIL. И он может по разному выполняться.
ARK>.NET — это VM для выполнения MSIL.
S>>>>Значит компилятор это VM? ARK>>>Нет, не значит. S>> Ну раз к >> .Net Native может и подходит
ARK>.NET и .NET Native — разные вещи, это так сложно понять? Хуже того, .NET Native не сможет даже корректно скомпилировать любой MSIL, который может сожрать CLR.
Еще раз .Net это и CLR и .net Native. Да сейчас CLR превалирует, но это не надолго.
Есть куча вещей где нужна скорость выполнения, объем памяти, обфускация
Кстати https://ru.wikipedia.org/wiki/Java_Virtual_Machine
Виртуальные машины Java обычно содержат Интерпретатор байт-кода, однако, для повышения производительности во многих машинах также применяется JIT-компиляция часто исполняемых фрагментов байт-кода в машинный код.
В CLR весь код компилируется при первом обращении к классу.
Виртуальная машина (ВМ, от англ. virtual machine) — программная и/или аппаратная система, эмулирующая аппаратное обеспечение некоторой платформы (target — целевая, или гостевая платформа) и исполняющая программы для target-платформы на host-платформе (host — хост-платформа, платформа-хозяин) или виртуализирующая некоторую платформу и создающая на ней среды, изолирующие друг от друга программы и даже операционные системы (см.: песочница); также спецификация некоторой вычислительной среды (например: «виртуальная машина языка программирования Си»).
CLR ничего не эмулирует, она компилирует байт код в машинный код. Но при этом обеспечивает работу с памятью, сборку мусора, дефрагментация памяти Это среда выполнения.
Кроме того даже при компиляции NGEN если не используется рефлексия к незагруженным классам, динамическая компиляция, то она не подходит под определение VM.
При этом есть много общего с JVM.
Но даже если и согласиться с огромной натяжкой, что CLR это VM. То .Net VM не является. Ибо .Net Native уже не притянуть под поняти VM.
При этом в Вики нет никакого определения .Net Native. И я так понимаю, что в Java нет аналога .Net Native
При этом используются все те же библиотеки на MSIL и компилируются под определенную платформу.
Во время преобразования приложения из промежуточного языка в машинный код цепочка инструментов .NET Native выполняет следующие операции:
Для некоторых ветвей кода заменяется код, основанный на отражении и метаданных, на статический машинный код. Например, если тип значения не переопределяет метод ValueType.Equals, то стандартный тест на эквивалентность использует отражение для получения объектов FieldInfo, представляющих поля этого типа значения, а затем сравнивает значения полей двух экземпляров. При компиляции в машинный код цепочка инструментов .NET Native заменяет код отражения и метаданные на статическое сравнение значений полей.
Везде, где возможно, делается попытка исключить все метаданные.
.NET Native включает в заключительные сборки приложения только тот код реализации, который фактически вызывается приложением. Особенно это касается кода сторонних библиотек и кода в библиотеке классов .NET Framework. В результате приложение больше не зависит от сторонних библиотек или всей библиотеки классов .NET Framework; вместо этого код сторонних библиотек и библиотек классов .NET Framework теперь является локальным для приложения. .NET Native заменяет полную среду CLR на оптимизированную среды выполнения, которая в первую очередь содержит сборщика мусора. Оптимизированная среда выполнения находится в библиотеке mrt100_app.dll, которая является локальной для приложения и имеет размер только несколько сотен килобайт. Это возможно потому, что статическое связывание устраняет необходимость во многих операциях, реализуемых средой CLR.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vsb, Вы писали: vsb>Мне понятней не стало. Какая разница, какие там размеры указателей, это же деталь реализации. Какая разница, какой объём доступной памяти, это вообще от конкретной машины зависит, а не только от битности. В Java нет ничего этого, например. Какого размера указатели — знает только виртуальная машина. Сколько доступной памяти — вообще никто не знает, пока не попробуешь её выделить.
Ну раз нормальный вопрос — можно и ответить
1. Как упоминали выше по топику, этот волшебный переключатель влияет только на разрядность процесса, в котором будет запущен рантайм (чур не придираться к словам, сам знаю, что криво сформулировал)
2. При этом сам il-код не меняется и никто не запрещает поправить это флаг пересборкой exe-шника или ч/з corflags.exe.
3. Наконец, выставлять этот флаг для сборок-библиотек крайне не рекомендуется, т.к. оно приводит к крайне своеобразным квестам типа такого.
4. Собственно зачем: изначально этот флаг задумывался исключительно для утилит, которые тесно завязаны на unmanaged-код _и_ заточены либо под x86, или под x64. Особенно полезно, если interop-сборка под другую платформу отсутствует в принципе, т.е. использовать софт не под целевой платформой смысла ноль.
Но где-то к четвёртому дотнету внезапно вспомнили про "перфоманс это тоже важно". Надо сказать что версия jit-а под x64 в те времена не отличалась умом и сообразительностью, да и несколько бОльшее потребление памяти тоже делало своё чёрное дело... В общем "надо что-то делать" и это надо что-то делать делалось менеджерским способом: в VS 2010 x86 сделали платформой по умолчанию для exe-шников. Чтоб не скучали, в сконвертированных проектах в platform при этом иногда значилось AnyCPU (пруф). Больше всего радости это доставляло всяким числомолотилкам, т.к. иногда рантайм таки имеет значение
. Суровые мужики стали добавлять тест на "сколько бит у нас в указателе? А если проверю?".
Движуха продолжилась в VS 2012. Следуя заветам Форда, AnyCPU теперь значило любой CPU из x86, конец списка. Ну и чтоб не нарушать традицию, и VS 2015 и VS 2013 иногда делают
вот так
Inspecting the project’s properties shows the following (in the current Visual Studio UI “Prefer 32-bit” is grayed out and unchecked, where in actuality it is enabled…):
Здравствуйте, AlexRK, Вы писали:
ARK>.NET — это VM для выполнения MSIL.
Пост сдал — пост принял что ли?
Баян же, причём древнейший. Из серии "как мне запустить приложение без установки фреймворка?".
Если нужен ответ для маркетологов — тынц.
Ответ с скучной матчастью — тынц два.
Ответ из серии "в реальности всё совсем не так как на самом деле" — тынц три (см. раздел Auto NGEN).
ARK>Хуже того, .NET Native не сможет даже корректно скомпилировать любой MSIL, который может сожрать CLR.
Эммм, а можно пример? А то тут два варианта: или просто не в теме, или сова на глобусе. Судя по ".Net Native ни под какой vm не выполняется" — речь про первое, но всякое бывает
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, LaptevVV, Вы писали:
LVV>>Только в результате трансляции с студии мы все равно имеем исполняемый файл, который загружается загрузчиком оси, и начинает работать.
K>Неужели это единственное решение, которое пришло вам в голову? А как же *.class файлы в джабе? Им ВНЕЗАПНО не надо быть ни исполняемым кодом, ни даже быть в PE-формате. Чудеса, да?
А ты из жабы сможешь вызвать LoadLibrary() -> GetProcAddress()->...?
Сколько приседаний тебе нужно будет сделать, чтобы подружить твой жабовский код с уже имеющимися нативными либами? Сколько приседаний тебе нужно будет сделать, чтобы работа с каким-нибудь Verctor3[][] была с приемлемой скоростью, и сможешь ли...?
Ты главное пойми: любое решение — набор компромиссов, тогда перестанешь к мелочам придираться.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Sinix, Вы писали:
S>Если нужен ответ для маркетологов — тынц.
Вроде как совпадает с тем, что я говорю.
S>Ответ с скучной матчастью — тынц два.
Это тут уже было. И оно как бы ни о чем.
S>Ответ из серии "в реальности всё совсем не так как на самом деле" — тынц три (см. раздел Auto NGEN).
Это лень читать.
ARK>>Хуже того, .NET Native не сможет даже корректно скомпилировать любой MSIL, который может сожрать CLR. S>Эммм, а можно пример? А то тут два варианта: или просто не в теме, или сова на глобусе. Судя по ".Net Native ни под какой vm не выполняется" — речь про первое, но всякое бывает
Я не проверял, но читал, что рефлексию оно не переваривает, в частности, по приватным полям. Ога?
Здравствуйте, Kolesiki, Вы писали:
K>1. Я пишу прогу, компиляю её в совершенно абстрактный байткод. Никаких битов, выравниваний и прочей чуши. Где будет запущено ПО — не знаю, может даже на arduino! K>2. VM, созданная специально для этой ОС, знает об окружении всё: битность, объём памяти, оборудование, способы линковки и т.п. И ей командуют "запусти этот шмот байткода". K>3. VM транслирует байткод в нативные команды ЦПУ, попутно подгружая зависимые модули и транслируя их тоже (если надо). На выходе — готовый дамп процесса. Кто и как там вызывает 64-битный код из 5683-битного — БАЙТКОДУ ПОФИГ, за него может и должна это делать виртуальная машина, ибо ей известно об ОС всё.
K>Итак, повторяю вопрос: причём тут биты в байткоде?
32 бита позволяют создавать объекты в памяти не более 2 гигов.
Часто нужно больше. Тогда надо принудительно указывать это.
Программа же не может, какая бы она не была продвинутая, на лету менять свою битность. Типа, когда объект подбирается в 2 гигам, программа выгружается из памяти, перекомпилируется под 64 бита и прыгает обратно, так что ли ты хочешь?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Не пофиг например если идёт взаимодействие с native библиотеками
Ну так узнавай в своём управляемом коде, под какой процовой архитектурой и осью запущен, и подсасывай нужную native библиотеку. Я так делал на жаве, и jar-ка содержала актуальные на тот момент win32-x86, lin-x86, lin-amd64, osx-amd64, osx-ppc32 бинарнички-прокладки к нужным API оси. Но конечно да, сделать рабочее приложение- это немного отличается от переливания из пустого в порожнее про "портируемый .NET код на единственной платформе".
Здравствуйте, Mr Bombastic, Вы писали:
MB>Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>Не пофиг например если идёт взаимодействие с native библиотеками MB>Ну так узнавай в своём управляемом коде, под какой процовой архитектурой и осью запущен, и подсасывай нужную native библиотеку.
Увы, нужная библиотека бывает только одной битности, и это ограничивает тебя в выборе.
MB>Но конечно да, сделать рабочее приложение- это немного отличается от переливания из пустого в порожнее про "портируемый .NET код на единственной платформе".
Для любой платформы и среды существует соответствующая болтология, и соответствующие "болтологи". Кое-кто даже предлагал на ассемблере web-приложения писать (типа большего и не надо, а если нужна другая платформа, то х86 очень просто эмулировать).
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, vl690001x, Вы писали:
V>32 бита позволяют создавать объекты в памяти не более 2 гигов. V>Часто нужно больше. Тогда надо принудительно указывать это.
Ни разу не было нужно. Более того, мне ни разу не было нужно более 2 гигов памяти.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Слава, Вы писали:
С>Здравствуйте, Lexey, Вы писали:
L>>Бг.... Попробуй JNI попользовать в столь любимой тобой яве. Неожиданно окажется, что не только под виндами нативные dll'ки могут иметь разную битность.
С>Большая часть java-программистов в жизни ни разу JNI не коснулись.
Б0льшая часть людей вообще не умеет программки писать, при этом 1/5 из них не умеет даже читать.
С>И слава богу, pure-java решения как правило лучше себя ведут.
Во-первых, это требует доказательств, а во-вторых это отдельный разговор.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Kolesiki, Вы писали:
K>Тогда зачем вообще связываться с байткодом, если ты заранее ограничиваешь бинарь той системой, под которую заточил??
Затем, чтобы твой бинарь бесшовно сливался с другими бинарями, которые уже ANYCPU.
K>Во-вторых, насколько я помню, Жаба и есть тот самый байткод, где никогда не упоминалась ни битность, ни какие-либо другие специфики.
Надо бы проверить: само существование JNI вызывает серьёзные сомнения в этом утверждении.
K>К слову, уже сейчас Java опережает дотнетину в некоторых тестах (я не все проверял). Заметьте — и это всё без единой заточки байткода под битность!
0) Ты не проверял, я — тоже. Что-то я сомневаюсь.
1)Очевидно, что в этот набор не входят тесты, для которых нужна массовая работа со всяческими System.Numerics.Complex/Point/Vector2/Vector3. По понятным причинам.
2) Так же в этот набор наверняка не входят тесты, где используется взаимодействие с нативным кодом. По понятным причинам.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Kolesiki, Вы писали:
K>Я и спрашиваю, а какой тогда вообще смысл в VM???
Я бы не стал называть это VM, и тебе бы не советовал: в данном случае это маркетинговый термин. CLR — это фрэймворк, и под него можно писать "unsafe" код (притом как родной unsafe, так и Mixed Assemblies), т.е. используюя бенефиты и того и другого.
K>Если мы сильно терям в скорости...
доказательства в студию!
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, AlexRK, Вы писали:
S>>Ответ с скучной матчастью — тынц два. ARK>Это тут уже было. И оно как бы ни о чем.
Блин, вас топикстартер покусал что ли?
По ссылкам всё написано: термин "VM" тут не совсем подходит, т.к. стоит сделать шаг в сторону ngen-ом или .net native и внезапно VM в традиционном понимании куда-то пропадает и получается натягивание совы в стиле "браузеры — это VM!!!".
ARK>Я не проверял, но читал, что рефлексию оно не переваривает, в частности, по приватным полям. Ога?
Как обычно, в перепеве Рабиновича.
Private reflection over types and members in the .NET Framework class library is not supported. You can, however, reflect over your own private types and members, as well as types and members in third-party libraries.
Это не принципиальное ограничение, наследие предыдущих вариантов натив-тулчайна. Ну и к IL оно никакого отношения не имеет, просто сэкономили на трансляторе.
С практической точчи зрения тут разницы никакой. Товарища, который выпустит код с подобной закладкой в продакшн надо переводить в внедренцы. Там как раз больше работы == больше денег.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, vl690001x, Вы писали:
V>>32 бита позволяют создавать объекты в памяти не более 2 гигов. V>>Часто нужно больше. Тогда надо принудительно указывать это.
Ф>Ни разу не было нужно. Более того, мне ни разу не было нужно более 2 гигов памяти.
Зависит от специфики выполняемых задач, очевидно. 64 бита не просто так придумали.
Здравствуйте, Sinix, Вы писали:
S>По ссылкам всё написано: термин "VM" тут не совсем подходит, т.к. стоит сделать шаг в сторону ngen-ом или .net native и внезапно VM в традиционном понимании куда-то пропадает и получается натягивание совы в стиле "браузеры — это VM!!!".
В общем, это пляски вокруг терминологии. Четкого формального определения, что такое VM, я не видел. Если предоставите — буду раз прочесть.
Согласно моему пониманию и определению в википедии, CLR вполне является VM. Как я понял, весь спор начался вокруг того, что в .NET входит как CLR, так и появившийся совсем недавно .NET Native, и, дескать, топикстартер выразился некорректно. Но что, разве непонятно, о чем говорил топикстартер, употребив выражение ".NET VM"? Непонятно, что он говорит о CLR, а .NET Native тут вообще ни при чем? Стоило разводить эту бодягу о терминологии?
ARK>>Я не проверял, но читал, что рефлексию оно не переваривает, в частности, по приватным полям. Ога? S>Как обычно, в перепеве Рабиновича. S>
S>Private reflection over types and members in the .NET Framework class library is not supported. You can, however, reflect over your own private types and members, as well as types and members in third-party libraries.
S>Это не принципиальное ограничение, наследие предыдущих вариантов натив-тулчайна. Ну и к IL оно никакого отношения не имеет, просто сэкономили на трансляторе. S>С практической точчи зрения тут разницы никакой. Товарища, который выпустит код с подобной закладкой в продакшн надо переводить в внедренцы. Там как раз больше работы == больше денег.
Тем не менее, _по факту_ разница есть. А с подходом "написать можно все", "да это за 10 минут студент на коленке может сделать" — с этим не ко мне.
S>Самое забавное, что у .Native есть куда более занятные нюансы, но обсуждаем почему-то именно этот.
Еще одно подтверждение, что различий немало. И я уверен, что различия между обычным нетом и нативом будут всегда.
Если же вы хотите перевести разговор в плоскость "различия есть, но не принципиальные, и 95% юзеров о них даже не узнают", так с этим никто и не спорил.
Здравствуйте, AlexRK, Вы писали:
ARK>В общем, это пляски вокруг терминологии. Четкого формального определения, что такое VM, я не видел. Если предоставите — буду раз прочесть.
+1. Проблема в том, что терминология тут цельнотянута от явы, там она хоть какой-то смысл имела. С дотнетом сложнее. Если совсем грубо, то дотнет состоит из штуки, которая генерит нативный код из IL (она может отработать при запуске, при деплое или прям при сборке — не суть важно), рантайм-библиотек и сборщика мусора. Что из этого можно обозвать VM?
ARK>Тем не менее, _по факту_ разница есть. А с подходом "написать можно все", "да это за 10 минут студент на коленке может сделать" — с этим не ко мне.
На практике особой разницы нет. В смысле софт (библиотеки) отличнейше собираются под .net native и работают с первого раза. Вот с самим переводом на .Core проблем хватает, но тут никто совместимости задаром и не обещал
Здравствуйте, Kolesiki, Вы писали:
K>Про MMX могу ошибаться, но суть вы поняли — джитнутый код очень далёк от кода, который МОГ БЫ оптимально исполняться на текущем CPU.
Суть мы и так знаем. JIT это всегда компромисс между скоростью запуска и качеством кодогенерации. Иначе будешь сутками собирать, как С++.
)
