Здравствуйте, Kolesiki, Вы писали:
K>Опять отсылаю к значению слова "виртуальный" в понятии VM.
Простите, а причем вообще VM? Вы же тему про .NET вроде начинали, не?
LVV>>Только в результате трансляции с студии мы все равно имеем исполняемый файл, который загружается загрузчиком оси, и начинает работать. K>Неужели это единственное решение, которое пришло вам в голову? А как же *.class файлы в джабе? Им ВНЕЗАПНО не надо быть ни исполняемым кодом, ни даже быть в PE-формате. Чудеса, да?
Мы не про Яву разговариваем.
В Яве интерпретатор можно вызвать отдельно из командной строки, отдав ему скомпилированные классы.
В нет такое возможно?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
K>Но я в упор не понимаю, как можно извратить обычную идею портабельного байткода до маразма, который мы сейчас наблюдаем в VisualStudio/.NET: K>Image: 7sdOBF8.png K>"Что это за биты? Что это за "prefer"? Нам таких не надо, диско-суперстар!" (ц)
Это ложноножки, которые отрастил сферический конь, чтобы хоть както выжить в этом угловатом мире
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Kolesiki, Вы писали:
K>Тогда зачем вообще связываться с байткодом, если ты заранее ограничиваешь бинарь той системой, под которую заточил??
По твоему скрину похоже, что ограничивать не обязательно, хотя можно, если так хочется разработчику.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, samius, Вы писали:
K>>Опять отсылаю к значению слова "виртуальный" в понятии VM. S>Простите, а причем вообще VM? Вы же тему про .NET вроде начинали, не?
А .NET это что, не VM?
А так-то топикстартер прав. Просто очередной кривой костыль.
Здравствуйте, LaptevVV, Вы писали:
LVV>>>Только в результате трансляции с студии мы все равно имеем исполняемый файл, который загружается загрузчиком оси, и начинает работать. K>>Неужели это единственное решение, которое пришло вам в голову? А как же *.class файлы в джабе? Им ВНЕЗАПНО не надо быть ни исполняемым кодом, ни даже быть в PE-формате. Чудеса, да? LVV>Мы не про Яву разговариваем. LVV>В Яве интерпретатор можно вызвать отдельно из командной строки, отдав ему скомпилированные классы. LVV>В нет такое возможно?
В .Net все компилируется. Но можно использовать рефлексию
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, samius, Вы писали:
K>>>Опять отсылаю к значению слова "виртуальный" в понятии VM. S>>Простите, а причем вообще VM? Вы же тему про .NET вроде начинали, не?
ARK>А .NET это что, не VM?
ARK>А так-то топикстартер прав. Просто очередной кривой костыль.
Здравствуйте, Serginio1, Вы писали:
ARK>>А так-то топикстартер прав. Просто очередной кривой костыль. S> Ну если ты им не пользуешься то конечно костыль.
Костыль не перестает быть костылем, даже если им кто-то (или все) пользуется.
Собственно, костылей, которыми никто не пользуется, и не существует.
S>На счет VM Is the CLR a virtual machine?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
K>>То, что MS всегда найдёт самую тухлейшую отмазу "почему здесь торчит изолента" — это я знаю, мне нужен инженерный ответ: "ЗАЧЕМ БАЙТКОДУ БИТНОСТЬ?".
EP>Предположу что это битность не байткода, а предпочитаемой цели. На x32/x64 разный объём доступной памяти, и разные размеры указателей (что влияет на потребление и в следствии скорость).
Мне понятней не стало. Какая разница, какие там размеры указателей, это же деталь реализации. Какая разница, какой объём доступной памяти, это вообще от конкретной машины зависит, а не только от битности. В Java нет ничего этого, например. Какого размера указатели — знает только виртуальная машина. Сколько доступной памяти — вообще никто не знает, пока не попробуешь её выделить.
> Плюс в x64 процесс нельзя загрузить x32 dll, которая может быть сторонней.
Опять же какое дело байткоду до всего этого? Запустишь 32-битной запускалкой — будет работать 32-битное приложение. Запустишь 64-битной запускалкой — будет работать 64-битное приложение.
Здравствуйте, fddima, Вы писали:
F>PS: Проблема незаметная, но это до тех пор, пока third-party нативная библиотека не пытается получить базовый путь к программе, а получает какой-нибудь /usr/bin.
В Java можно делать свои лаунчеры, которые загружают JVM как DLL и запускают программу. Некоторые крупные проекты вроде Eclipse так и делают. Но в целом очень мало кто так делает и проблем больших от этого не испытывают.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, Serginio1, Вы писали:
ARK>>>А так-то топикстартер прав. Просто очередной кривой костыль. S>> Ну если ты им не пользуешься то конечно костыль.
ARK>Костыль не перестает быть костылем, даже если им кто-то (или все) пользуется. ARK>Собственно, костылей, которыми никто не пользуется, и не существует.
S>>На счет VM Is the CLR a virtual machine?
ARK>А что нового я там должен увидеть?
ARK>Могу тоже ссылку дать, https://en.wikipedia.org/wiki/Common_Language_Runtime: ARK>
The Common Language Runtime (CLR), the virtual machine component of Microsoft's .NET framework, manages the execution of .NET programs.
Ээээ.. чего?
S>>> Кроме того есть .Net Native ARK>>Ну есть и есть. Интерпретаторы С++ тоже есть. S> Которые выполняются со скоростью машинного кода? Ты бы хоть ссылки то почитал. S>
S>.NET Native использует то же сервер, что и компилятор C++, который оптимизирован для статических сценариев предварительной компиляции.
Во-первых, здесь не написано, что .NET Native выполняется со скоростью машинного кода.
Во-вторых, .NET Native в принципе не может достичь скорости неуправляемых языков просто хотя бы по причине наличия рефлексии.
В-третьих, .NET Native — не эквивалентен .NET.
И наконец — вообще неважно, с какой скоростью все исполняется, и скорость не имеет никакого отношения к определению того, является язык нативным или нет. Есть медленные нативные языки, есть быстрые виртуальные машины.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, Serginio1, Вы писали:
S>> Что ты понимаеншь под VM?
ARK>https://en.wikipedia.org/wiki/Virtual_machine
S>>CLR Это хост для компиляции IL кода
ARK>Википедия с вами не согласна.
Ну в википедии много чего есть, что не соответствует истины. S>>Компилятор это VM
ARK>Ээээ.. чего?
Вот именно. По твоему JIT компилятор это VM
Ты хоть читай ссылки которые тебе дают.
Приложения предназначенные для платформы .NET Framework, создаются на определенном языке программирования и компилируются в промежуточный язык (IL). Перед выполнением какого-либо метода в первый раз JIT-компилятор компилирует IL-код в машинный код для локального компьютера. В противоположность этому цепочка инструментов .NET Native преобразует исходный код в машинный код во время компиляци
S>>>> Кроме того есть .Net Native ARK>>>Ну есть и есть. Интерпретаторы С++ тоже есть. S>> Которые выполняются со скоростью машинного кода? Ты бы хоть ссылки то почитал. S>>
S>>.NET Native использует то же сервер, что и компилятор C++, который оптимизирован для статических сценариев предварительной компиляции.
ARK>Во-первых, здесь не написано, что .NET Native выполняется со скоростью машинного кода. ARK>Во-вторых, .NET Native в принципе не может достичь скорости неуправляемых языков просто хотя бы по причине наличия рефлексии. ARK>В-третьих, .NET Native — не эквивалентен .NET.
Ну да, а что это?
Еще раз читаем ссылки, что бы не позориться
.NET Native включает в заключительные сборки приложения только тот код реализации, который фактически вызывается приложением. Особенно это касается кода сторонних библиотек и кода в библиотеке классов .NET Framework. В результате приложение больше не зависит от сторонних библиотек или всей библиотеки классов .NET Framework; вместо этого код сторонних библиотек и библиотек классов .NET Framework теперь является локальным для приложения.
.NET Native заменяет полную среду CLR на оптимизированную среды выполнения, которая в первую очередь содержит сборщика мусора. Оптимизированная среда выполнения находится в библиотеке mrt100_app.dll, которая является локальной для приложения и имеет размер только несколько сотен килобайт. Это возможно потому, что статическое связывание устраняет необходимость во многих операциях, реализуемых средой CLR.
Генератор образов в машинном коде (NGEN) компилирует сборки в машинный код и устанавливает их в кэш образов в машинном коде на локальном компьютере. Однако хотя NGEN, как и .NET Native, создает машинный код, NGEN имеет существенные отличия от .NET Native:
Если для конкретного метода нет образа в машинном коде, NGEN переключается на JIT-компиляцию кода. Это означает, что образы в машинном коде должны продолжать включать метаданные и IL-код для того случая, если генератору NGEN необходимо переключиться на JIT-компиляцию. В противоположность этому .NET Native только создает образы в машинном коде и не переключается на JIT-компиляцию. В результате должны сохраняться метаданные, необходимые только для некоторых сценариев отражения, сериализации и взаимодействия.
NGEN по-прежнему полагается на полную среду CLR для таких сервисов, как загрузка сборок, удаленное и локальное взаимодействие, управление памятью, сбор мусора и, при необходимости, JIT-компиляция. В .NET Native многие из этих сервисов являются либо ненужными (JIT-компиляции), либо разрешаются во время построения и включаются в сборку приложения. Остальные сервисы, наиболее важным из которых является сбор мусора, включены в гораздо более компактную, оптимизированную среду выполнения mrt100_app.dll.
ARK>И наконец — вообще неважно, с какой скоростью все исполняется, и скорость не имеет никакого отношения к определению того, является язык нативным или нет. Есть медленные нативные языки, есть быстрые виртуальные машины.
Еще раз, что по твоему VM?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>>CLR Это хост для компиляции IL кода ARK>>Википедия с вами не согласна. S> Ну в википедии много чего есть, что не соответствует истины.
А где же взять истину, о гуру?
S>>>Компилятор это VM ARK>>Ээээ.. чего? S> Вот именно. По твоему JIT компилятор это VM
Не надо свои выдумки выдавать за мои слова.
S> Ты хоть читай ссылки которые тебе дают. S>
Приложения предназначенные для платформы .NET Framework, создаются на определенном языке программирования и компилируются в промежуточный язык (IL). Перед выполнением какого-либо метода в первый раз JIT-компилятор компилирует IL-код в машинный код для локального компьютера. В противоположность этому цепочка инструментов .NET Native преобразует исходный код в машинный код во время компиляци
Здесь для меня нет ничего нового.
ARK>>Во-первых, здесь не написано, что .NET Native выполняется со скоростью машинного кода. ARK>>Во-вторых, .NET Native в принципе не может достичь скорости неуправляемых языков просто хотя бы по причине наличия рефлексии. ARK>>В-третьих, .NET Native — не эквивалентен .NET. S> Ну да, а что это? S>Еще раз читаем ссылки, что бы не позориться
Вы лучше включите голову, чтобы не позориться. Может тогда увидите, что у вас по ссылкам нет опровержения ни одного из моих пунктов.
ARK>>И наконец — вообще неважно, с какой скоростью все исполняется, и скорость не имеет никакого отношения к определению того, является язык нативным или нет. Есть медленные нативные языки, есть быстрые виртуальные машины. S> Еще раз, что по твоему VM?
Набор сервисов, предназначенных для выполнения кода в специальном формате. Выполнение кода, сборка мусора, работа с памятью, исключения и прочее и прочее.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, Serginio1, Вы писали:
S>>>>CLR Это хост для компиляции IL кода ARK>>>Википедия с вами не согласна. S>> Ну в википедии много чего есть, что не соответствует истины.
ARK>А где же взять истину, о гуру?
На заборе вестимо. S>>>>Компилятор это VM ARK>>>Ээээ.. чего? S>> Вот именно. По твоему JIT компилятор это VM
ARK>Не надо свои выдумки выдавать за мои слова.
S>> Ты хоть читай ссылки которые тебе дают. S>>
Приложения предназначенные для платформы .NET Framework, создаются на определенном языке программирования и компилируются в промежуточный язык (IL). Перед выполнением какого-либо метода в первый раз JIT-компилятор компилирует IL-код в машинный код для локального компьютера. В противоположность этому цепочка инструментов .NET Native преобразует исходный код в машинный код во время компиляци
ARK>Здесь для меня нет ничего нового.
ARK>>>Во-первых, здесь не написано, что .NET Native выполняется со скоростью машинного кода. ARK>>>Во-вторых, .NET Native в принципе не может достичь скорости неуправляемых языков просто хотя бы по причине наличия рефлексии. ARK>>>В-третьих, .NET Native — не эквивалентен .NET. S>> Ну да, а что это? S>>Еще раз читаем ссылки, что бы не позориться
ARK>Вы лучше включите голову, чтобы не позориться. Может тогда увидите, что у вас по ссылкам нет опровержения ни одного из моих пунктов.
Ну как же ты сам признал, что VM это не компилятор.
На самом деле для выполнения MSIL его нужно скомпилировать
1. Динамически с помощью JIT компилятора их CLR
2. Статически .Net Native. При этом есть ограничение на рефлексию в MSIL коде. ARK>>>И наконец — вообще неважно, с какой скоростью все исполняется, и скорость не имеет никакого отношения к определению того, является язык нативным или нет. Есть медленные нативные языки, есть быстрые виртуальные машины. S>> Еще раз, что по твоему VM?
ARK>Набор сервисов, предназначенных для выполнения кода в специальном формате. Выполнение кода, сборка мусора, работа с памятью, исключения и прочее и прочее.
То есть это определение подходит и .Net Native.
NGEN по-прежнему полагается на полную среду CLR для таких сервисов, как загрузка сборок, удаленное и локальное взаимодействие, управление памятью, сбор мусора и, при необходимости, JIT-компиляция. В .NET Native многие из этих сервисов являются либо ненужными (JIT-компиляции), либо разрешаются во время построения и включаются в сборку приложения. Остальные сервисы, наиболее важным из которых является сбор мусора, включены в гораздо более компактную, оптимизированную среду выполнения mrt100_app.dll.
Значит компилятор это VM?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>> Ну в википедии много чего есть, что не соответствует истины. ARK>>А где же взять истину, о гуру? S> На заборе вестимо.
Смешно, смешно.
S> Ну как же ты сам признал, что VM это не компилятор.
VM — это не компилятор, но вполне может включать в себя компилятор. А может и не включать.
S> На самом деле для выполнения MSIL его нужно скомпилировать S>1. Динамически с помощью JIT компилятора их CLR S>2. Статически .Net Native. При этом есть ограничение на рефлексию в MSIL коде.
И что дальше?
Джаву можно интерпретировать, можно JIT-ить, а можно компилировать (см. Excelsior).
JavaScript/LUA можно интерпретировать, можно JIT-ить.
C/C++/Pascal можно интерпретировать, можно компилировать.
Какое это все имеет отношение к виртуальной машине .NET?
ARK>>Набор сервисов, предназначенных для выполнения кода в специальном формате. Выполнение кода, сборка мусора, работа с памятью, исключения и прочее и прочее. S> То есть это определение подходит и .Net Native.
К .Net Native может и подходит. Но .Net Native — это не .NET, а подмножество.
S>Значит компилятор это VM?
Нет, не значит.
У вас с логикой что-то не то. Есть некий код, который может быть либо а) выполнен с помощью виртуальной машины; либо б) скомпилирован в единый экзешник (есть еще вариант — сунуть в экзешник всю виртуальную машину, как это частично делает Excelsior). Вывод Serginio1: раз код можно выполнять на VM и компилировать, значит VM это компилятор.
Типа если человек может жрать траву, и корова может жрать траву, значит человек это корова.
S>> На самом деле для выполнения MSIL его нужно скомпилировать
S>>1. Динамически с помощью JIT компилятора их CLR
S>>2. Статически .Net Native. При этом есть ограничение на рефлексию в MSIL коде.
ARK>>>Набор сервисов, предназначенных для выполнения кода в специальном формате. Выполнение кода, сборка мусора, работа с памятью, исключения и прочее и прочее. S>> То есть это определение подходит и .Net Native.
ARK>К .Net Native может и подходит. Но .Net Native — это не .NET, а подмножество.
Читаем выделенное. Net это MSIL. И он может по разному выполняться. S>>Значит компилятор это VM?
ARK>Нет, не значит.
Ну раз к >> .Net Native может и подходит
ARK>У вас с логикой что-то не то. Есть некий код, который может быть либо а) выполнен с помощью виртуальной машины; либо б) скомпилирован в единый экзешник (есть еще вариант — сунуть в экзешник всю виртуальную машину, как это частично делает Excelsior). Вывод Serginio1: раз код можно выполнять на VM и компилировать, значит VM это компилятор.
Под какой VM выполняется .Net Native ARK>Типа если человек может жрать траву, и корова может жрать траву, значит человек это корова.
Угу по твоей логике и ОС это вируальная машна.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, Serginio1, Вы писали:
S>>>> Ну в википедии много чего есть, что не соответствует истины. ARK>>>А где же взять истину, о гуру? S>> На заборе вестимо.
ARK>Смешно, смешно.
Архитектура .NET[править | править вики-текст]
Программа для .NET Framework, написанная на любом поддерживаемом языке программирования, сначала переводится компилятором в единый для .NET промежуточный байт-код Common Intermediate Language (CIL) (ранее назывался Microsoft Intermediate Language, MSIL). В терминах .NET получается сборка, англ. assembly.
[q]
Затем код либо исполняется виртуальной машиной Common Language Runtime (CLR), либо транслируется утилитой NGen.exe в исполняемый код для конкретного целевого процессора.
Использование виртуальной машины предпочтительно, так как избавляет разработчиков от необходимости заботиться об особенностях аппаратной части. В случае использования виртуальной машины CLR встроенный в неё JIT-компилятор «на лету» (just in time) преобразует промежуточный байт-код в машинные коды нужного процессора. Современная технология динамической компиляции позволяет достигнуть высокого уровня быстродействия. Виртуальная машина CLR также сама заботится о базовой безопасности, управлении памятью и системе исключений, избавляя разработчика от части работы.
[/q]
То есть даже NGEN это не виртуальная машина, хотя на самом деле как я уже давал ссылки
NGEN по-прежнему полагается на полную среду CLR для таких сервисов, как загрузка сборок, удаленное и локальное взаимодействие, управление памятью, сбор мусора и, при необходимости, JIT-компиляция. В .NET Native многие из этих сервисов являются либо ненужными (JIT-компиляции), либо разрешаются во время построения и включаются в сборку приложения. Остальные сервисы, наиболее важным из которых является сбор мусора, включены в гораздо более компактную, оптимизированную среду выполнения mrt100_app.dll.
Так, что верь Вики. Она тебя же и опровергает.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Читаем выделенное. Net это MSIL. И он может по разному выполняться.
.NET — это VM для выполнения MSIL.
S>>>Значит компилятор это VM? ARK>>Нет, не значит. S> Ну раз к >> .Net Native может и подходит
.NET и .NET Native — разные вещи, это так сложно понять? Хуже того, .NET Native не сможет даже корректно скомпилировать любой MSIL, который может сожрать CLR.
S> Под какой VM выполняется .Net Native
Ни под какой. Спрашиваю еще раз: какое отношение .NET Native имеет к виртуальной машине .NET, кроме возможности компилировать урезанный вариант MSIL?
ARK>>Типа если человек может жрать траву, и корова может жрать траву, значит человек это корова. S> Угу по твоей логике и ОС это вируальная машна.
Безусловно, ОС и VM имеют много общего. И в частных случаях одно может быть другим.
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 это не виртуальная машина, хотя на самом деле как я уже давал ссылки
Ничего не понял. Есть такая поговорка — кто ясно мыслит, тот ясно излагает.
Вас словосочетание "Виртуальная машина CLR" в процитированном вами же тексте ни на что не наталкивает?
S>
S>NGEN по-прежнему полагается на полную среду CLR для таких сервисов, как загрузка сборок, удаленное и локальное взаимодействие, управление памятью, сбор мусора и, при необходимости, JIT-компиляция. В .NET Native многие из этих сервисов являются либо ненужными (JIT-компиляции), либо разрешаются во время построения и включаются в сборку приложения. Остальные сервисы, наиболее важным из которых является сбор мусора, включены в гораздо более компактную, оптимизированную среду выполнения mrt100_app.dll.
S> Так, что верь Вики. Она тебя же и опровергает.
Где и в чем она меня опровергает?
Еще раз повторяю свою мысль: .NET — это виртуальная машина для выполнения IL, плюс библиотека классов. Что тут неясно? Тот факт, что есть отдельная вещь под названием .NET Native, ничего не доказывает и не опровергает. Любой язык можно компилировать или выполнять в виртуальной машине.
