Нам все уши прожужжали преимуществами байткода перед "обычным кодом" (причём все эти преимущества элементарно нивелируются компиляцией под нужный CPU).
Но я в упор не понимаю, как можно извратить обычную идею портабельного байткода до маразма, который мы сейчас наблюдаем в VisualStudio/.NET:
"Что это за биты? Что это за "prefer"? Нам таких не надо, диско-суперстар!" (ц)
То, что MS всегда найдёт самую тухлейшую отмазу "почему здесь торчит изолента" — это я знаю, мне нужен инженерный ответ: "ЗАЧЕМ БАЙТКОДУ БИТНОСТЬ?".
Разве не за универсальность боролись "отцы Жабы", чтобы навсегда забыть о битах, процессорах и прочей чуши, которая не имеет никакого отношения к кодингу?
И что самое обидное, полностью извратив идею байткода, мелкомягкие клоуны опять куда-то бегут через всю индустрию с флагом "теперь всё нативно!". Попутно похерив весь свой мобильный сегмент.
Итак, вопрос капсом выше.
PS
Это не холивар, это абсолютно технический вопрос для выявления костылей .NET платформы.
Здравствуйте, alexzzzz, Вы писали:
A> Если на 64-разрядной ОС твоя программа будет автоматически запускаться как 64-разрядный процесс, как и куда она будет подгружать эту 32-разрядную библиотеку?
Топик уже истоптал всю поляну вокруг главной идеи, некоторые её даже косвенно озвучили, но пора бы уже настоящим инженерам догадаться. Выскажусь тезисно:
1. Чисто теоретически, идеальная система (какую и ДОЛЖНЫ были проектировать гиганты вроде MS) может спокойно обходиться БЕЗ БИТНОСТИ. Java тому прекрасный пример.
2. Все намёки на "загрузку 13-битных DLL в 47-битной системе" отношу к непрофессиональным — все почему-то решили, что если МИКРОСОФТ СВАЛИЛА СВОИ ПРОБЛЕМЫ НА ВАС, то так и должно быть! НЕ ДОЛЖНО. Нет вообще никакого смысла заново "изобретать VM" (после Java), если мы опять скатываемся в гуано, которое накосячила MS! Это ЕЁ ПРЯМАЯ ЗАДАЧА — обеспечивать загрузку "разнобитных DLL".
Итого, как MS должны были сделать, но не сделали ввиду узколобости руководства и посредственной квалификации разрабов:
1. Новый формат исполняемых IL-файлов. Скажем, *.mod(ule). Он НИЧЕГО не меняет в экосистеме венды, зато даёт однозначность при работе с ними. Заодно, сплавив legacy-поля и введя современные. Сейчас мы имеем БАРДАК из *.exe, *.dll, *.ocx и прочего фуфла, где невозможно сказать, что это за модуль — 16-битный DOS, 64-битный вантуз или вообще MSIL! СПАСИБО тебе, микрософт, что добавляешь геморой на пустом месте, зато с "единым запускатором" в виде PE-файла!
2. Прозрачная загрузка любых DLL. Ни бог весть какая задача, особенно на x64 системах, особенно для квалифицированного windows-системщика. То, что венда — это мельница из костылей и изоленты — это ВАША(MS) ВИНА. Задача адекватного инженера — сделать так, чтобы вообще про битность можно было забыть! Не от большого ума была придумана компиляция в x64 режим, потому что в одном приложении запросто могут быть СРАЗУ НЕСКОЛЬКО БИТНОСТЕЙ(!). Во что компилять MSIL, если он использует сторонние DLL из 13 и 25 битов? В полусумму? Вот то-то же!
Ну и пункт, с которым вообще нет смысла спорить:
3. .NET с самого первого байта ОБЯЗАН был быть портируемым. Это просто сама суть VM — обеспечивать переносимый, бинарный код. Жалкие оправдания, почему это НЕ было сделано просто смехотворны и главное, лишь подтверждают убогую квалификацию тогдашних программистов, ибо сейчас они ВСЁ РАВНО К ЭТОМУ ПРИШЛИ — к переносимому .NET Core! Нужны ли ещё доказательства того, что .NET — красивая идея с безобразной реализацией?! (впрочем, как и всегда у MS)
K>Но я в упор не понимаю, как можно извратить обычную идею портабельного байткода до маразма, который мы сейчас наблюдаем в VisualStudio/.NET: K>Image: 7sdOBF8.png K>"Что это за биты? Что это за "prefer"? Нам таких не надо, диско-суперстар!" (ц)
Это ложноножки, которые отрастил сферический конь, чтобы хоть както выжить в этом угловатом мире
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ·, Вы писали:
A>>Ключи существуют, чтобы решать конкретную проблему, которая Яве естественно тоже есть, но решает её там конечный пользователь самостоятельно. A>>http://stackoverflow.com/questions/9757456/java-native-interface-32-bit-dll-on-64-bit-system ·>Ну понятно, раз нет нативных бинарников под данную платформу — их надо либо поставить, либо запустить под 32 бита. Зачем это делать программисту во время билда CIL-сборок?
Это программисту понятно, что у него есть, а что у него нет. Пользователю это непонятно. У пользователя всё просто должно работать. Если не работает, это проблема не пользователя, а программиста.
Стоит у пользователя 64-разрядная Ява, он программу запускает, а она не запускается. Ему что, обязательно знать, что проблема из-за того, что Явы, оказывается, бывают разные? Ну допустим так, но 64 ведь лучше, чем 32. Должно же работать. Или нужно 86-разрядную? Да он даже не знает, что такое Ява. Остров вроде, а может мотоцикл.
При таком отношении к пользователю не удивительно, что Ява на десктопах начинается и заканчивается на Майнкрафте.
A>>Ну вот нет у тебя нативной библиотеки подо все платформы. Автор библиотеки скомпилировал её в 1995 году только под x86, а про x64 и x128 не догадался. Исходники стёр, сам застрелился, бекапы сгорели. ·>Ну запусти под 32 битной vm. Делов-то. А если таки есть?
А я знаю, есть или нет? Я пользователь. Ты ж программист, давай, я тебе в субботу позвоню, а ты мне по телефону всё починишь? В понедельник утром уже сдавать отчёт, а ничего не работает. Что конкретно не работает? Ничего не работает.
·> Что делать с x86 CIL-сборкой, если автор застрелился?
Забавный факт: программисты на C++ умирают чаще, чем программисты на C#.
Конечному пользователю вообще-то пофиг. X86 у него и так запустится. Если ты программист, и попалась управляемая библиотека x86-only, то варианта два:
1. Либо она под x64 в принципе неработоспособна, потому что, например, в свою очередь зависит от x86-only нативной библиотеки. Тогда делаешь свою программу тоже x86-only, другого варианта всё равно нет.
2. Либо ограничение, не знаю как, вдруг возникло по ошибке. Если ты в этом уверен, убираешь ограничивающий флажок ручками взад и пользуешься.
A>>Зачем такой геморрой? Достаточно в своей программе выставить флажок на запуск её в 32-разрядном виде всегда, независимо от разрядности ОС. ·>Не надо такой гемморой. Ведь на ОС запускается не сама программа, а vm. Просто запусти эту же программу под 32-битной VM. Ведь байт-код для этого и придумывали, чтобы можно было менять VM, используя те же bytecode-бинарики.
Ты программист, ты заранее знаешь, что твой код не будет работать в 64-разрядном процессе. Не обманывай людей, поставь флажок x86-only и избавь пользователей от ненужного ни им, ни тебе геморроя, а то и по воскресеньям начнут звонить.
Здравствуйте, Kolesiki, Вы писали:
K>То, что MS всегда найдёт самую тухлейшую отмазу "почему здесь торчит изолента" — это я знаю, мне нужен инженерный ответ: "ЗАЧЕМ БАЙТКОДУ БИТНОСТЬ?".
Предположу что это битность не байткода, а предпочитаемой цели. На x32/x64 разный объём доступной памяти, и разные размеры указателей (что влияет на потребление и в следствии скорость). Плюс в x64 процесс нельзя загрузить x32 dll, которая может быть сторонней.
В принципе всё правильно, но сам импорт на mscoree.dll как и любой нативный стаб — по сути легаси механизм на всякий случай, а начиная с Windows XP+ загрузчик в ОС уже и сам осведомлен о native / .net executable. В противном случае, думается мне никакого бы AnyCPU не было бы.
Здравствуйте, AlexRK, Вы писали:
ARK>.NET — это VM для выполнения MSIL.
Пост сдал — пост принял что ли?
Баян же, причём древнейший. Из серии "как мне запустить приложение без установки фреймворка?".
Если нужен ответ для маркетологов — тынц.
Ответ с скучной матчастью — тынц два.
Ответ из серии "в реальности всё совсем не так как на самом деле" — тынц три (см. раздел Auto NGEN).
ARK>Хуже того, .NET Native не сможет даже корректно скомпилировать любой MSIL, который может сожрать CLR.
Эммм, а можно пример? А то тут два варианта: или просто не в теме, или сова на глобусе. Судя по ".Net Native ни под какой vm не выполняется" — речь про первое, но всякое бывает
Здравствуйте, Sharov, Вы писали:
S>Еще разок. Причина -- необходимая битность PE-header'а, следсвтие -- managed код под windows может зависть от битности, хотя не должен. Где я ошибся? S>Можно просто сказать, а не рожи крючитьфейспалмить.
Причина — необходимость загрузчику знать, какая среда исполнения нужна файлу, с тем, чтобы эту самую среду ему обеспечить перед запуском. Наличие флага — это следствие данной необходимости. Managed код под windows может зависить от битности только тогда, когда он использует компоненты, зависящие от битности. При этом сам managed код не становится каким-то особенным, отличающимся от "независящего", просто у него есть ограничения на то, в каком окружении он может работать.
Здравствуйте, Sharov, Вы писали:
S>Благодарю, так яснее. Хотя не согласен в том, что managed код совсем уж не отличается. Я точно не уверен, но думается мне, зная target битность компилятор может получше провести оптимизацию байт кода, нежели в случае AnyCpu. Но я ничего не утверждаю, просто логично было бы предположить...
Компилятору исходного языка в IL всё равно, на какой платформе будет исполняться код, это не его дело. А JIT-компилятору на флажок тоже плевать, потому что к моменту, когда он выходит на сцену, процесс нужной битности уже создан. Так что он без всяких флажков знает, на какой платформе он работает.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>·>Понятно, но это не связано с байткодом. EP>>>Это связано с тем во что транслируется байткод, собственно сабжевый флажок это и контролирует. EP>·>Так байткод может и не транслироваться, а тупо интерпретироваться. Асбтракция, и всё такое. EP>Я не пойму что ты хочешь сказать, и как это всё относится к теме.
Собственно напрямую. У майкрософта "здесь торчит изолента", не потому что байткод, а потому что в майкрософте фигню наиндусокодили с сабжем. В яве этого бреда нет и не надо. Битность таргет-платформы JVM вообще никак не относится к тому как компилится исходный код. Почему компилятору нужно знать во что транслируется байткод? Байткод при желании можно и в рантайме генерить, без всяких компиляторов.
Все эти оптимизации того что "x64 может легко увеличить потребление ресурсов на ровном месте" реализуются на уровне JVM (например упомянутый Compressed Oops), а не с помощью протекающих абстракций.
Наличие JNI и DLL-ек тоже не причина. System.loadLibrary просто выбирает подходящую нативную библиотеку под текущую платформу. Байткод-то тут причём?
Это "Такое что в x64 системе может работать x32 код. И что лучше для твоего конкретного приложения среда может и не знать" решается тупо тем под какой JVM запускаешь — x32 или x64 — можешь иметь обе одновременно.
EP>x86 код например тоже может интерпретироваться
Понятно, но x86 это не байткод виртуальной машины, а машинный код конкретного железа. Зачем микрософт запихнула детали имплементации платформы на уроветь компилятора исходников — один Бг знает.
EP>>>Ну да, я же говорю — без хаков. А с хаками да, можно — но там уже будет указатель не указатель, а некий синтезированный индекс, и соответствующие penalty и т.п. EP>·>Хаки эти никак на байткод не влияют EP>А где влияют? EP>Насколько я понял из темы — влияние сабжевых ключей на байткод это лишь неверное предположение — так зачем постоянно кивать в эту сторону?
Тут скорее всего проблема в том, что эти ключи вообще существуют.
EP>·>С т.з. байткода есть только OOP (ordinary object pointer) и ничего не меняется. Скажем например можно включить Compressed Oops, когда указатель ВНЕЗАПНО становится не указатель... но всё работает как и раньше. EP>В C++ скомпилированном в JS тоже под капотом получается ВНЕЗАПНО совсем не указатель. И дальше что?
В С++ понятие платформы — в стандарте языка, зачем это же в тащить в байткод, который собственно и создавался для того, чтобы обеспечить платформонезависимость?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
K>>То, что MS всегда найдёт самую тухлейшую отмазу "почему здесь торчит изолента" — это я знаю, мне нужен инженерный ответ: "ЗАЧЕМ БАЙТКОДУ БИТНОСТЬ?". EP>Предположу что это битность не байткода, а предпочитаемой цели. На x32/x64 разный объём доступной памяти, и разные размеры указателей (что влияет на потребление и в следствии скорость). Плюс в x64 процесс нельзя загрузить x32 dll, которая может быть сторонней.
Добавлю предположений.
Битность не самого байткода, а его окружения.
Фактически интерпретатора (jit-компилятора).
Я ж так понимаю, что он весь целиком лежит в исполняемом файле.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Kolesiki, Вы писали: K>>"ЗАЧЕМ БАЙТКОДУ БИТНОСТЬ?".
S>Для оптимизаций типа выравнивания. Т.е. можно заранее подготовить, а не по ходу дела.
Тогда зачем вообще связываться с байткодом, если ты заранее ограничиваешь бинарь той системой, под которую заточил??
K>>Разве не за универсальность боролись "отцы Жабы", чтобы навсегда забыть о битах, процессорах и прочей чуши, которая не имеет никакого отношения к кодингу?
S>Где-то читал, что когда Гослинга спросили про 100% портируемый код, он взоржал в ответ и сказал, что такого не бывает в природе.
Ну во-первых, Гослинг — не истина в последней инстанции, это прежде всего человек со своим уровнем интеллекта и образования. Это к тому, что нет никаких прямых доказательств "не бывает в природе".
Во-вторых, насколько я помню, Жаба и есть тот самый байткод, где никогда не упоминалась ни битность, ни какие-либо другие специфики.
В-третьих, Микрософт и так ЧЕТЫРНАДЦАТЬ ЛЕТ никуда не торопилась портировать .NET — что б с того, если бы байткод был Intel only?? Я бы даже это простил! Но потратить 14 лет, чтобы придти к тому же геморою, с которого начинали — это уже технологическая тупость!
К слову, уже сейчас Java опережает дотнетину в некоторых тестах (я не все проверял). Заметьте — и это всё без единой заточки байткода под битность!
K>>И что самое обидное, полностью извратив идею байткода, мелкомягкие клоуны опять куда-то бегут через всю индустрию с флагом "теперь всё нативно!". Попутно похерив весь свой мобильный сегмент.
S>Устройтесь туда на работу и покажите клоунам как надо. Дел то на пару собеседований.
Ха... Это как устроиться в Кремль, чтобы Россию поднять — самим-то не смешно? Что я могу лично, так это сделать свою платформу, с джитом и байткодами, которая по крайней мере не будет заниматься мозготраханьем "вам чёрный Форд какого цвета?".
Здравствуйте, Kolesiki, Вы писали:
EP>> Плюс в x64 процесс нельзя загрузить x32 dll, которая может быть сторонней.
K>Это вообще из мира венды. Байткод — у нас есть только он.
Бг.... Попробуй JNI попользовать в столь любимой тобой яве. Неожиданно окажется, что не только под виндами нативные dll'ки могут иметь разную битность.
K>Как его разрулят на уровне ОС — дело третье.
Причем тут ОС? Она про байткод вообще ничего не знает.
Здравствуйте, alexzzzz, Вы писали:
A>Стоит у пользователя 64-разрядная Ява, он программу запускает, а она не запускается. Ему что, обязательно знать, что проблема из-за того, что Явы, оказывается, бывают разные? Ну допустим так, но 64 ведь лучше, чем 32. Должно же работать. Или нужно 86-разрядную? Да он даже не знает, что такое Ява. Остров вроде, а может мотоцикл.
Реплика в сторону — однако же, что такое трамблёр, шрус, дром.ру, курс доллара и соединение металлопластика "под пресс" — этот пользователь таки выучил. Иногда после того, как лишился изрядного количества денег и нервов. И про яву выучит, не бином Ньютона.
Дополнительное следствие: чтобы пользователь быстрее учился, программа его должна ощутимо бить по голове.
Здравствуйте, Sharov, Вы писали:
S>Это менее важная причина. Товарищ Точка выше уже описал главную причину, почему битность торчит -- заголовок PE-header'а.
Здравствуйте, LaptevVV, Вы писали:
LVV>Вот эта минимальная часть тоже может быть 32-битной или 64-битной. LVV>И библиотеки загружать соответствующие, как тут уже ранее отметили.
In a .NET executable, the PE code section contains a stub that invokes the CLR virtual machine startup entry, _CorExeMain or _CorDllMain in mscoree.dll
Здравствуйте, 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…):
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, AlexRK, Вы писали:
ARK>>Здравствуйте, Serginio1, Вы писали:
S>>>Так самый смех заключается в том, что с NGEN и CLR не подходит пот терминалогию VM так как выполняется код под конкретную платформу.
ARK>>Это ничего не значит. "Виртуализировать некоторую платформу" можно любым способом, главное, что эта платформа (IL) в принципе есть. Остальное неважно — интерпретируется IL, компилируется или вычисляется вручную кучей китайцев в подвале. S> Ну дык под это определение подходит и C++. Он тоже кросс-платформенный и компилируется. Ничем IL от C++ не отличается. Просто он более низкоуровневый.
У вас все перемешалось, надо вам прочитать какю-нить литературу.
Вы путаете языки программирования, интерпретатор, компилятор, среду исполнения, байт код, виртуальную машину и мне кажется даже OS.
1 язык программирования надеюсь нет смысла объяснять
2 Интерпретатор — читает текст программы как есть и выполняет инструкцию (для c, c++, perl, ... есть интерпретатор)
например bash тоже интерпретатор не переводит даже в машинный код, или tcsh — этот shel тоже является
интерпретатором но "C" языка. Первые движки javascrip тоже являлись только интерпретатором. Конечно теперь у javascrip есть виртуальная машина и компилятор.
У Perl есть и интерпретатор и виртуальная машина и даже может компилить в нативные инструкции процессора (машинный код). Хотя когда запускаете perl script то идет компиляция на лету в байт код и потом виртуальная машина PERL исполняет этот код.
3 компилятор преобразует исходный текст программы в машинный код или в код виртуальный
машины (по другому абстрактной как раз этот код потом исполняется виртуальной машиной например Java, perl, Lua, .Net, ...)
как понимаешь виртуальная машина не абстрактное понятие а конкретное приложение и исполняет конкретный байт код
который сформировал соответствующий конкретный компилятор из конкретного языка программирования
4а среда исполнения может быть как непосредственно процессор (частенько в микроконтроллерах программа работает напрямцю с процессором без каких либо OS), но может средой исполнения быть и процессор в связке OS который может предложить дополнительные удобства. Например загрузку или выгрузку программы и дополнительно предложить готовые
функции по вводу и выводу и также функции по доступу к оборудованию.
4б Но средой исполнения, например для байт кода, может выступать и виртуальная машина, которая кроме исполнения
байт кода может предложить и дополнительные услуги,компиляция в нативный код, сборщик мусора, доступ к
оборудованию (например звуковой карте и т.д.)
5 байт код (абстрактный код или виртуальный код т.к. нет такой машины с электрической схемой которая могла бы выполнить этот код) как мы уже сказали может быть получен путем компиляции в байт код (прошу заметить в независимый код от процессора системы на котором будет запускаться данное приложение).
Но то что сегодня этот байт код является виртуальной сегодня то завтра может быть сделан специальный
процессор для этого кода. Так случилось с Java-ой т.к. для байт кода Java создали процессор.
6 Виртуальная машина это программа которая является прослойкой между байт кодом и процессором.
виртуальная машина берет байт код и выполняет на целевой системе "интерпретируя" этот код, но заметьте виртуальная машина при этом не становится интерпретатором. Ранее мы уже сказали что интерпретатор анализирует текст программы а не байт код, само слово "код" — и есть ключевое понятие машины и в данном случае виртуальной.
S>>>В CLR весь код компилируется при первом обращении к классу.
ARK>>После этого CLR можно отключать? ARK>>Правда после отключения мы захотели обратиться еще к одному классу и... S>Ну скомпилировали через NGEN и JIT компиляцию можно отключать (если конечно нет рефлексии к неподгруженным сборкам) S> CLR это не только JIT но и менеджер памяти и сборка мусора. Аналог CLR только оптимизированный есть и в .Net Native.
Здравствуйте, LaptevVV, Вы писали:
LVV>Битность не самого байткода, а его окружения. LVV>Фактически интерпретатора (jit-компилятора). LVV>Я ж так понимаю, что он весь целиком лежит в исполняемом файле.
А вот и не угадал! Мы для того и ставим дотнетину под сотню мег, чтобы ОНА занималась всем этим джитом и оптимизациями.
Мы, как наивные простофили, верили рассказам "джит может оптимизировать код под платформу, где исполняется", а на самом деле он даже MMX не задействовал!! Вот такая вот халтура под маркетоидным соусом.
PS
Про MMX могу ошибаться, но суть вы поняли — джитнутый код очень далёк от кода, который МОГ БЫ оптимально исполняться на текущем CPU.
Здравствуйте, vmpire, Вы писали:
K>>"Что это за биты? Что это за "prefer"? Нам таких не надо, диско-суперстар!" (ц) V>Если Вам не надо — выбирайте AnyCPU.
Выбрал. А студия, работая под 64-битной вендой, нарыгала мне 32-битную шнягу! В результате прога не смогла загрузить 64-битную DLL-ю (стороннюю). Так какой смысл во всей этой .NET-тряхомудии?? Писал бы себе на Delphi и имел бы ровно те же грабли, но на порядок больших скоростях и точно зная, чего ожидать. (это не говоря об ожиданиях по портированию приложений под mobile!)
K>>То, что MS всегда найдёт самую тухлейшую отмазу "почему здесь торчит изолента" — это я знаю, мне нужен инженерный ответ: "ЗАЧЕМ БАЙТКОДУ БИТНОСТЬ?". K>>Разве не за универсальность боролись "отцы Жабы", чтобы навсегда забыть о битах, процессорах и прочей чуши, которая не имеет никакого отношения к кодингу? V>см. басню крылова "свинья под дубом".
Может, всё таки "медведь на воеводстве"? "Мартышка и очки"? "Квартет"? Любая басня подойдёт ко смыслу "Три пижона решили, что можно скондачка переименовать Жабу в .NET и чтобы не терять время, захардкодить её по самые шлейфы на вендоплатформу, да ещё пусть с битностью помучаются".
V>Всё выполняется в конечном счёте на "битах, процессорах и прочей чуши".
Ну просто открыл глаза, чо! Ну то есть создатели JVM — они дураки, думали их виртуальная машина сама из проца выросла?
V> Хотите, чтобы выполнялось хорошо — приходится думать и об этом.
Вот именно, что НЕ ХОЧУ. Программе не надо работать "очень быстро", ей надо работать "приемлемо быстро", что и позволяет дотнет. Почему я должен думать обо всех этих битах? Были бы мне нужны биты, сидел бы и сипипискал до сих пор! В ДотНЕТ люди приходят именно за этим — вылезти из 20 века и начать уже жить алгоритмами, а не "32-битными dll-ками".
V>Волшебной палочки не бывает, полной изоляции от аппаратуры добиться невозможно.
JVM.
K>>Попутно похерив весь свой мобильный сегмент. V>Это к данному вопросу вообще отношения не имеет
Ещё как имеет! Имеющий нормальное зрение, да узрит: имей мы нормальный ДотНЕТ, приложения можно было бы просто копировать в телефон и запускать! (как сейчас Java и делает) Увы, микрософту сии мечты не видать как ушей — они сами сознательно шли к своему "портируемому одноплатформенному болоту".
Здравствуйте, Kolesiki, Вы писали:
K>Вы считаете, что эта экономия на спичках что-то значит?
Иногда она значит очень много.
K>Да сегодня только убогие планшеты сидят с гигабайтом, у всех по 4 гига минимум — какой смысл в экономии? Не говоря о том, что для крупных данных существуют minimum requirements. Хочешь предсказывать погоду — будь добр, ставь 32 гига ОЗУ и считай сколько хочешь.
Сколько гигабайт там размер кэша процессора? Сколько в него влезет 32-х битных указателей, а сколько 64-х битных?
K>Глядя на всё это, просто диву даёшься, как можно было написать такой бестолковый проект как .NET, что аж пришлось переписывать в .NET Core — настолько прибита гвоздями вся внутренняя кухня, включая, мать их, даже биты!
Роди свой "толковый проект", если сможешь. Все тебе только спасибо скажут.
Здравствуйте, Kolesiki, Вы писали:
K>PS K>Это не холивар, это абсолютно технический вопрос для выявления костылей .NET платформы.
в проекте есть зависимости от 32-х битных нативных DLL\OCX, переделывать которые в 64бита никто не собирается, т.к. не нужно. Как без явного указания битности использующей их сборки решить эту инженерную проблему? Поведай нам, местный юродивый
Здравствуйте, samius, Вы писали:
K>>Опять отсылаю к значению слова "виртуальный" в понятии VM. S>Простите, а причем вообще VM? Вы же тему про .NET вроде начинали, не?
А .NET это что, не VM?
А так-то топикстартер прав. Просто очередной кривой костыль.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, vl690001x, Вы писали:
V>>32 бита позволяют создавать объекты в памяти не более 2 гигов. V>>Часто нужно больше. Тогда надо принудительно указывать это.
Ф>Ни разу не было нужно. Более того, мне ни разу не было нужно более 2 гигов памяти.
Зависит от специфики выполняемых задач, очевидно. 64 бита не просто так придумали.
Здравствуйте, ·, Вы писали:
A>>Стоит у пользователя 64-разрядная Ява, он программу запускает, а она не запускается. Ему что, обязательно знать, что проблема из-за того, что Явы, оказывается, бывают разные? Ну допустим так, но 64 ведь лучше, чем 32. Должно же работать. Или нужно 86-разрядную? Да он даже не знает, что такое Ява. Остров вроде, а может мотоцикл. ·>У программиста (возможно у другого) проблема будет только лишь собрать дистрибутив под соответствующую платформу, даже возможно с bundled VM, ну чтобы пользователю не надо было, как обычно, трахаться с установкой правильной версии .net-фреймворка, а затем развлекаться с Microsoft .NET Framework Repair® Tool™. ·>Но это сборка дистрибутива, а не компиляция шарп-кода. Каждому шагу процесса соответствующие вопросы, а не текучие абстракции.
Программу с правильно установленным флажком достаточно просто скачать и запустить. Щёлкнуть два раза мышкой по .exe, и он весело запустится. Если программисту хочется потрахаться, он всегда найдёт где.
A>>При таком отношении к пользователю не удивительно, что Ява на десктопах начинается и заканчивается на Майнкрафте. ·>Обилие шарп-софта на десктопе я наблюдаю только в корпоративной среде, где всё и так ставят админы.
Админ тоже человек и терпеть не может программы, которые хотят странного. Когда есть выбор, предпочитает ту, которая минимально парит ему мозг. Если бы программисты знали, что админы о них думают (иногда вслух)...
A>>А я знаю, есть или нет? Я пользователь. Ты ж программист, давай, я тебе в субботу позвоню, а ты мне по телефону всё починишь? В понедельник утром уже сдавать отчёт, а ничего не работает. Что конкретно не работает? Ничего не работает. ·>Такому пользователю даёшь .zip или setup.exe, который распаковывает всё что надо, включая нативные либы и jvm, и можно запускать приложение.
Просто выставить x86 недостойно или другой работы мало? Или раз в Яве этого нет, то ненужно?
A>>1. Либо она под x64 в принципе неработоспособна, потому что, например, в свою очередь зависит от x86-only нативной библиотеки. Тогда делаешь свою программу тоже x86-only, другого варианта всё равно нет. ·>А если попалась библиотека x86+x64, но не ARM и Itanium? Что делать?
Во-первых, так не бывает. Во-вторых, в этом пункте рассмотрена ситуация, когда ограничение выставлено осознанно разработчиком библиотеки ― ему виднее, где она работоспособна, а где нет. Если считаешь, что знаешь это лучше разработчика, переходишь к пункту 2.
A>>2. Либо ограничение, не знаю как, вдруг возникло по ошибке. Если ты в этом уверен, убираешь ограничивающий флажок ручками взад и пользуешься. ·>Убираешь где?
Ну где установлен (в библиотеке), там и убираешь. Логично вроде.
Здравствуйте, ononim, Вы писали:
O>·>Ну понятно, раз нет нативных бинарников под данную платформу — их надо либо поставить, либо запустить под 32 бита. Зачем это делать программисту во время билда CIL-сборок? O>Потому что CIL сборка использует в качестве контейнера PE формат. У этого контейнера есть опция — запускать в 32 битах или 64 битах. Используя циркуль, буханку хлеба и hiew можно этот флажок поменять в уже собранном ехе-шнике, но зачем?
Ну да, это я уже понял откуда свисает изолента. Они примотали потенциально платформонезависимый артефакт (CIL-сборку) к платформозависимому PE-формату. Ну и получилось что получилось...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Sharov, Вы писали:
S>Благодарю, так яснее. Хотя не согласен в том, что managed код совсем уж не отличается. Я точно не уверен, но думается мне, зная target битность компилятор может получше провести оптимизацию байт кода, нежели в случае AnyCpu. Но я ничего не утверждаю, просто логично было бы предположить...
Это же легко проверить.
Тут ещё есть такой момент — даже если какие-то оптимизации по типу тех, о которых ты говоришь, и производятся, результирующий код всё равно остаётся переносимым между 32 и 64 битами. Ибо флаг битности можно поменять и без перекомпиляции (см. corflags.exe), при этом сборка остаётся работоспособной (опять же, при условии, что у неё нет платформо-зависимых dependencies).
Здравствуйте, Serginio1, Вы писали:
S> То есть машинный код берется из формата?
С точки зрения VES — безусловно да. На входе данные в общепринятом формате, на выходе — исполняемый код.
С точки зрения конкретной реализации вместо IL может быть что угодно, от своего диалекта и до генерации RyuJIT IR напрямую из текстовых исходников.
Вы сначала определитесь, какой именно уровень и чего именно мы обсуждаем, затем можно продолжать будет.
Иначе получается очередная попытка натянуть нотный стан на струны рояля. А чо, и там и там музыка, ключи, и ноты и клавиши чорно-белые, да и молоточки на ноты (не)похожи.
Вот как-то так оно выглядит
S> Кстати насчет интерпретаторов S> А вот натягивание этого понятия на CLR, да вообще на .Net в целом мало отличается от совы и глобуса. S> Java назвала JVM и отсюда все, что связано с байт кодом и сборщиком мусора стали называть VM
Ну да, не надо смешивать описание реализаций в разных языках. В каждом из сложилась своя терминология и трактовка понятий "VM" в питоне и в яве пересекаются весьма слабо. Особенно если учесть, что вариантов питона штук двадцать, на любой вкус.
Тынц как пример.
Здравствуйте, Serginio1, Вы писали:
S>>С точки зрения VES — безусловно да. На входе данные в общепринятом формате, на выходе — исполняемый код. S> Данные в общепринятом формате это что?
ECMA-335 Partition III: CIL Instruction Set.
S> Почему этот формат легко декомпилировать в C# или Delphi.Net?
Коротко: везение.
Подробней: по двум причинам:
* из бинарного представления восстановить il не сложнее, чем набросать простенький дизассемблер.
* до недавнего времени конструкции шарпа легко и однозначно сопоставлялись с последовательностями в il.
Но начиная с третьего шарпа всё больше логики декомпиляторов — это эвристики, которые легко ломаются на обновлениях компилятора или при использовании il-реврайтеров. Халява кончилась.
S>>и до генерации RyuJIT IR напрямую из текстовых исходников. S> То есть это язык который компилируется в машинные коды?
UPD: вопрос про RyuJIT IR? Если да — Это вообще не язык, это ещё одно представление потока инструкций (по аналогии с gcc ir или llvm ir), заточено под быстрые оптимизации и лёгкую трансляцию в бинарный код.
Тем не менее даже такой изврат наотлично будет работать с остальным managed-кодом, чем с незапамятных времён пользовались отдельные извращенцы (см секцию Native Injection).
Если нет и вопрос про IL — см выше
С CIL вечно путаница — под ним понимают и CIL bytecode и CIL как язык, из контекста обычно понятно
для преобразования в бинарный код сам язык, очевидно, не нужен.
S>>Вы сначала определитесь, какой именно уровень и чего именно мы обсуждаем, затем можно продолжать будет. S> Ну дык мы говрим о натягивании понятия VM на все, что имеет байт код.
А, бесполезное это дело. Нужно ещё знать контекст, в котором обсуждаем. Иначе под VM кучу разных вещей c разных логических уровней набивается. Про что и писал выше
Если говорить про CLI как про абстрактную модель, то там VM разумеется присутствует, но когда дело доходит до готовых бинарников, то вся роль "VM" сводится к набору runtime services. Конкретный их состав зависит от таргетинга.
S> Например по твоему CIL это не байт код.
Так CIL или CLI? разные ж вещи
Если CIL — тыкни носом, где я это писал плиз.
K>Это не холивар, это абсолютно технический вопрос для выявления костылей .NET платформы.
Этот переключатель постоянно сбивает всех с толку.
На самом деле он никак не слияет на байткод, байт код генерится всегда.
Этот переключатель просто выставляет флаг в заголовке просто для того что бы сделать невозможным запуск вашего бинарника не не поддерживаемой системе. Почему она может быть не поддерживаемой — куча вариантов на самом деле
The “bit-identical” computation ideas came from a desire in the 60s to ensure semantics over many platforms (and this is oddly still not a top priority in the computing world). In the ARPA-Parc community — which was working on personal computing pervasively networked over the world — thus many hardware platforms and likely many OSs — this was a critical need.
The byte code virtual machine idea traces back to an actual piece of hardware — the Burroughs B5000, mostly designed and invented by Bob Barton — which had the aim of being able to directly manifest a reasonable hardware platform for “higher-level languages” (such as Algol). The result was quite wonderful, and at many more levels than just byte-codes (all computer people should know about and understand this amazing design from the early 60s).
Various people realized that the B5000 architecture would make a great and highly portable virtual machine — a notable example was Wirth’s and Weber’s Euler language (CACM Jan-Feb 1966), whose byte-codes were later executed via microcode by Weber. These were called P-codes and were used in a variety of systems, including Pascal.
Я так понял, что без соотв. железа разработчики так и будут кувыркаться с битностью.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
K>> "ЗАЧЕМ БАЙТКОДУ БИТНОСТЬ?".
EP>Предположу что это битность не байткода, а предпочитаемой цели.
Вот это-то и смешно! Откуда я знаю, в какой системе будет запущено приложение? Моё дело — "универсальный байткод". Дело вирт.машины — его джитить или тупо интерпретировать. Что опять нас приводит к вопросу о битности.
EP> На x32/x64 разный объём доступной памяти, и разные размеры указателей
Каким боком это должно касаться байткода? Корячиться с битами — полностью задача VM. В крайнем случае, можно дописать к "запускатору" ключ "компиляй в 16 бит". Но байткод-то один и тот же!
EP> Плюс в x64 процесс нельзя загрузить x32 dll, которая может быть сторонней.
Это вообще из мира венды. Байткод — у нас есть только он. Как его разрулят на уровне ОС — дело третье.
Здравствуйте, Kolesiki, Вы писали:
K>>> "ЗАЧЕМ БАЙТКОДУ БИТНОСТЬ?". EP>>Предположу что это битность не байткода, а предпочитаемой цели. K>Вот это-то и смешно! Откуда я знаю, в какой системе будет запущено приложение?
Такое что в x64 системе может работать x32 код. И что лучше для твоего конкретного приложения среда может и не знать
EP>> На x32/x64 разный объём доступной памяти, и разные размеры указателей K>Каким боком это должно касаться байткода?
А оно касается?
EP>> Плюс в x64 процесс нельзя загрузить x32 dll, которая может быть сторонней. K>Это вообще из мира венды.
Это из мира реального железа, и справедливо в том числе и для Linux, и для OS X
Здравствуйте, Kolesiki, Вы писали:
EP>>Да, об этом и речь. Это даже априорно понятно, без тестов — указателей в программах много K>Вы считаете, что эта экономия на спичках что-то значит?
А с чего ты взял что это спички? Речь идёт не про какие-то константные расходы, а про примерно пропорционально зависящие от объема данных. На 300k указателей перерасход больше гигабайта
K>Да сегодня только убогие планшеты сидят с гигабайтом, у всех по 4 гига минимум — какой смысл в экономии?
1. Если программа на x32 использует например один гигабайт, а на x64 — полтора — то ей может не хватить реальной памяти, особенно учитывая то, что системы многозадачные, если ещё всякие веб-браузеры и т.п.
2. Я уже объяснил — дело не только в объёме, но иногда ещё в падении скорости (из-за лишнего объёма).
K>Не говоря о том, что для крупных данных существуют minimum requirements.
Шта?
K>Хочешь предсказывать погоду — будь добр, ставь 32 гига ОЗУ и считай сколько хочешь.
А софт конкурентов при этом укладывается в 1GiB
K>И потом, вся эта кутерьма с VM затеяна не ради экономии байт.
Если можно сэкономить, причём минимальными усилиями, то зачем платить больше?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
K>>Вот это-то и смешно! Откуда я знаю, в какой системе будет запущено приложение?
EP>Такое что в x64 системе может работать x32 код. И что лучше для твоего конкретного приложения среда может и не знать
Какое дело байткоду какая битность у DLL??? Кто вообще сказал, что это будет виндовая библиотека? Давайте просто опишем процесс:
1. Я пишу прогу, компиляю её в совершенно абстрактный байткод. Никаких битов, выравниваний и прочей чуши. Где будет запущено ПО — не знаю, может даже на arduino!
2. VM, созданная специально для этой ОС, знает об окружении всё: битность, объём памяти, оборудование, способы линковки и т.п. И ей командуют "запусти этот шмот байткода".
3. VM транслирует байткод в нативные команды ЦПУ, попутно подгружая зависимые модули и транслируя их тоже (если надо). На выходе — готовый дамп процесса. Кто и как там вызывает 64-битный код из 5683-битного — БАЙТКОДУ ПОФИГ, за него может и должна это делать виртуальная машина, ибо ей известно об ОС всё.
Итак, повторяю вопрос: причём тут биты в байткоде?
EP>>> На x32/x64 разный объём доступной памяти, и разные размеры указателей K>>Каким боком это должно касаться байткода? EP>А оно касается?
Судя по сеттингам студии — да.
EP>>> Плюс в x64 процесс нельзя загрузить x32 dll, которая может быть сторонней. K>>Это вообще из мира венды. EP>Это из мира реального железа, и справедливо в том числе и для Linux, и для OS X
Реальное железо — причём тут оно? Мы говорим о вирт. машине — догадайтесь с трёх раз, к чему там слово "виртуальная".
Здравствуйте, Lexey, Вы писали:
L>Бг.... Попробуй JNI попользовать в столь любимой тобой яве. Неожиданно окажется, что не только под виндами нативные dll'ки могут иметь разную битность.
Большая часть java-программистов в жизни ни разу JNI не коснулись. И слава богу, pure-java решения как правило лучше себя ведут.
LVV>>Фактически интерпретатора (jit-компилятора). LVV>>Я ж так понимаю, что он весь целиком лежит в исполняемом файле.
K>А вот и не угадал! Мы для того и ставим дотнетину под сотню мег, чтобы ОНА занималась всем этим джитом и оптимизациями. K>Мы, как наивные простофили, верили рассказам "джит может оптимизировать код под платформу, где исполняется", а на самом деле он даже MMX не задействовал!! Вот такая вот халтура под маркетоидным соусом. K>PS K>Про MMX могу ошибаться, но суть вы поняли — джитнутый код очень далёк от кода, который МОГ БЫ оптимально исполняться на текущем CPU.
Да это пофигу.
Только в результате трансляции с студии мы все равно имеем исполняемый файл, который загружается загрузчиком оси, и начинает работать.
То, есть там все равно есть минимальная часть двоичных кодов.
Которая в процессе работы может загружать хоть черта лысого.
Вот эта минимальная часть тоже может быть 32-битной или 64-битной.
И библиотеки загружать соответствующие, как тут уже ранее отметили.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, vmpire, Вы писали:
K>>>"Что это за биты? Что это за "prefer"? Нам таких не надо, диско-суперстар!" (ц) V>>Если Вам не надо — выбирайте AnyCPU.
K>Выбрал. А студия, работая под 64-битной вендой, нарыгала мне 32-битную шнягу! В результате прога не смогла загрузить 64-битную DLL-ю (стороннюю).
Раз зависимости имеют привязку к архитектуре платформы, то надо выбирать конкретную архитектуру. Для этого тебе и предлагают выбор.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, samius, Вы писали:
K>>>Опять отсылаю к значению слова "виртуальный" в понятии VM. S>>Простите, а причем вообще VM? Вы же тему про .NET вроде начинали, не?
ARK>А .NET это что, не VM?
ARK>А так-то топикстартер прав. Просто очередной кривой костыль.
Ээээ.. чего?
S>>> Кроме того есть .Net Native ARK>>Ну есть и есть. Интерпретаторы С++ тоже есть. S> Которые выполняются со скоростью машинного кода? Ты бы хоть ссылки то почитал. S>
S>.NET Native использует то же сервер, что и компилятор C++, который оптимизирован для статических сценариев предварительной компиляции.
Во-первых, здесь не написано, что .NET Native выполняется со скоростью машинного кода.
Во-вторых, .NET Native в принципе не может достичь скорости неуправляемых языков просто хотя бы по причине наличия рефлексии.
В-третьих, .NET Native — не эквивалентен .NET.
И наконец — вообще неважно, с какой скоростью все исполняется, и скорость не имеет никакого отношения к определению того, является язык нативным или нет. Есть медленные нативные языки, есть быстрые виртуальные машины.
Здравствуйте, Sinix, Вы писали:
S>Если нужен ответ для маркетологов — тынц.
Вроде как совпадает с тем, что я говорю.
S>Ответ с скучной матчастью — тынц два.
Это тут уже было. И оно как бы ни о чем.
S>Ответ из серии "в реальности всё совсем не так как на самом деле" — тынц три (см. раздел Auto NGEN).
Это лень читать.
ARK>>Хуже того, .NET Native не сможет даже корректно скомпилировать любой MSIL, который может сожрать CLR. S>Эммм, а можно пример? А то тут два варианта: или просто не в теме, или сова на глобусе. Судя по ".Net Native ни под какой vm не выполняется" — речь про первое, но всякое бывает
Я не проверял, но читал, что рефлексию оно не переваривает, в частности, по приватным полям. Ога?
Здравствуйте, 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 оно никакого отношения не имеет, просто сэкономили на трансляторе.
С практической точчи зрения тут разницы никакой. Товарища, который выпустит код с подобной закладкой в продакшн надо переводить в внедренцы. Там как раз больше работы == больше денег.
Здравствуйте, ·, Вы писали:
EP>>Играет. На x32 больше 2-4 GiB откусить не получится (без хаков типа PAE). ·>Понятно, но это не связано с байткодом.
Это связано с тем во что транслируется байткод, собственно сабжевый флажок это и контролирует.
EP>>А то что у Java проблема с созданием массива в 8млрд байт на x64 — это ортогонально ·>При наличии поддержки в vm — создашь, теоретически ограничений нет. ·>Хотя на практике, насколько я знаю, такой имплементации vm никто не делал, т.к. бессмысленно, проще взять 64-битное железо. А так я слыхал о реализациях jvm для 16 или даже 8-битных процов.
Ну да, я же говорю — без хаков. А с хаками да, можно — но там уже будет указатель не указатель, а некий синтезированный индекс, и соответствующие penalty и т.п.
Здравствуйте, ·, Вы писали:
·>В яве этого бреда нет и не надо. Битность таргет-платформы JVM вообще никак не относится к тому как компилится исходный код.
EP>>Насколько я понял из темы — влияние сабжевых ключей на байткод это лишь неверное предположение — так зачем постоянно кивать в эту сторону? ·>Тут скорее всего проблема в том, что эти ключи вообще существуют.
Ключи существуют, чтобы решать конкретную проблему, которая Яве естественно тоже есть, но решает её там конечный пользователь самостоятельно. http://stackoverflow.com/questions/9757456/java-native-interface-32-bit-dll-on-64-bit-system
·>Наличие JNI и DLL-ек тоже не причина. System.loadLibrary просто выбирает подходящую нативную библиотеку под текущую платформу. Байткод-то тут причём?
Ну вот нет у тебя нативной библиотеки подо все платформы. Автор библиотеки скомпилировал её в 1995 году только под x86, а про x64 и x128 не догадался. Исходники стёр, сам застрелился, бекапы сгорели.
Но теперь тебе кровь из носу нужно, чтобы твоя программа могла загрузить эту нативную x86-библиотеку в ОС любой разрядности. Если на 64-разрядной ОС твоя программа будет автоматически запускаться как 64-разрядный процесс, как и куда она будет подгружать эту 32-разрядную библиотеку? Никак и никуда. Нужно будет параллельно поднять вспомогательный 32-разрядный процесс, загрузить библиотеку в него и организовать какую-нибудь связь между двумя полученными процессами.
Зачем такой геморрой? Достаточно в своей программе выставить флажок на запуск её в 32-разрядном виде всегда, независимо от разрядности ОС.
·>Понятно, но x86 это не байткод виртуальной машины, а машинный код конкретного железа. Зачем микрософт запихнула детали имплементации платформы на уроветь компилятора исходников — один Бг знает.
Был бы в Net дополнительно линковщик, запихнули бы в него. Кто пишет на диск финальный .exe, в того и пихать.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>·>Все эти оптимизации того что "x64 может легко увеличить потребление ресурсов на ровном месте" реализуются на уровне JVM (например упомянутый Compressed Oops) EP>>>При этом добавляя дополнительные тормоза. EP>·>А ссылки на факты есть? EP>Факт чего? Того что лишние манипуляции с каждым указателем будут давать дополнительные тормоза?
Единственный способ судить о перформансе — измерить перформанс. Рассуждения о том что некая манипуляция даёт тормоза — всего лишь спекуляции. Даже если манипуляции могут тормозить — это ничего не значит, например, использование меньшего объёма памяти на более короткие указатели может дать более значительный прирост производительности.
EP>Ты читать не умеешь? EP>
EP>>>Речь о том, что нативные библиотеки могут быть только под одну платформу. Это уже несколько раз было озвучено выше
EP>Например есть только x32 библиотека, купленная у стороннего поставщика N лет назад, со своей работой справляется на ура.
Ну запускай своё приложение на x32 vm. В чём проблема-то?
EP>>>Байткод не причём — это ты сам придумал. EP>·>И зачем тогда эти нативные библиотеки вообще в этом топике помянуты? EP>При том что сабжевые опции помогают разрулить ситуации когда например есть только x32 библиотека. Сам байт-код при этом не меняется, а меняется только соседний ключик.
А что делать, если есть x86 и x64, но нет ARM и Itanium? Какой флажок указывать?
EP>>>·>Это "Такое что в x64 системе может работать x32 код. И что лучше для твоего конкретного приложения среда может и не знать" решается тупо тем под какой JVM запускаешь — x32 или x64 — можешь иметь обе одновременно. EP>>>Это может легко решить разработчик на своей стороне, с помощью сабжевого ключика EP>·>Зачем ему это решать? EP>Чтобы пользователь бы доволен — запустил .exe и всё заработало
Тогда кроме как варианта поставлять native-библиотеки под все платформы — нет.
EP>>>>>x86 код например тоже может интерпретироваться EP>>>·>Понятно, но x86 это не байткод виртуальной машины, а машинный код конкретного железа. EP>>>И что из этого? К чему вообще эти майсы про интерпретацию? EP>·>Байткод исполняется на виртуальой машине, притом как интерпретацией, так и jit-компиляцией. EP>А ещё бывает на реальной — и чо?
Круто чё. И чё? Причём тут x86 машинный код? Зачем ты обосновываешь особенности использовании байткода микрософтом какими-то рассуждениями о машкоде?
EP>·>А вот к чему вообще тут x86 интерпретция? EP>Ты к чему-то непонятному сказал что байткод может быть интерпретирован — ОК — x86 тоже может быть — что сказать-то хотел?
Суть и предназначение машинного кода и байт-кода разное. Почитай учебники что-ли, ссылку на вики я уже давал.
EP>>>>>В C++ скомпилированном в JS тоже под капотом получается ВНЕЗАПНО совсем не указатель. И дальше что? EP>>>·>В С++ понятие платформы — в стандарте языка, зачем это же в тащить в байткод, который собственно и создавался для того, чтобы обеспечить платформонезависимость? EP>>>Давай пруфлинк на то что это есть в байткоде, ты уже несколько раз это сказал на протяжении последних сообщений. EP>·>Что "это"? Что байт код для платформонезависимости? EP>Ты говоришь "зачем это же в тащить в байткод" — покажи как сабжевые опции влияют именно на байткод.
Ты не сможешь запустить байткод под неправильной платформой, если он собран с этим флажком.
EP>·>И ВНЕЗАПНО — некий CIL код может работать исключительно на 64 битах. Упс. EP>Так же как и Java код напрямую использующий x64-only библиотеки
Конкретно java-код будет работать как и раньше. Просто не сработает вызов System.loadLibrary, кинет исключение, которое, кстати, можно поймать и, например, переключиться на менее эффективную pure-java реализацию.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Философ, Вы писали:
_>>Единственно стоит заметить, что это проблемы любого байт-кода, а не только .net. И в борьбе с этим пожалуй дальше всех продвинулась Java, благодаря их escape-анализу. Однако это всё равно всё полумеры, не решающие базовую проблему. Ф>Это проблемы JIT'ера, а не IL.
Это проблемы идеи "приложение — файл с байт-кодом". А соответственно если выкинуть эту идею, то и IL не особо нужен становится.
_>>На мой взгляд реальным универсальным решением была бы компиляция приложения при установке не пользовательскую машину. Т.е. разработчики генерируют байт-код (скажем какой-нибудь там llvm), а при инсталляции он превращается (с полноценной оптимизацией) в нормальный нативный. Ф>ngen?
Ну для начала я пока что не слышал про компилятор с приличной оптимизацией для .net. Естественно в теории он возможен (хотя многие части идеологии .net будут противоречить быстродействующему коду и до уровня того же C++ не добраться никогда, даже с максимально оптимизирующим компилятором, но это уже тема для другой дискуссии), но на данный момент с этим проблемы. Но даже если MS и сделают его, это всё равно только часть задачи. Кроме этого требуется соответствующая инфраструктура распространения. И пока что я не видел движений в этом направление. Есть отдельно обычный .net (распространение байт-кода) и отдельно в перспективе существует .net native (соответственно распространение машинных инструкций). А вот про инфраструктуру с распространением байт-кода, компилируемого при инсталляции — про такое у MS я не слышал. Хотя на других платформах примеров реализации подобной техники весьма не мало.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, wraithik, Вы писали:
W>>Да хрен там. W>>Я так мелкую утилиту собрал для х64 (стоит по умолчанию, я на на шарпе пишу крайне редко), так эта гадина под Вынь 7 х86 не запустилась, проорав "я не х86". W>>Какая к черту разница какая битность в .НЕТе
W>>Хотя есть подозрение что там только заголовок файла разный.
S>http://rsdn.org/forum/flame.comp/6576282.1
EP>>>>Насколько я понял из темы — влияние сабжевых ключей на байткод это лишь неверное предположение — так зачем постоянно кивать в эту сторону? A>>·>Тут скорее всего проблема в том, что эти ключи вообще существуют. A>>Ключи существуют, чтобы решать конкретную проблему, которая Яве естественно тоже есть, но решает её там конечный пользователь самостоятельно. A>>http://stackoverflow.com/questions/9757456/java-native-interface-32-bit-dll-on-64-bit-system ·>Ну понятно, раз нет нативных бинарников под данную платформу — их надо либо поставить, либо запустить под 32 бита. Зачем это делать программисту во время билда CIL-сборок?
Потому что CIL сборка использует в качестве контейнера PE формат. У этого контейнера есть опция — запускать в 32 битах или 64 битах. Используя циркуль, буханку хлеба и hiew можно этот флажок поменять в уже собранном ехе-шнике, но зачем?
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ·, Вы писали:
·>Ну да, это я уже понял откуда свисает изолента. Они примотали потенциально платформонезависимый артефакт (CIL-сборку) к платформозависимому PE-формату. Ну и получилось что получилось...
И получилось отлично: .NET процессы видны в таск менеджере со своими нормальными именами безовсяких приседаний, GetModuleHandle(NULL) и прочий API работает. В добавок AnyCPU никто не отменял, чего по три круга ходить-то.
Здравствуйте, ononim, Вы писали:
O>·>Ну да, это я уже понял откуда свисает изолента. Они примотали потенциально платформонезависимый артефакт (CIL-сборку) к платформозависимому PE-формату. Ну и получилось что получилось... O>Ну, на самом деле тот флажок в РЕ заголовке — архитектура процессора, там помимо интела 32/64 что угодно может быть, так что примотать могли и по другому, прописав туда процессор некий пусть будет CIL_MACHINE. O>Но дело тут такое — х64 винда с дотнетом это на некотором уровне приближения две винды с двумя дотнетами — 32хбитная винда с 32хбитным дотнетом и 64 битная винда с 64хбитным дотнетом. И как тут выбрать на чем работать?
Понятно. Т.е. в итоге сабж это не продуманное архитектурное решение, а необходимость как-то бороться с platform-hell в винде.
Скажем, в дистрибутив java приложения делается специальный launcher (или несколько) под конкретную платформу (app.exe/app.sh/etc), а само приложение обычно кладётся как jar рядышком.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Ну наверное Микрософту делать нечего было, ну и запилили на выходных эту тулзу ради прикола.
Сами решают свои проблемы сами, не сваливая на пользователя.
A>>У меня дома долго висела Java 8 Update 73 (64-bit), которая ни работать не хотела, ни удаляться. Сейчас про неё вспомнил, пришлось грохать папку и чистить следы вручную. Java Repair Tool не нашёл. ·>А какие там следы-то?
В реестре. Из-за которых Java всё ещё висела в списке установленных программ, и из-за которых java-программа, которую я скачал для проверки, при запуске писала что-то типа «Ява вроде есть, а вроде и нет, запускаться не буду».
A>>Тут раз двадцать уже написали, что флажок нужен/полезен только для тех случаев, когда у программы имеется жёсткая зависимость от какого-либо компонента, существующего только под одну конкретную платформу. Ну не работает твоя программа в режиме x64. Ей не нужно делать специальных ярлычков. Ставишь platform:x86 ― и теперь она знает сама как ей правильно запускаться на 64. ·>В данном случае нет "правильного". Правильность зависит от того, как пользователь хочет её использовать.
В двадцать первый раз написать? Программа не работает в режиме x64. Не потому что программист ― сволочь, а потому что объективно не работает. С таким же успехом пользователь может хотеть две тонны золота в слитках.
A>>·>Решение о таргет-платформе должно приниматься во время деплоймента, а не во время компиляции. A>>Он НЕ требуется на этапе компиляции проекта. Можешь выставить потом, когда захочешь, если надо. ·>Т.е. "/platform (C# Compiler Options)" это не опция компилятора, т.е. тулзы, которая компилирует?
Кто тебя требует её указывать во время компиляции? Никто. Хочешь принять решение позже? Принимай. Хочешь изменить уже принятое решение? Изменяй.
/out:<file> Specify output file name (default: base name of
file with main class or first file)
К опции out есть аналогичные претензии?
А что, к IL отношения не имеет, но тем не менее зачем-то является опцией компилятора. Можно не указывать, но значение по умолчанию будет всё равно. Какой идиот придумал указывать имя файла на стадии компиляции? Можно ведь задавать правильное имя файлу во время деплоимента. Собрать специальный инсталлятор, чтобы он выставлял правильное имя файла прямо на машине пользователя. А также делал два ярлычка на рабочем столе.
A>>Конкретно такой комбинации не бывает, чтобы «x86+x64, но не ARM и Itanium». Там либо конкретная платформа, на которую программа заточена, либо AnyCPU. ·>Комбинация, очевидно, бывает. Заточить программу можно под некое подмножество платформ. Просто компилятор так не умеет.
А зачем? У тебя есть волшебная нативная dll, код которой можно загрузить и в x86-процесс, и в x64-процесс и он везде будет работать?
Здравствуйте, ononim, Вы писали:
O>·>Понятно. Т.е. в итоге сабж это не продуманное архитектурное решение, а необходимость как-то бороться с platform-hell в винде. O>·>Скажем, в дистрибутив java приложения делается специальный launcher (или несколько) под конкретную платформу (app.exe/app.sh/etc), а само приложение обычно кладётся как jar рядышком. O>JRE тоже может быть несколько на системе, а может быть одна. С .нет ситуация более предсказуемая, потому разработчикам дали рычажок.
Ещё раз повторяю. java-софт для домохозяек обычно распространяется с bundled jvm, нужной версии с нужными native и т.п. — предсказуемее некуда, распаковывешь и запускаешь. О таком в .net только мечтать с их монструозным установщиками, которые втыкаются по самые гланды в систему, обязательно требуя админских прав, и как же без ребутов...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, fddima, Вы писали:
F>·>Так в том-то и дело, что оно _может_ являться компонентом системы, если очень хочеися, но _не должно_. Чем от меньшего числа компонент системы зависит некий софт — тем лучше. F> Нет, — дотнет неотъемлимый компонент целого ряда версий систем (и всех современных десктопных). Даже загрузчик модулей распознает дотнет модули. Правильно ли было делать так — вопрос иного толка, я совсем выше в этом топике кажется писал, но если кратко — мне лично, нравятся внешние интерпретаторы больше, но и плюсы от нативной интеграции есть.
Плохо, что есть _только_ нативная интеграция.
F>>>·>Когда рута нет, есть возможность вручную скачать/распаковать. F>>> Ага, а поставить возможности толком нет. F>·>Что значит "толком поставить"? Запускается и работает — этого не достаточно? Обязательно заколачивать в систему по самые гланды? Зачем? F>А если не запускается? Исполнимый модуль, например, банально импортирует модуль по абсолютному пути (для записи смертным недоступный).
Бага же, очевидно. Пофиксить надо.
F>Нужно уже совершать доп действия (например подредактировать шелл скрипт дабы втюхнуть переменные). Да и вообще там не простое копирование встречается. Просить от дотнета того же — странно. .net core теоретически можно бандлить (не знаю как просто это сделать, баловался только с ембедом рантайма в нэйтив).
Теоретически, если повезёт. Притом не поддерживается официально — хакайте сами, если сможете. Т.е. с какой-то версии может и поломаться и придётся придумывать новую теорию.
F>·>Она не порочна если абсолютно всё ставится из-под админа и никак по-другому ничего сделать нельзя. А в таком виде это тупо палки в колёса. F>Везде по сути можно ставить программы без админских прав,
Можно, но только если это не .net-программа.
F>с теми или иными ограничениями. Иначе это не комп а плеер/читалка/кому что по душе. Не все права даются юзеру, некоторый софт просто неспособен работать без соответствующих прав. В итоге неясно с чего такое безапелляционно е утверждение.
Я понимаю, когда эта программа требует что-то системного, ну там железо какое-то или открыть 80-й порт.
Но, скажем, обычный софт.. bug tracker например. Скачал, запустил, поигрался — не понравилось, выкинул, понравилось поставил нормально. Скажем, youtrack какой-нибудь — едет как бинарник, со встроенным web сервером и субд. Поиграться или вести баги для своей домашней странички — пожалуйста, установи на рабочий стол и пользуйся на здоровье. А потребуется для чего-то более серьёзного — поставишь по серьёзному с админ-правами на сервак, 80-й порт, большая субд и т.п.
F>>>·>Нифига они не рулят, просто выкручиваются как могут из-за отстутствия пакетного менеджера. F>>> Пакетные менеджеры сдуваются на конфликтах system-wide библиотек. В итоге бандлить чаще проще, что несколько ограничивает его применимость. В линуксах оно работает от того, что репозиторий фактически один центральный. Всякие внешние (дополнительные) источники, безусловно удобны, но как только появляются конфликты — оно перестает быть удобным. В итоге путь анархии — практически показал что это просто работает. А вот попытки контроллировать деплоймент централизованно (всякие сторы) — уже сложнее, чем могло-бы быть. KISS же. F>·>dll и прочий hell? Не, не слышал. F>Нет, не слышал. Приватные зависимости носим с собой.
sxs hell? или уже придумали новый hell?
F>Разве ад возникал не из-за тупого деплоймента?
Ад возникает из-за того, что вещи которые сами по себе внезапно становятся системными, вот и начинаются проблемы деплоймента.
F>·>Так для изврлюбителей и java есть ставящаяся в систему, с автообновлялкой и с теми же присущими глюками и заморочками. F> Так и отлично.
Правильно — отлично. Отлично то, что есть выбор. .net выбор не предоставляет.
F> Просто в фаре набираю java ... и этого на винде мне хватает. Зачем бандлить рантайм для программы весом в метр. Тем кому важен специфичный рантайм бандлят. Но это скорее от неизбежности, так просто проще. Но с дотнетом этого не нужно.
А разве не возникает проблем, что старый софт не работает на новой версии fw? И если нужной версии не оказалось...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alexzzzz, Вы писали:
A>·>"Recommended Method: Run the Microsoft utility to repair corrupted registry keys". А уж если и это мелкомягкое поделие не сработает, можно и ручками один ключик реестра прибить. A>Читал, даже воспользовался. Оно просто убирает Java из списка установленных программ, чтоб не отсвечивало. Ручками потом тоже нужно. Ручками завсегда можно, но хотелось бы, чтобы оно само.
Чтобы оно само что? Удаляешь да и всё.
Не хочешь мучиться с MSI, ставь яву из архива.
A>·>Ява тут не причём. Это мелкомягкий MSI жжот напалмом A>Ява всегда не при чём.
"Ты виноват уж тем, что хочется мне кушать".
Как может быть ява виновата в проблемах MSI?? Ок, могу допустить что в Оракле напортачили при создании инсталлятора, но это и не мудрено с такой замечательной технологией как MSI.
A>>>К опции out есть аналогичные претензии? A>·>Нет, ибо современные компьютеры данные хранят в файлах. Вывод компилятора — данные, данные без имени файла сохранять некуда.
A>1. /out можно не указывать. A>2. «Имя файла не влияет на работоспособность программы». A>3. Файл всегда можно переименовать. A>Зачем тогда опция?
Эта опция относится непосредственно к процессу компиляции. Компилятор должен куда-то класть свой вывод, вариантов нет. Обсуждаемый флажок никакого отношения к компиляции не имеет, а влияет только на работоспособность на последнем этапе жизненного цикла проекта — запуск в системе пользователя.
A>>>А зачем? У тебя есть волшебная нативная dll, код которой можно загрузить и в x86-процесс, и в x64-процесс и он везде будет работать? A>·>У меня есть две длл, под обе intel платформы, но нет под ARM/Itanium. Шо делать? A>Раз программа сама разрешает свои зависимости => AnyCPU.
Что значит сама? Почему нельзя всегда самой? Зачем эти частные случаи? Чем поддержка одной платформы из четырёх принципиально отличается от поддержки двух платформ из четырёх?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
A>>/out никакого отношения к процессу компиляции не имеет. Компилятору всё равно, как называется конечный файл. Опция опциональна, указывать не требуется, т.к. есть значение по умолчанию. /platform тоже не имеет отношения к процессу компиляции, компилятору всё равно, что там указано. Опция также не требуется, т.к. есть значение по умолчанию. ·>Не правда. Компилятор должен иметь какое-то имя файла, иначе ему некуда будет писать результат своей работы.
Здравствуйте, Kolesiki, Вы писали:
K>Итак, повторяю вопрос: причём тут биты в байткоде?
Ни при чём. Данная опция студии всего лишь ставит один флаг в заголовке файла. Его можно поменять без перекомпиляции с помощью утилиты corflags (ну или даже вручную с помощью hex-редактора). Нужна эта опция в основном для интеграции с легаси-кодом в виде COM-объектов (т.к. они бинарные, то для 32 и 64 бит нужны разные библиотеки, старые компоненты, соответственно, есть только в 32 битных билдах). У нас на работе полно такого хлама.
Здравствуйте, Sinix, Вы писали:
S>? S>гуй есть, обновление всего софта есть, селф-хостинг присутствует — что ещё для щастья надо-то?
Ну вот пару дней назад vbox сломался, сам одной версии, extensions другой, виртуалка не пускается. Вообще, поддержка многих пакетов в лучших традициях опенсорса.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Слава, Вы писали:
С>Вы нативый оракловый клиент когда-нибудь трогали, взаимодействовали с ним?
Кстати искренне желаю, чтобы его аффтаров до конца жизни мучал понос Ни один другой компонент не являлся источником стольких проблем, как эта поделка криворуких кодерастов
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Sharov, Вы писали:
S>>Еще разок. Причина -- необходимая битность PE-header'а, следсвтие -- managed код под windows может зависть от битности, хотя не должен. Где я ошибся? S>>Можно просто сказать, а не рожи крючитьфейспалмить.
K>Причина — необходимость загрузчику знать, какая среда исполнения нужна файлу, с тем, чтобы эту самую среду ему обеспечить перед запуском. Наличие флага — это следствие данной необходимости. Managed код под windows может зависить от битности только тогда, когда он использует компоненты, зависящие от битности. При этом сам managed код не становится каким-то особенным, отличающимся от "независящего", просто у него есть ограничения на то, в какой окружении он может работать.
Благодарю, так яснее. Хотя не согласен в том, что managed код совсем уж не отличается. Я точно не уверен, но думается мне, зная target битность компилятор может получше провести оптимизацию байт кода, нежели в случае AnyCpu. Но я ничего не утверждаю, просто логично было бы предположить...
Здравствуйте, Sinix, Вы писали:
S>> Например по твоему CIL это не байт код. S>Так CIL или CLI? разные ж вещи S>Если CIL — тыкни носом, где я это писал плиз.
Прошу прощения спутал
Кстати ассемблер то по сути представление потока инструкций
Помню еще в 80 х компилятои Пакскаля сначла переводил в ассемблер, потом obj затем в Exe
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, tranzit, Вы писали:
S>>Здравствуйте, tranzit, Вы писали:
...
Всё ок, но я бы сделал оговорку, что это всё с точки зрения разработки под абстрактную CLI-совместимую реализацию дотнета.
Когда дело доходит до _конкретной_ реализации на _конкретной_ платформе, то имеем классический "В теории, между теорией и практикой разницы нет. На практике — упс".
Скажем, компиляторы не вызывают Ilasm и вот это
но виртуальная машина может выполнять инструкции байт кода как от своего имени и при этом задействует
новы возможности процессора или же может вызвать jit компиляцию.
для любого девелопера под дотнет не вызовет никакой реакции кроме как "да ладно?". Не, _теоретически_ никто не запрещает писать под netmf скажем, где JIT-а на сегодня нет вообще, но на практике — сколько разработчиков этим занимаются?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Предположу что это битность не байткода, а предпочитаемой цели.
AFAIK верное предположение.
EP>На x32/x64 разный объём доступной памяти, и разные размеры указателей (что влияет на потребление и в следствии скорость).
Я несколько раз натыкался на статьи, которые на абстрактном или реальном примере показывали, что x64 может легко увеличить потребление ресурсов на ровном месте. Особенно когда явных преймуществ для задачи от x64 нет (в частности брали для тестов WebApp как я помню).
K>То, что MS всегда найдёт самую тухлейшую отмазу "почему здесь торчит изолента" — это я знаю, мне нужен инженерный ответ: "ЗАЧЕМ БАЙТКОДУ БИТНОСТЬ?".
Для оптимизаций типа выравнивания. Т.е. можно заранее подготовить, а не по ходу дела.
K>Разве не за универсальность боролись "отцы Жабы", чтобы навсегда забыть о битах, процессорах и прочей чуши, которая не имеет никакого отношения к кодингу?
Где-то читал, что когда Гослинга спросили про 100% портируемый код, он взоржал в ответ и сказал, что такого не бывает в природе.
K>И что самое обидное, полностью извратив идею байткода, мелкомягкие клоуны опять куда-то бегут через всю индустрию с флагом "теперь всё нативно!". Попутно похерив весь свой мобильный сегмент.
Устройтесь туда на работу и покажите клоунам как надо. Дел то на пару собеседований.
Здравствуйте, Doc, Вы писали:
EP>>На x32/x64 разный объём доступной памяти, и разные размеры указателей (что влияет на потребление и в следствии скорость). Doc>Я несколько раз натыкался на статьи, которые на абстрактном или реальном примере показывали, что x64 может легко увеличить потребление ресурсов на ровном месте. Особенно когда явных преймуществ для задачи от x64 нет (в частности брали для тестов WebApp как я помню).
Да, об этом и речь. Это даже априорно понятно, без тестов — указателей в программах много, особенно на управляемых языках — переход на x64 соответственно увеличивает потребление памяти, а ещё возможно и ухудшает быстродействие в memory-throughput-bottlenecked коде (но не всё так однозначно — например в x64 режиме доступно больше регистров).
При этом далеко не каждой программе нужно столько адресного пространства/памяти пространства.
Здравствуйте, Kolesiki, Вы писали:
K>"Что это за биты? Что это за "prefer"? Нам таких не надо, диско-суперстар!" (ц)
Если Вам не надо — выбирайте AnyCPU.
Бывает, когда битность важна.
K>То, что MS всегда найдёт самую тухлейшую отмазу "почему здесь торчит изолента" — это я знаю, мне нужен инженерный ответ: "ЗАЧЕМ БАЙТКОДУ БИТНОСТЬ?". K>Разве не за универсальность боролись "отцы Жабы", чтобы навсегда забыть о битах, процессорах и прочей чуши, которая не имеет никакого отношения к кодингу?
см. басню крылова "свинья под дубом". Всё выполняется в конечном счёте на "битах, процессорах и прочей чуши". Хотите, чтобы выполнялось хорошо — приходится думать и об этом.
Волшебной палочки не бывает, полной изоляции от аппаратуры добиться невозможно.
K>И что самое обидное, полностью извратив идею байткода, мелкомягкие клоуны опять куда-то бегут через всю индустрию с флагом "теперь всё нативно!".
Тgen существует давно, его просто доработали до автоматического удобного использования. Это не так чтоб очень новое.
K>Попутно похерив весь свой мобильный сегмент.
Это к данному вопросу вообще отношения не имеет
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Да, об этом и речь. Это даже априорно понятно, без тестов — указателей в программах много
Вы считаете, что эта экономия на спичках что-то значит? Да сегодня только убогие планшеты сидят с гигабайтом, у всех по 4 гига минимум — какой смысл в экономии? Не говоря о том, что для крупных данных существуют minimum requirements. Хочешь предсказывать погоду — будь добр, ставь 32 гига ОЗУ и считай сколько хочешь.
И потом, вся эта кутерьма с VM затеяна не ради экономии байт. VM — это
1. Портируемость кода без перекомпиляции.
2. Защита — в VM нельзя залезть в буфера ОС или выполнить привилегированную команду. Все команды априори безопасны, даже те, которые лезут по нулевому указателю.
3. Поддержка множества языков.
Глядя на всё это, просто диву даёшься, как можно было написать такой бестолковый проект как .NET, что аж пришлось переписывать в .NET Core — настолько прибита гвоздями вся внутренняя кухня, включая, мать их, даже биты!
Здравствуйте, vmpire, Вы писали:
K>>И что самое обидное, полностью извратив идею байткода, мелкомягкие клоуны опять куда-то бегут через всю индустрию с флагом "теперь всё нативно!". V>Тgen существует давно, его просто доработали до автоматического удобного использования. Это не так чтоб очень новое.
Здравствуйте, Sharov, Вы писали:
V>>Тgen существует давно, его просто доработали до автоматического удобного использования. Это не так чтоб очень новое.
S>NGEN
Русская Т, английская N. Одна клавиша. Не тпут, и на том спасибо
Здравствуйте, Kolesiki, Вы писали:
K>>>Вот это-то и смешно! Откуда я знаю, в какой системе будет запущено приложение? EP>>Такое что в x64 системе может работать x32 код. И что лучше для твоего конкретного приложения среда может и не знать K>Какое дело байткоду какая битность у DLL??? Кто вообще сказал, что это будет виндовая библиотека?
В смысле "будет"? Она есть, и её надо использовать, и для этого нужен x32 процесс.
K>Давайте просто опишем процесс: K>1. Я пишу прогу, компиляю её в совершенно абстрактный байткод. Никаких битов, выравниваний и прочей чуши. Где будет запущено ПО — не знаю, может даже на arduino!
Целевая платформа .NET приложений обычно заранее известна.
K>2. VM, созданная специально для этой ОС, знает об окружении всё: битность, объём памяти, оборудование, способы линковки и т.п. И ей командуют "запусти этот шмот байткода".
Она не знает что лучше для конкретного приложения — x32 или x64.
K>Кто и как там вызывает 64-битный код из 5683-битного — БАЙТКОДУ ПОФИГ
Не пофиг например если идёт взаимодействие с native библиотеками
Не пофиг если хочется сэкономить память, или наоборот получить большее адресное пространство.
EP>>>> На x32/x64 разный объём доступной памяти, и разные размеры указателей K>>>Каким боком это должно касаться байткода? EP>>А оно касается? K>Судя по сеттингам студии — да.
Именно байт-кода? Или одного значения/флажка рядом с этим байт-кодом?
EP>>>> Плюс в x64 процесс нельзя загрузить x32 dll, которая может быть сторонней. K>>>Это вообще из мира венды. EP>>Это из мира реального железа, и справедливо в том числе и для Linux, и для OS X K>Реальное железо — причём тут оно?
При том что на нём в итоге и работает код, а не в сферическом вакууме, и у которого есть вполне осязаемые ограничения
Здравствуйте, Kolesiki, Вы писали:
K>>>"Что это за биты? Что это за "prefer"? Нам таких не надо, диско-суперстар!" (ц) V>>Если Вам не надо — выбирайте AnyCPU. K>Выбрал. А студия, работая под 64-битной вендой, нарыгала мне 32-битную шнягу! В результате прога не смогла загрузить 64-битную DLL-ю (стороннюю).
Если это консольное приложение — снимите галку prefer 32 bit. Если не консольное — то так не бывает.
K> Так какой смысл во всей этой .NET-тряхомудии??
Смысл — он у каждого свой
K>Писал бы себе на Delphi и имел бы ровно те же грабли, но на порядок больших скоростях и точно зная, чего ожидать. (это не говоря об ожиданиях по портированию приложений под mobile!)
А что, кто-то заставляет? Пишите на Delphi, не думаю, что кто-то здесь будет против.
Кстати, там SEH, уже научились корректно поддерживать?
V>>Всё выполняется в конечном счёте на "битах, процессорах и прочей чуши". K>Ну просто открыл глаза, чо! Ну то есть создатели JVM — они дураки, думали их виртуальная машина сама из проца выросла?
А что, в жабе вы можете загрузить 32-битную dll в 64-битный процесс и наоборот?
V>> Хотите, чтобы выполнялось хорошо — приходится думать и об этом. K>Вот именно, что НЕ ХОЧУ.
Ну, каждому своё. Не хотите думать — используйте более высокоуровневые инструменты.
V>>Программе не надо работать "очень быстро", ей надо работать "приемлемо быстро", что и позволяет дотнет.
Это кому как. Мне вот часто приходится думать о том, как сделать, чтобы работало быстро.
V>>Почему я должен думать обо всех этих битах? Были бы мне нужны биты, сидел бы и сипипискал до сих пор! В ДотНЕТ люди приходят именно за этим — вылезти из 20 века и начать уже жить алгоритмами, а не "32-битными dll-ками".
У вас просто ожидания от .NET не совпали с реальностью. Может, проблема в завышенных ожиданиях?
V>>Волшебной палочки не бывает, полной изоляции от аппаратуры добиться невозможно. K>JVM.
Да ну, серьёзно и в java native тоже? Если вы скажете, что "не надо использовать вызовы нативных функций" то я скажу "так и в .NET их можно не использовать, выбирайте тогда AnyCPU с отключенной опцией prefer 32 bit"
K>>>Попутно похерив весь свой мобильный сегмент. V>>Это к данному вопросу вообще отношения не имеет K>Ещё как имеет! Имеющий нормальное зрение, да узрит: имей мы нормальный ДотНЕТ, приложения можно было бы просто копировать в телефон и запускать! (как сейчас Java и делает) Увы, микрософту сии мечты не видать как ушей — они сами сознательно шли к своему "портируемому одноплатформенному болоту".
Мобильный сегмент там похерен вообще не из-за .NET.
Здравствуйте, Sharov, Вы писали:
V>>Тgen существует давно, его просто доработали до автоматического удобного использования. Это не так чтоб очень новое. S>NGEN
да, опечатался
Я кстати предпочитаю когда интерпретаторы вызываются нормальным/внешним образом.
Но и решение .net процессы сделать родными — так же считаю правильным: безбожные вызовы GetModuleHandle(NULL) работают, нормальные имена процессов в task manager, да и вообще запуск безовсяких приседаний... Всё таки хорошая интеграция, с минимумом усилий.
Впрочем с .net core, насколько я понимаю об этом можно забыть.
PS: Проблема незаметная, но это до тех пор, пока third-party нативная библиотека не пытается получить базовый путь к программе, а получает какой-нибудь /usr/bin.
Здравствуйте, fddima, Вы писали:
F>PS: Проблема незаметная, но это до тех пор, пока third-party нативная библиотека не пытается получить базовый путь к программе, а получает какой-нибудь /usr/bin.
.Core сейчас для веба / UWP, там без вариантов надо использовать фирменное API для получения путей к контенту (при этом бинарники могут быть запулены куда угодно).
Оно и для текущего дотнета с ShadowCopyFiles в домене актуально, но встречается гораздо реже.
Здравствуйте, Vladek, Вы писали:
K>>Выбрал. А студия, работая под 64-битной вендой, нарыгала мне 32-битную шнягу! В результате прога не смогла загрузить 64-битную DLL-ю (стороннюю).
V>Раз зависимости имеют привязку к архитектуре платформы, то надо выбирать конкретную архитектуру. Для этого тебе и предлагают выбор.
Я и спрашиваю, а какой тогда вообще смысл в VM??? Только чтобы MS похвалилась тысячей языков? VM — это и есть АБСТРАКЦИЯ НАД ВСЕМ. Если мы сильно терям в скорости, то и получить за это мы должны полную независимость: написал код — и ВООБЩЕ НИКОГДА не париться о том, где и как он будет работать и кого вызывать. Это не моё дело, что криворукие индусы напилили в венде — сами написали — сами пусть и расхлёбывают, а не вешают СВОИ ПРОБЛЕМЫ НА НАС.
Здравствуйте, LaptevVV, Вы писали:
LVV>Только в результате трансляции с студии мы все равно имеем исполняемый файл, который загружается загрузчиком оси, и начинает работать.
Неужели это единственное решение, которое пришло вам в голову? А как же *.class файлы в джабе? Им ВНЕЗАПНО не надо быть ни исполняемым кодом, ни даже быть в PE-формате. Чудеса, да?
Здравствуйте, consign, Вы писали:
C>Здравствуйте, Kolesiki, Вы писали:
K>>Итак, вопрос капсом выше.
C>Там вся реальная разница — это флажок у экзешника "в каком режиме запускать". Байткод абсолютно одинаковый.
С позиции землеройки — да. Чуть выше на уровень и опять вопрос: зачем мне ДАЖЕ ОДИН БИТ, если моя виртуальная машина обязана исполнять абстрактный код?
Давайте, заведите опять шарманку про 32/64-битные DLL... и я опять спрошу: а если это Arduino? Linux? Эльбрус? Какое мне вообще дело, даже если там 13-битный ЦПУ??
Здравствуйте, Kolesiki, Вы писали:
Еще она вещь, это использование Интеропа. Например для .Net Core SqlClient используются нативные библиотеки для каждой оси.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Tom, Вы писали:
Tom>Этот переключатель просто выставляет флаг в заголовке просто для того что бы сделать невозможным запуск вашего бинарника не не поддерживаемой системе. Почему она может быть не поддерживаемой — куча вариантов на самом деле
Искать отмазы костылям (а на самом деле глупости и лени) — можно всегда и везде. Почему жабовским *.class'ам не нужны битности, объясните?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Kolesiki, Вы писали: K>>>>Вот это-то и смешно! Откуда я знаю, в какой системе будет запущено приложение? EP>>>Такое что в x64 системе может работать x32 код. И что лучше для твоего конкретного приложения среда может и не знать K>>Какое дело байткоду какая битность у DLL??? Кто вообще сказал, что это будет виндовая библиотека?
EP>В смысле "будет"? Она есть, и её надо использовать, и для этого нужен x32 процесс.
А какое отношение это имеет к байткоду? Ну да, есть говновенда на костылях и изоленте, где ничего не работает, если не закостылить правильные переходники между 32/64. Скажите, вы для этого учились 6 лет паттернам и алгоритмам? Чтобы выйти в реал и заниматься этим навозным копанием? Я считаю, в программинге есть куда более важные задачи и это была прямая обязанность .NET-клепателей — сделать бесшовную интеграцию VM и окружения.
EP>Целевая платформа .NET приложений обычно заранее известна.
Ерунду не пишите. Я пишу код, где он будет исполняться — полностью ЗАВИСИТ ОТ ЮЗЕРА.
K>>2. VM, созданная специально для этой ОС, знает об окружении всё: битность, объём памяти, оборудование, способы линковки и т.п. И ей командуют "запусти этот шмот байткода".
EP>Она не знает что лучше для конкретного приложения — x32 или x64.
Да потому что нет никакой разницы! У 99% приложений вообще можно "положить на битность". А если уж она так важна, зачем тогда лезть в .NET? Там, где архитектура/скорость начинает играть роль, там нет места для VM.
EP>Именно байт-кода? Или одного значения/флажка рядом с этим байт-кодом?
Не имеет значения, на выходе всё равно получишь жёстко ориентированный на битность код.
K>>Реальное железо — причём тут оно? EP>При том что на нём в итоге и работает код, а не в сферическом вакууме, и у которого есть вполне осязаемые ограничения
Опять отсылаю к значению слова "виртуальный" в понятии VM.
Здравствуйте, Kolesiki, Вы писали:
K>Опять отсылаю к значению слова "виртуальный" в понятии VM.
Простите, а причем вообще VM? Вы же тему про .NET вроде начинали, не?
LVV>>Только в результате трансляции с студии мы все равно имеем исполняемый файл, который загружается загрузчиком оси, и начинает работать. K>Неужели это единственное решение, которое пришло вам в голову? А как же *.class файлы в джабе? Им ВНЕЗАПНО не надо быть ни исполняемым кодом, ни даже быть в PE-формате. Чудеса, да?
Мы не про Яву разговариваем.
В Яве интерпретатор можно вызвать отдельно из командной строки, отдав ему скомпилированные классы.
В нет такое возможно?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Kolesiki, Вы писали:
K>Тогда зачем вообще связываться с байткодом, если ты заранее ограничиваешь бинарь той системой, под которую заточил??
По твоему скрину похоже, что ограничивать не обязательно, хотя можно, если так хочется разработчику.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, LaptevVV, Вы писали:
LVV>>>Только в результате трансляции с студии мы все равно имеем исполняемый файл, который загружается загрузчиком оси, и начинает работать. K>>Неужели это единственное решение, которое пришло вам в голову? А как же *.class файлы в джабе? Им ВНЕЗАПНО не надо быть ни исполняемым кодом, ни даже быть в PE-формате. Чудеса, да? LVV>Мы не про Яву разговариваем. LVV>В Яве интерпретатор можно вызвать отдельно из командной строки, отдав ему скомпилированные классы. LVV>В нет такое возможно?
В .Net все компилируется. Но можно использовать рефлексию
Здравствуйте, 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.
Здравствуйте, 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, ничего не доказывает и не опровергает. Любой язык можно компилировать или выполнять в виртуальной машине.
Здравствуйте, 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.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, LaptevVV, Вы писали:
LVV>>Только в результате трансляции с студии мы все равно имеем исполняемый файл, который загружается загрузчиком оси, и начинает работать.
K>Неужели это единственное решение, которое пришло вам в голову? А как же *.class файлы в джабе? Им ВНЕЗАПНО не надо быть ни исполняемым кодом, ни даже быть в PE-формате. Чудеса, да?
А ты из жабы сможешь вызвать LoadLibrary() -> GetProcAddress()->...?
Сколько приседаний тебе нужно будет сделать, чтобы подружить твой жабовский код с уже имеющимися нативными либами? Сколько приседаний тебе нужно будет сделать, чтобы работа с каким-нибудь Verctor3[][] была с приемлемой скоростью, и сможешь ли...?
Ты главное пойми: любое решение — набор компромиссов, тогда перестанешь к мелочам придираться.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, 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>Если мы сильно терям в скорости...
доказательства в студию!
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, 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 это всегда компромисс между скоростью запуска и качеством кодогенерации. Иначе будешь сутками собирать, как С++.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, Sinix, Вы писали:
S>>По ссылкам всё написано: термин "VM" тут не совсем подходит, т.к. стоит сделать шаг в сторону ngen-ом или .net native и внезапно VM в традиционном понимании куда-то пропадает и получается натягивание совы в стиле "браузеры — это VM!!!".
ARK>В общем, это пляски вокруг терминологии. Четкого формального определения, что такое VM, я не видел. Если предоставите — буду раз прочесть.
ARK>Согласно моему пониманию и определению в википедии, CLR вполне является VM. Как я понял, весь спор начался вокруг того, что в .NET входит как CLR, так и появившийся совсем недавно .NET Native, и, дескать, топикстартер выразился некорректно. Но что, разве непонятно, о чем говорил топикстартер, употребив выражение ".NET VM"? Непонятно, что он говорит о CLR, а .NET Native тут вообще ни при чем? Стоило разводить эту бодягу о терминологии?
Так самый смех заключается в том, что с NGEN и CLR не подходит пот терминалогию VM так как выполняется код под конкретную платформу.
Виртуальная машина (ВМ, от англ. virtual machine) — программная и/или аппаратная система, эмулирующая аппаратное обеспечение некоторой платформы (target — целевая, или гостевая платформа) и исполняющая программы для target-платформы на host-платформе (host — хост-платформа, платформа-хозяин) или виртуализирующая некоторую платформу и создающая на ней среды, изолирующие друг от друга программы и даже операционные системы (см.: песочница); также спецификация некоторой вычислительной среды (например: «виртуальная машина языка программирования Си»).
Ну под это описание даже CLR с JIT компиляцией не подходит.
Хорошо есть описание
Виртуальная машина исполняет некоторый машинно-независимый код (например, байт-код, шитый код, p-код) или машинный код реального процессора.
Так при NGEN выполняется код под существующий процессор. Да CLR может загружать сборки и компилировать их. Но если приложение не использует рефлексиюс неизвестными типами, то и дополнительной JIT компиляции не происходит.
Так, что выражение .Net это VM ложно.
Виртуальные машины Java обычно содержат Интерпретатор байт-кода, однако, для повышения производительности во многих машинах также применяется JIT-компиляция часто исполняемых фрагментов байт-кода в машинный код.
В CLR весь код компилируется при первом обращении к классу.
А что касается зачем нужны разные платформы то ответ дан здесь
Здравствуйте, vl690001x, Вы писали:
K>>Итак, повторяю вопрос: причём тут биты в байткоде? V>32 бита позволяют создавать объекты в памяти не более 2 гигов. V>Часто нужно больше. Тогда надо принудительно указывать это.
Надо уточнить, что 2г это размер одного объекта. Т.е. например массивы в java индексируются int, т.е. создать массив byte с 3млрд элементов размером 3гб — проблема.
А создать Map<String, String> занимающий размер более 3гб — запросто.
Любопытно услышать пример задачи (да так чтобы "часто"), требующей объект такого размера.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
K>>>Итак, повторяю вопрос: причём тут биты в байткоде? V>>32 бита позволяют создавать объекты в памяти не более 2 гигов. V>>Часто нужно больше. Тогда надо принудительно указывать это. ·>Надо уточнить, что 2г это размер одного объекта. Т.е. например массивы в java индексируются int, т.е. создать массив byte с 3млрд элементов размером 3гб — проблема.
Речь шла про общее ограничение на доступную память в x32 (без хаков типа PAE), а не про какие-то ограничения индексов массивов в Java в x64.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
K>>>>Итак, повторяю вопрос: причём тут биты в байткоде? V>>>32 бита позволяют создавать объекты в памяти не более 2 гигов. V>>>Часто нужно больше. Тогда надо принудительно указывать это. EP>·>Надо уточнить, что 2г это размер одного объекта. Т.е. например массивы в java индексируются int, т.е. создать массив byte с 3млрд элементов размером 3гб — проблема. EP>Речь шла про общее ограничение на доступную память в x32 (без хаков типа PAE), а не про какие-то ограничения индексов массивов в Java в x64.
Видимо я что-то не понял, но речь про байткод была. Если пишешь на java, то запускается именно байткод, а там только ограничение связанное с типом индекса массива. Битность физической платформы роли не играет — битность указателя (ссылки) в байткоде не определена, "совершенно абстрактный байткод. Никаких битов, выравниваний и прочей чуши".
Т.е. ограничение 2млрд элементов (не байтов!) в jvm есть только на размеры массивов, а не на общий размер доступной памяти, т.е. с размером адресного пространства и битностью платформы напрямую не связано (связано лишь только существованием осмысленной реалзиации vm).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
K>>>>>Итак, повторяю вопрос: причём тут биты в байткоде? V>>>>32 бита позволяют создавать объекты в памяти не более 2 гигов. V>>>>Часто нужно больше. Тогда надо принудительно указывать это. EP>>·>Надо уточнить, что 2г это размер одного объекта. Т.е. например массивы в java индексируются int, т.е. создать массив byte с 3млрд элементов размером 3гб — проблема. EP>>Речь шла про общее ограничение на доступную память в x32 (без хаков типа PAE), а не про какие-то ограничения индексов массивов в Java в x64. ·>Видимо я что-то не понял, но речь про байткод была. Если пишешь на java, то запускается именно байткод, а там только ограничение связанное с типом индекса массива. Битность физической платформы роли не играет
Играет. На x32 больше 2-4 GiB откусить не получится (без хаков типа PAE).
·>- битность указателя (ссылки) в байткоде не определена,
Она и байткоде .NET не определена, как сказали выше. Меняется только соседствующий с байткодом флажок.
·>Т.е. ограничение 2млрд элементов (не байтов!) в jvm есть только на размеры массивов, а не на общий размер доступной памяти, т.е. с размером адресного пространства и битностью платформы напрямую не связано (связано лишь только существованием осмысленной реалзиации vm).
Ещё раз. Речь про ограничение адресного пространства в x32. Те ограничения Java о которых ты говоришь накладываются уже поверх ограничений адресного пространства — не создашь ты массив с 2мдрд int'ов на x32
А то что у Java проблема с созданием массива в 8млрд байтов (как элементов) на x64 — это ортогонально
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Речь шла про общее ограничение на доступную память в x32 (без хаков типа PAE), а не про какие-то ограничения индексов массивов в Java в x64. EP>·>Видимо я что-то не понял, но речь про байткод была. Если пишешь на java, то запускается именно байткод, а там только ограничение связанное с типом индекса массива. Битность физической платформы роли не играет EP>Играет. На x32 больше 2-4 GiB откусить не получится (без хаков типа PAE).
Понятно, но это не связано с байткодом.
EP>·>Т.е. ограничение 2млрд элементов (не байтов!) в jvm есть только на размеры массивов, а не на общий размер доступной памяти, т.е. с размером адресного пространства и битностью платформы напрямую не связано (связано лишь только существованием осмысленной реалзиации vm). EP>Ещё раз. Речь про ограничение адресного пространства в x32. Те ограничения Java о которых ты говоришь накладываются уже поверх ограничений адресного пространства — не создашь ты массив с 2мдрд int'ов на x32 EP>А то что у Java проблема с созданием массива в 8млрд байт на x64 — это ортогонально
При наличии поддержки в vm — создашь, теоретически ограничений нет. Хотя на практике, насколько я знаю, такой имплементации vm никто не делал, т.к. бессмысленно, проще взять 64-битное железо. А так я слыхал о реализациях jvm для 16 или даже 8-битных процов.
Были ещё такие проекты, которые позволяли запускать приложение в как бы distributed vm — т.е. код реально выполнялся на множестве машин, имея объединённое адресное пространство. Но не прижилось, как и все эти EE-всемогутеры, эти универсальные решения менее эффективны, чем архитектура хорошо заточенная под конкретную задачу.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Mr Bombastic, Вы писали:
EP>>Не пофиг например если идёт взаимодействие с native библиотеками MB>Ну так узнавай в своём управляемом коде, под какой процовой архитектурой и осью запущен, и подсасывай нужную native библиотеку. Я так делал на жаве, и jar-ка содержала актуальные на тот момент win32-x86, lin-x86, lin-amd64, osx-amd64, osx-ppc32 бинарнички-прокладки к нужным API оси
Речь о сторонних библиотеках, которые могут быть только под одну из архитектур.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, ·, Вы писали:
EP>>>Играет. На x32 больше 2-4 GiB откусить не получится (без хаков типа PAE). EP>·>Понятно, но это не связано с байткодом. EP>Это связано с тем во что транслируется байткод, собственно сабжевый флажок это и контролирует.
Так байткод может и не транслироваться, а тупо интерпретироваться. Асбтракция, и всё такое.
EP>>>А то что у Java проблема с созданием массива в 8млрд байт на x64 — это ортогонально EP>·>При наличии поддержки в vm — создашь, теоретически ограничений нет. EP>·>Хотя на практике, насколько я знаю, такой имплементации vm никто не делал, т.к. бессмысленно, проще взять 64-битное железо. А так я слыхал о реализациях jvm для 16 или даже 8-битных процов. EP>Ну да, я же говорю — без хаков. А с хаками да, можно — но там уже будет указатель не указатель, а некий синтезированный индекс, и соответствующие penalty и т.п.
Хаки эти никак на байткод не влияют, это только сложности в конкретной имплементации конкретной vm под конкретную платфрому.
С т.з. байткода есть только OOP (ordinary object pointer) и ничего не меняется. Скажем например можно включить Compressed Oops, когда указатель ВНЕЗАПНО становится не указатель... но всё работает как и раньше.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
EP>>·>Понятно, но это не связано с байткодом. EP>>Это связано с тем во что транслируется байткод, собственно сабжевый флажок это и контролирует. ·>Так байткод может и не транслироваться, а тупо интерпретироваться. Асбтракция, и всё такое.
Я не пойму что ты хочешь сказать, и как это всё относится к теме.
x86 код например тоже может интерпретироваться
EP>>Ну да, я же говорю — без хаков. А с хаками да, можно — но там уже будет указатель не указатель, а некий синтезированный индекс, и соответствующие penalty и т.п. ·>Хаки эти никак на байткод не влияют
А где влияют?
Насколько я понял из темы — влияние сабжевых ключей на байткод это лишь неверное предположение — так зачем постоянно кивать в эту сторону?
·>С т.з. байткода есть только OOP (ordinary object pointer) и ничего не меняется. Скажем например можно включить Compressed Oops, когда указатель ВНЕЗАПНО становится не указатель... но всё работает как и раньше.
В C++ скомпилированном в JS тоже под капотом получается ВНЕЗАПНО совсем не указатель. И дальше что?
Здравствуйте, Serginio1, Вы писали:
S>Так самый смех заключается в том, что с NGEN и CLR не подходит пот терминалогию VM так как выполняется код под конкретную платформу.
Это ничего не значит. "Виртуализировать некоторую платформу" можно любым способом, главное, что эта платформа (IL) в принципе есть. Остальное неважно — интерпретируется IL, компилируется или вычисляется вручную кучей китайцев в подвале.
S>В CLR весь код компилируется при первом обращении к классу.
После этого CLR можно отключать?
Правда после отключения мы захотели обратиться еще к одному классу и...
Здравствуйте, ·, Вы писали:
·>Все эти оптимизации того что "x64 может легко увеличить потребление ресурсов на ровном месте" реализуются на уровне JVM (например упомянутый Compressed Oops)
При этом добавляя дополнительные тормоза.
·>Наличие JNI и DLL-ек тоже не причина. System.loadLibrary просто выбирает подходящую нативную библиотеку под текущую платформу.
Речь о том, что нативные библиотеки могут быть только под одну платформу. Это уже несколько раз было озвучено выше
·>Байткод-то тут причём?
Байткод не причём — это ты сам придумал.
·>Это "Такое что в x64 системе может работать x32 код. И что лучше для твоего конкретного приложения среда может и не знать" решается тупо тем под какой JVM запускаешь — x32 или x64 — можешь иметь обе одновременно.
Это может легко решить разработчик на своей стороне, с помощью сабжевого ключика
EP>>x86 код например тоже может интерпретироваться ·>Понятно, но x86 это не байткод виртуальной машины, а машинный код конкретного железа.
И что из этого? К чему вообще эти майсы про интерпретацию?
EP>>·>С т.з. байткода есть только OOP (ordinary object pointer) и ничего не меняется. Скажем например можно включить Compressed Oops, когда указатель ВНЕЗАПНО становится не указатель... но всё работает как и раньше. EP>>В C++ скомпилированном в JS тоже под капотом получается ВНЕЗАПНО совсем не указатель. И дальше что? ·>В С++ понятие платформы — в стандарте языка, зачем это же в тащить в байткод, который собственно и создавался для того, чтобы обеспечить платформонезависимость?
Давай пруфлинк на то что это есть в байткоде, ты уже несколько раз это сказал на протяжении последних сообщений.
EP>·>Все эти оптимизации того что "x64 может легко увеличить потребление ресурсов на ровном месте" реализуются на уровне JVM (например упомянутый Compressed Oops) EP>При этом добавляя дополнительные тормоза.
А ссылки на факты есть?
EP>·>Наличие JNI и DLL-ек тоже не причина. System.loadLibrary просто выбирает подходящую нативную библиотеку под текущую платформу. EP>Речь о том, что нативные библиотеки могут быть только под одну платформу. Это уже несколько раз было озвучено выше
С одним и тем же байткод-приложением можно тупо поставлять нативные библиотеки под все платформы. Пишешь в коде System.loadLibrary("libfoo") и оно подрузит соответствующую dll/so текущей запущенной jvm.
EP>·>Байткод-то тут причём? EP>Байткод не причём — это ты сам придумал.
И зачем тогда эти нативные библиотеки вообще в этом топике помянуты?
EP>·>Это "Такое что в x64 системе может работать x32 код. И что лучше для твоего конкретного приложения среда может и не знать" решается тупо тем под какой JVM запускаешь — x32 или x64 — можешь иметь обе одновременно. EP>Это может легко решить разработчик на своей стороне, с помощью сабжевого ключика
Зачем ему это решать?
EP>>>x86 код например тоже может интерпретироваться EP>·>Понятно, но x86 это не байткод виртуальной машины, а машинный код конкретного железа. EP>И что из этого? К чему вообще эти майсы про интерпретацию?
Байткод исполняется на виртуальой машине, притом как интерпретацией, так и jit-компиляцией. А вот к чему вообще тут x86 интерпретция?
EP>>>В C++ скомпилированном в JS тоже под капотом получается ВНЕЗАПНО совсем не указатель. И дальше что? EP>·>В С++ понятие платформы — в стандарте языка, зачем это же в тащить в байткод, который собственно и создавался для того, чтобы обеспечить платформонезависимость? EP>Давай пруфлинк на то что это есть в байткоде, ты уже несколько раз это сказал на протяжении последних сообщений.
Что "это"? Что байт код для платформонезависимости? Да пожалуйста: https://en.wikipedia.org/wiki/Common_Intermediate_Language
CIL is a CPU- and platform-independent instruction set that can be executed in any environment supporting the Common Language Infrastructure,[3] such as the .NET runtime on Windows, or the cross-platform Mono runtime. In theory, this eliminates the need to distribute different executable files for different platforms and CPU types
И ВНЕЗАПНО — некий CIL код может работать исключительно на 64 битах. Упс.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Философ, Вы писали:
K>>Если мы сильно терям в скорости... Ф>доказательства в студию!
Если сравнивать .net код и аналогичный приличный нативный (типа C++), то у .net есть огромное количество причин для тормозов. Но действительно далеко не все они связаны с генерацией байт-кода. Однако и такие тоже имеются. К примеру отсутствие автовекторизации циклов и агрессивного инлайна является как раз следствием применения байт-кода, т.к. jit-компилятор не способен успевать подобные оптимизации.
Единственно стоит заметить, что это проблемы любого байт-кода, а не только .net. И в борьбе с этим пожалуй дальше всех продвинулась Java, благодаря их escape-анализу. Однако это всё равно всё полумеры, не решающие базовую проблему.
На мой взгляд реальным универсальным решением была бы компиляция приложения при установке не пользовательскую машину. Т.е. разработчики генерируют байт-код (скажем какой-нибудь там llvm), а при инсталляции он превращается (с полноценной оптимизацией) в нормальный нативный.
Это если зачем-то упороться на идее "единый бинарник для всех". Не вижу в ней особых преимуществ, по сравнению с идеей "единый исходный код для всех платформ, с компиляцией разных бинарников под каждую". Точнее есть куча ограничений (можем нормально пользоваться только средствами предлагаемого фреймворка, а до системных средств не дотянуться) без единого существенного плюса.
Здравствуйте, ·, Вы писали:
EP>>·>Все эти оптимизации того что "x64 может легко увеличить потребление ресурсов на ровном месте" реализуются на уровне JVM (например упомянутый Compressed Oops) EP>>При этом добавляя дополнительные тормоза. ·>А ссылки на факты есть?
Факт чего? Того что лишние манипуляции с каждым указателем будут давать дополнительные тормоза?
EP>>·>Наличие JNI и DLL-ек тоже не причина. System.loadLibrary просто выбирает подходящую нативную библиотеку под текущую платформу. EP>>Речь о том, что нативные библиотеки могут быть только под одну платформу. Это уже несколько раз было озвучено выше ·>С одним и тем же байткод-приложением можно тупо поставлять нативные библиотеки под все платформы. Пишешь в коде System.loadLibrary("libfoo") и оно подрузит соответствующую dll/so текущей запущенной jvm.
Ты читать не умеешь?
EP>>Речь о том, что нативные библиотеки могут быть только под одну платформу. Это уже несколько раз было озвучено выше
Например есть только x32 библиотека, купленная у стороннего поставщика N лет назад, со своей работой справляется на ура.
EP>>·>Байткод-то тут причём? EP>>Байткод не причём — это ты сам придумал. ·>И зачем тогда эти нативные библиотеки вообще в этом топике помянуты?
При том что сабжевые опции помогают разрулить ситуации когда например есть только x32 библиотека. Сам байт-код при этом не меняется, а меняется только соседний ключик.
EP>>·>Это "Такое что в x64 системе может работать x32 код. И что лучше для твоего конкретного приложения среда может и не знать" решается тупо тем под какой JVM запускаешь — x32 или x64 — можешь иметь обе одновременно. EP>>Это может легко решить разработчик на своей стороне, с помощью сабжевого ключика ·>Зачем ему это решать?
Чтобы пользователь бы доволен — запустил .exe и всё заработало
EP>>>>x86 код например тоже может интерпретироваться EP>>·>Понятно, но x86 это не байткод виртуальной машины, а машинный код конкретного железа. EP>>И что из этого? К чему вообще эти майсы про интерпретацию? ·>Байткод исполняется на виртуальой машине, притом как интерпретацией, так и jit-компиляцией.
А ещё бывает на реальной — и чо?
·>А вот к чему вообще тут x86 интерпретция?
Ты к чему-то непонятному сказал что байткод может быть интерпретирован — ОК — x86 тоже может быть — что сказать-то хотел?
EP>>>>В C++ скомпилированном в JS тоже под капотом получается ВНЕЗАПНО совсем не указатель. И дальше что? EP>>·>В С++ понятие платформы — в стандарте языка, зачем это же в тащить в байткод, который собственно и создавался для того, чтобы обеспечить платформонезависимость? EP>>Давай пруфлинк на то что это есть в байткоде, ты уже несколько раз это сказал на протяжении последних сообщений. ·>Что "это"? Что байт код для платформонезависимости?
Ты говоришь "зачем это же в тащить в байткод" — покажи как сабжевые опции влияют именно на байткод.
·>И ВНЕЗАПНО — некий CIL код может работать исключительно на 64 битах. Упс.
Так же как и Java код напрямую использующий x64-only библиотеки
Здравствуйте, alexzzzz, Вы писали:
EP>>>Насколько я понял из темы — влияние сабжевых ключей на байткод это лишь неверное предположение — так зачем постоянно кивать в эту сторону? A>·>Тут скорее всего проблема в том, что эти ключи вообще существуют. A>Ключи существуют, чтобы решать конкретную проблему, которая Яве естественно тоже есть, но решает её там конечный пользователь самостоятельно. A>http://stackoverflow.com/questions/9757456/java-native-interface-32-bit-dll-on-64-bit-system
Ну понятно, раз нет нативных бинарников под данную платформу — их надо либо поставить, либо запустить под 32 бита. Зачем это делать программисту во время билда CIL-сборок?
A>·>Наличие JNI и DLL-ек тоже не причина. System.loadLibrary просто выбирает подходящую нативную библиотеку под текущую платформу. Байткод-то тут причём? A>Ну вот нет у тебя нативной библиотеки подо все платформы. Автор библиотеки скомпилировал её в 1995 году только под x86, а про x64 и x128 не догадался. Исходники стёр, сам застрелился, бекапы сгорели.
Ну запусти под 32 битной vm. Делов-то. А если таки есть? Что делать с x86 CIL-сборкой, если автор застрелился?
A>Но теперь тебе кровь из носу нужно, чтобы твоя программа могла загрузить эту нативную x86-библиотеку в ОС любой разрядности. Если на 64-разрядной ОС твоя программа будет автоматически запускаться как 64-разрядный процесс, как и куда она будет подгружать эту 32-разрядную библиотеку? Никак и никуда. Нужно будет параллельно поднять вспомогательный 32-разрядный процесс, загрузить библиотеку в него и организовать какую-нибудь связь между двумя полученными процессами. A>Зачем такой геморрой? Достаточно в своей программе выставить флажок на запуск её в 32-разрядном виде всегда, независимо от разрядности ОС.
Не надо такой гемморой. Ведь на ОС запускается не сама программа, а vm. Просто запусти эту же программу под 32-битной VM. Ведь байт-код для этого и придумывали, чтобы можно было менять VM, используя те же bytecode-бинарики.
A>·>Понятно, но x86 это не байткод виртуальной машины, а машинный код конкретного железа. Зачем микрософт запихнула детали имплементации платформы на уроветь компилятора исходников — один Бг знает. A>Был бы в Net дополнительно линковщик, запихнули бы в него. Кто пишет на диск финальный .exe, в того и пихать.
А, понятно откуда изолента торчит — запуск CIL-кода примотано к нативному.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Философ, Вы писали:
K>>>Если мы сильно терям в скорости... Ф>>доказательства в студию!
_>Если сравнивать .net код и аналогичный приличный нативный (типа C++), то у .net есть огромное количество причин для тормозов. Но действительно далеко не все они связаны с генерацией байт-кода. Однако и такие тоже имеются. К примеру отсутствие автовекторизации циклов и агрессивного инлайна является как раз следствием применения байт-кода, т.к. jit-компилятор не способен успевать подобные оптимизации.
_>Единственно стоит заметить, что это проблемы любого байт-кода, а не только .net. И в борьбе с этим пожалуй дальше всех продвинулась Java, благодаря их escape-анализу. Однако это всё равно всё полумеры, не решающие базовую проблему.
Это проблемы JIT'ера, а не IL.
_>На мой взгляд реальным универсальным решением была бы компиляция приложения при установке не пользовательскую машину. Т.е. разработчики генерируют байт-код (скажем какой-нибудь там llvm), а при инсталляции он превращается (с полноценной оптимизацией) в нормальный нативный.
ngen?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Kolesiki, Вы писали:
K>>То, что MS всегда найдёт самую тухлейшую отмазу "почему здесь торчит изолента" — это я знаю, мне нужен инженерный ответ: "ЗАЧЕМ БАЙТКОДУ БИТНОСТЬ?".
EP>Предположу что это битность не байткода, а предпочитаемой цели. На x32/x64 разный объём доступной памяти, и разные размеры указателей (что влияет на потребление и в следствии скорость). Плюс в x64 процесс нельзя загрузить x32 dll, которая может быть сторонней.
Да хрен там.
Я так мелкую утилиту собрал для х64 (стоит по умолчанию, я на на шарпе пишу крайне редко), так эта гадина под Вынь 7 х86 не запустилась, проорав "я не х86".
Какая к черту разница какая битность в .НЕТе
Хотя есть подозрение что там только заголовок файла разный.
Здравствуйте, wraithik, Вы писали:
W>Да хрен там. W>Я так мелкую утилиту собрал для х64 (стоит по умолчанию, я на на шарпе пишу крайне редко), так эта гадина под Вынь 7 х86 не запустилась, проорав "я не х86". W>Какая к черту разница какая битность в .НЕТе
W>Хотя есть подозрение что там только заголовок файла разный.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, Serginio1, Вы писали:
S>>Так самый смех заключается в том, что с NGEN и CLR не подходит пот терминалогию VM так как выполняется код под конкретную платформу.
ARK>Это ничего не значит. "Виртуализировать некоторую платформу" можно любым способом, главное, что эта платформа (IL) в принципе есть. Остальное неважно — интерпретируется IL, компилируется или вычисляется вручную кучей китайцев в подвале.
Ну дык под это определение подходит и C++. Он тоже кроссплатформенный и компилируется. Ничем IL от C++ не отличается. Просто он более низкоуровневый.
S>>В CLR весь код компилируется при первом обращении к классу.
ARK>После этого CLR можно отключать? ARK>Правда после отключения мы захотели обратиться еще к одному классу и...
Ну скомпилировали через NGEN и JIT компиляцию можно отключать (если конечно нет рефлексии к неподгруженным сборкам)
CLR это не только JIT но и менеджер памяти и сборка мусора. Аналог CLR только оптимизированный есть и в .Net Native.
и солнце б утром не вставало, когда бы не было меня
S>> Одна из основных причина это использование через интероп нативного кода
W>Уроды. Вся фишка .НЕТа в том что ему по идее пофиг где исполняться, если есть необходимый фреймворк.
W>Собирал я программку на Дельфе или С++ вопросов бы не было.
Я когда на Win CE программировал, то там был голимый InterOP.
Но если ты не используешь Интероп к библиотекам которые есть только для одной платформы, то можешь все собирать под AnyCPU. Я так и поступаю.
и солнце б утром не вставало, когда бы не было меня
·>Собственно напрямую. У майкрософта "здесь торчит изолента", не потому что байткод, а потому что в майкрософте фигню наиндусокодили с сабжем. В яве этого бреда нет и не надо. Битность таргет-платформы JVM вообще никак не относится к тому как компилится исходный код. Почему компилятору нужно знать во что транслируется байткод? Байткод при желании можно и в рантайме генерить, без всяких компиляторов.
Значит любая jvm программа будет запускать дольше аналого под .net.
S>>> Одна из основных причина это использование через интероп нативного кода
W>>Уроды. Вся фишка .НЕТа в том что ему по идее пофиг где исполняться, если есть необходимый фреймворк.
W>>Собирал я программку на Дельфе или С++ вопросов бы не было. S> Я когда на Win CE программировал, то там был голимый InterOP. S>Но если ты не используешь Интероп к библиотекам которые есть только для одной платформы, то можешь все собирать под AnyCPU. Я так и поступаю.
Пасиб. Хорошо на 1Ске, там пофиг на ЦПУ
Если бы я юзал где выход в неуправляемый код, то мне сразу понятно зачем ЦПУ указывать. А так они уроды.
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, Vladek, Вы писали:
K>>>Выбрал. А студия, работая под 64-битной вендой, нарыгала мне 32-битную шнягу! В результате прога не смогла загрузить 64-битную DLL-ю (стороннюю).
V>>Раз зависимости имеют привязку к архитектуре платформы, то надо выбирать конкретную архитектуру. Для этого тебе и предлагают выбор.
K>Я и спрашиваю, а какой тогда вообще смысл в VM??? Только чтобы MS похвалилась тысячей языков? VM — это и есть АБСТРАКЦИЯ НАД ВСЕМ. Если мы сильно терям в скорости, то и получить за это мы должны полную независимость: написал код — и ВООБЩЕ НИКОГДА не париться о том, где и как он будет работать и кого вызывать. Это не моё дело, что криворукие индусы напилили в венде — сами написали — сами пусть и расхлёбывают, а не вешают СВОИ ПРОБЛЕМЫ НА НАС.
Ну ты же сам добавил зависимость какую-то, которая работает только вне виртуальной машины. Убери её и будет тебе полная виртуальность.
Здравствуйте, wraithik, Вы писали:
WS>> Я когда на Win CE программировал, то там был голимый InterOP. S>>Но если ты не используешь Интероп к библиотекам которые есть только для одной платформы, то можешь все собирать под AnyCPU. Я так и поступаю.
W>Пасиб. Хорошо на 1Ске, там пофиг на ЦПУ
Нет там давно уже не пофиг. Нужно делать Native ВК и под 32 и 64 разрядные платформы.
Приходится изворачиваться так https://habrahabr.ru/post/304542/
А CoreClr для каждой платформы своя. Другое дело, что свои библиотеки я использую под AnyCPU
W>Если бы я юзал где выход в неуправляемый код, то мне сразу понятно зачем ЦПУ указывать. А так они уроды.
Так не указывай. Указывай AnyCPU который по умолчанию.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, wraithik, Вы писали:
W>Я так мелкую утилиту собрал для х64 (стоит по умолчанию, я на на шарпе пишу крайне редко), так эта гадина под Вынь 7 х86 не запустилась, проорав "я не х86". W>Какая к черту разница какая битность в .НЕТе
A>·>Ну понятно, раз нет нативных бинарников под данную платформу — их надо либо поставить, либо запустить под 32 бита. Зачем это делать программисту во время билда CIL-сборок? A>Это программисту понятно, что у него есть, а что у него нет. Пользователю это непонятно. У пользователя всё просто должно работать. Если не работает, это проблема не пользователя, а программиста. A>Стоит у пользователя 64-разрядная Ява, он программу запускает, а она не запускается. Ему что, обязательно знать, что проблема из-за того, что Явы, оказывается, бывают разные? Ну допустим так, но 64 ведь лучше, чем 32. Должно же работать. Или нужно 86-разрядную? Да он даже не знает, что такое Ява. Остров вроде, а может мотоцикл.
У программиста (возможно у другого) проблема будет только лишь собрать дистрибутив под соответствующую платформу, даже возможно с bundled VM, ну чтобы пользователю не надо было, как обычно, трахаться с установкой правильной версии .net-фреймворка, а затем развлекаться с Microsoft .NET Framework Repair® Tool™.
Но это сборка дистрибутива, а не компиляция шарп-кода. Каждому шагу процесса соответствующие вопросы, а не текучие абстракции.
A>При таком отношении к пользователю не удивительно, что Ява на десктопах начинается и заканчивается на Майнкрафте.
Обилие шарп-софта на десктопе я наблюдаю только в корпоративной среде, где всё и так ставят админы.
A>>>Ну вот нет у тебя нативной библиотеки подо все платформы. Автор библиотеки скомпилировал её в 1995 году только под x86, а про x64 и x128 не догадался. Исходники стёр, сам застрелился, бекапы сгорели. A>·>Ну запусти под 32 битной vm. Делов-то. А если таки есть? A>А я знаю, есть или нет? Я пользователь. Ты ж программист, давай, я тебе в субботу позвоню, а ты мне по телефону всё починишь? В понедельник утром уже сдавать отчёт, а ничего не работает. Что конкретно не работает? Ничего не работает.
Такому пользователю даёшь .zip или setup.exe, который распаковывает всё что надо, включая нативные либы и jvm, и можно запускать приложение.
A>·> Что делать с x86 CIL-сборкой, если автор застрелился? A>Забавный факт: программисты на C++ умирают чаще, чем программисты на C#.
?
A>Конечному пользователю вообще-то пофиг. X86 у него и так запустится. Если ты программист, и попалась управляемая библиотека x86-only, то варианта два: A>1. Либо она под x64 в принципе неработоспособна, потому что, например, в свою очередь зависит от x86-only нативной библиотеки. Тогда делаешь свою программу тоже x86-only, другого варианта всё равно нет.
А если попалась библиотека x86+x64, но не ARM и Itanium? Что делать?
A>2. Либо ограничение, не знаю как, вдруг возникло по ошибке. Если ты в этом уверен, убираешь ограничивающий флажок ручками взад и пользуешься.
Убираешь где?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
EP>>>>Речь о том, что нативные библиотеки могут быть только под одну платформу. Это уже несколько раз было озвучено выше
EP>>Например есть только x32 библиотека, купленная у стороннего поставщика N лет назад, со своей работой справляется на ура. ·>Ну запускай своё приложение на x32 vm. В чём проблема-то?
Этот флажок и есть подсказка запускать приложение на x32 VM, коей в грубом приближении и является wow64 подсистема
Как много веселых ребят, и все делают велосипед...
Здравствуйте, alexzzzz, Вы писали:
A>·>У программиста (возможно у другого) проблема будет только лишь собрать дистрибутив под соответствующую платформу, даже возможно с bundled VM, ну чтобы пользователю не надо было, как обычно, трахаться с установкой правильной версии .net-фреймворка, а затем развлекаться с Microsoft .NET Framework Repair® Tool™. A>·>Но это сборка дистрибутива, а не компиляция шарп-кода. Каждому шагу процесса соответствующие вопросы, а не текучие абстракции. A>Программу с правильно установленным флажком достаточно просто скачать и запустить. Щёлкнуть два раза мышкой по .exe, и он весело запустится. Если программисту хочется потрахаться, он всегда найдёт где.
Неправда. Надо ещё откуда-то .net framework взять. Притом правильной версии и битности. И чтобы он поставился нормально. И чтобы не поломался случайно.
A>>>При таком отношении к пользователю не удивительно, что Ява на десктопах начинается и заканчивается на Майнкрафте. A>·>Обилие шарп-софта на десктопе я наблюдаю только в корпоративной среде, где всё и так ставят админы. A>Админ тоже человек и терпеть не может программы, которые хотят странного. Когда есть выбор, предпочитает ту, которая минимально парит ему мозг. Если бы программисты знали, что админы о них думают (иногда вслух)...
Обычно java-based программы ставятся распаковкой архива. Куда уж проще...
А наличие Microsoft .NET Framework Repair® Tool™ ни на что не намекает?
A>>>А я знаю, есть или нет? Я пользователь. Ты ж программист, давай, я тебе в субботу позвоню, а ты мне по телефону всё починишь? В понедельник утром уже сдавать отчёт, а ничего не работает. Что конкретно не работает? Ничего не работает. A>·>Такому пользователю даёшь .zip или setup.exe, который распаковывает всё что надо, включая нативные либы и jvm, и можно запускать приложение. A>Просто выставить x86 недостойно или другой работы мало? Или раз в Яве этого нет, то ненужно?
Это бессмысленно. Скажем в IDEA можно во время установки выбрать галочками какие ярлыки запуска помещать на рабочий стол — x84, x64 или оба. Решение о таргет-платформе должно приниматься во время деплоймента, а не во время компиляции.
A>>>1. Либо она под x64 в принципе неработоспособна, потому что, например, в свою очередь зависит от x86-only нативной библиотеки. Тогда делаешь свою программу тоже x86-only, другого варианта всё равно нет. A>·>А если попалась библиотека x86+x64, но не ARM и Itanium? Что делать? A>Во-первых, так не бывает.
Почему не бывает? Программ которые пишут под x86/x64 — полно, а вот ARM/Itanium — экзотика.
A>Во-вторых, в этом пункте рассмотрена ситуация, когда ограничение выставлено осознанно разработчиком библиотеки ― ему виднее, где она работоспособна, а где нет. Если считаешь, что знаешь это лучше разработчика, переходишь к пункту 2.
Вот разработчик видит: "эта нужная мне либа имеет .dll-ки под Intel-ы 32 и 64. Но ARM не умеет". Как разработчик поставит флажок?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ononim, Вы писали:
O>·>Ну запускай своё приложение на x32 vm. В чём проблема-то? O>Этот флажок и есть подсказка запускать приложение на x32 VM, коей в грубом приближении и является wow64 подсистема
Это понятно. Непонятно почему этот флажок требуется на этапе компиляции проекта, а не его дистрибуции.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, fddima, Вы писали:
F>·>Ну да, это я уже понял откуда свисает изолента. Они примотали потенциально платформонезависимый артефакт (CIL-сборку) к платформозависимому PE-формату. Ну и получилось что получилось... F> И получилось отлично: .NET процессы видны в таск менеджере со своими нормальными именами безовсяких приседаний, GetModuleHandle(NULL) и прочий API работает. В добавок AnyCPU никто не отменял, чего по три круга ходить-то.
Отлично для платформо-зависимого решения, к платформо-независимым языкам это не подходит. Где там ваш GetModuleHandle на non-windows платформах?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Слава, Вы писали:
С>Реплика в сторону — однако же, что такое трамблёр, шрус, дром.ру, курс доллара и соединение металлопластика "под пресс" — этот пользователь таки выучил. Иногда после того, как лишился изрядного количества денег и нервов. И про яву выучит, не бином Ньютона.
Моя жена из этого только про курс доллара знает, и то, чисто умозрительно. Сам я остальные слова знаю, но в основном как тяжелое легаси, в практической области не сталкиваюсь уже лет 10, а потенциально сам могу только с шрусом столкнуться в качестве покупки, как его приделывать разбираться не собираюсь.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
O>>·>Ну понятно, раз нет нативных бинарников под данную платформу — их надо либо поставить, либо запустить под 32 бита. Зачем это делать программисту во время билда CIL-сборок? O>>Потому что CIL сборка использует в качестве контейнера PE формат. У этого контейнера есть опция — запускать в 32 битах или 64 битах. Используя циркуль, буханку хлеба и hiew можно этот флажок поменять в уже собранном ехе-шнике, но зачем? ·>Ну да, это я уже понял откуда свисает изолента. Они примотали потенциально платформонезависимый артефакт (CIL-сборку) к платформозависимому PE-формату. Ну и получилось что получилось...
Ну, на самом деле тот флажок в РЕ заголовке — архитектура процессора, там помимо интела 32/64 что угодно может быть, так что примотать могли и по другому, прописав туда процессор некий пусть будет CIL_MACHINE.
Но дело тут такое — х64 винда с дотнетом это на некотором уровне приближения две винды с двумя дотнетами — 32хбитная винда с 32хбитным дотнетом и 64 битная винда с 64хбитным дотнетом. И как тут выбрать на чем работать?
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ·, Вы писали:
F>>·>Ну да, это я уже понял откуда свисает изолента. Они примотали потенциально платформонезависимый артефакт (CIL-сборку) к платформозависимому PE-формату. Ну и получилось что получилось... F>> И получилось отлично: .NET процессы видны в таск менеджере со своими нормальными именами безовсяких приседаний, GetModuleHandle(NULL) и прочий API работает. В добавок AnyCPU никто не отменял, чего по три круга ходить-то. ·>Отлично для платформо-зависимого решения, к платформо-независимым языкам это не подходит. Где там ваш GetModuleHandle на non-windows платформах?
Язык (C#) и так платформо-независим. А .NET кроме как на виндовс и нет нигде. Остальные же кушают те же самые модули как им нравится, в mono даже есть некоторые расширения навроде dllmap.
Или полагаешь, что если платформонезависимый артефакт прикрутить к "платформонезависимому" эльфу то будет лучше? Или если прикрутить в свой формат — будет лучше? Чё-то в рамках .NET и Виндовс в частности выигрыша вообще не видно. А всякие там нативные лаунчеры вокруг дотнета и так никто не мешает делать, но нужно это очень редко.
Здравствуйте, ·, Вы писали:
A>>Программу с правильно установленным флажком достаточно просто скачать и запустить. Щёлкнуть два раза мышкой по .exe, и он весело запустится. Если программисту хочется потрахаться, он всегда найдёт где. ·>Неправда. Надо ещё откуда-то .net framework взять. Притом правильной версии и битности. И чтобы он поставился нормально. И чтобы не поломался случайно.
Инсталлятор, да, лучше приложить, хотя Net Framework часто уже есть. С правильной битностью в Net Framework проще ― инсталляторы ставят сразу оба варианта, где это практически возможно.
·>Обычно java-based программы ставятся распаковкой архива. Куда уж проще...
С дополнительным exe-шничком, который собственно и запускает программу на правильной версии Явы, если она есть. Дополнительных exe-шничков в Net тоже можно налепить, была бы необходимость.
·>А наличие Microsoft .NET Framework Repair® Tool™ ни на что не намекает?
Не-а. Ещё не видел сломанного Net Framework, кроме трёх компьютеров, на которых вирус Expiro прошёлся по всем exe-шникам. Если бы Net Framework там реально использовался, Repair Tool был бы полезен, наверное.
У меня дома долго висела Java 8 Update 73 (64-bit), которая ни работать не хотела, ни удаляться. Сейчас про неё вспомнил, пришлось грохать папку и чистить следы вручную. Java Repair Tool не нашёл.
A>>Просто выставить x86 недостойно или другой работы мало? Или раз в Яве этого нет, то ненужно? ·>Это бессмысленно. Скажем в IDEA можно во время установки выбрать галочками какие ярлыки запуска помещать на рабочий стол — x84, x64 или оба.
Тут раз двадцать уже написали, что флажок нужен/полезен только для тех случаев, когда у программы имеется жёсткая зависимость от какого-либо компонента, существующего только под одну конкретную платформу. Ну не работает твоя программа в режиме x64. Ей не нужно делать специальных ярлычков. Ставишь platform:x86 ― и теперь она знает сама как ей правильно запускаться на 64.
·>Решение о таргет-платформе должно приниматься во время деплоймента, а не во время компиляции.
Он НЕ требуется на этапе компиляции проекта. Можешь выставить потом, когда захочешь, если надо.
A>>·>А если попалась библиотека x86+x64, но не ARM и Itanium? Что делать? A>>Во-первых, так не бывает. ·>Почему не бывает? Программ которые пишут под x86/x64 — полно, а вот ARM/Itanium — экзотика. A>>Во-вторых, в этом пункте рассмотрена ситуация, когда ограничение выставлено осознанно разработчиком библиотеки ― ему виднее, где она работоспособна, а где нет. Если считаешь, что знаешь это лучше разработчика, переходишь к пункту 2. ·>Вот разработчик видит: "эта нужная мне либа имеет .dll-ки под Intel-ы 32 и 64. Но ARM не умеет". Как разработчик поставит флажок?
Конкретно такой комбинации не бывает, чтобы «x86+x64, но не ARM и Itanium». Там либо конкретная платформа, на которую программа заточена, либо AnyCPU.
/platform:<string> Limit which platforms this code can run on: x86,
Itanium, x64, arm, anycpu32bitpreferred, or
anycpu. The default is anycpu.
Здравствуйте, alexzzzz, Вы писали:
A>·>Неправда. Надо ещё откуда-то .net framework взять. Притом правильной версии и битности. И чтобы он поставился нормально. И чтобы не поломался случайно. A>Инсталлятор, да, лучше приложить, хотя Net Framework часто уже есть. С правильной битностью в Net Framework проще ― инсталляторы ставят сразу оба варианта, где это практически возможно.
А часто и нет. Или 3 версии, а надо 4ю. и т.п.
A>·>Обычно java-based программы ставятся распаковкой архива. Куда уж проще... A>С дополнительным exe-шничком, который собственно и запускает программу на правильной версии Явы, если она есть. Дополнительных exe-шничков в Net тоже можно налепить, была бы необходимость.
Обычно есть опция скачать архив с bundled jvm, чтобы не искать "правильную версию".
A>·>А наличие Microsoft .NET Framework Repair® Tool™ ни на что не намекает? A>Не-а. Ещё не видел сломанного Net Framework, кроме трёх компьютеров, на которых вирус Expiro прошёлся по всем exe-шникам. Если бы Net Framework там реально использовался, Repair Tool был бы полезен, наверное.
Ну наверное Микрософту делать нечего было, ну и запилили на выходных эту тулзу ради прикола.
A>У меня дома долго висела Java 8 Update 73 (64-bit), которая ни работать не хотела, ни удаляться. Сейчас про неё вспомнил, пришлось грохать папку и чистить следы вручную. Java Repair Tool не нашёл.
А какие там следы-то?
A>·>Это бессмысленно. Скажем в IDEA можно во время установки выбрать галочками какие ярлыки запуска помещать на рабочий стол — x84, x64 или оба. A>Тут раз двадцать уже написали, что флажок нужен/полезен только для тех случаев, когда у программы имеется жёсткая зависимость от какого-либо компонента, существующего только под одну конкретную платформу. Ну не работает твоя программа в режиме x64. Ей не нужно делать специальных ярлычков. Ставишь platform:x86 ― и теперь она знает сама как ей правильно запускаться на 64.
В данном случае нет "правильного". Правильность зависит от того, как пользователь хочет её использовать.
A>·>Решение о таргет-платформе должно приниматься во время деплоймента, а не во время компиляции. A>Он НЕ требуется на этапе компиляции проекта. Можешь выставить потом, когда захочешь, если надо.
Т.е. "/platform (C# Compiler Options)" это не опция компилятора, т.е. тулзы, которая компилирует?
A>·>Почему не бывает? Программ которые пишут под x86/x64 — полно, а вот ARM/Itanium — экзотика. A>>>Во-вторых, в этом пункте рассмотрена ситуация, когда ограничение выставлено осознанно разработчиком библиотеки ― ему виднее, где она работоспособна, а где нет. Если считаешь, что знаешь это лучше разработчика, переходишь к пункту 2. A>·>Вот разработчик видит: "эта нужная мне либа имеет .dll-ки под Intel-ы 32 и 64. Но ARM не умеет". Как разработчик поставит флажок? A>Конкретно такой комбинации не бывает, чтобы «x86+x64, но не ARM и Itanium». Там либо конкретная платформа, на которую программа заточена, либо AnyCPU.
Комбинация, очевидно, бывает. Заточить программу можно под некое подмножество платформ. Просто компилятор так не умеет.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
O>>Но дело тут такое — х64 винда с дотнетом это на некотором уровне приближения две винды с двумя дотнетами — 32хбитная винда с 32хбитным дотнетом и 64 битная винда с 64хбитным дотнетом. И как тут выбрать на чем работать? ·>Понятно. Т.е. в итоге сабж это не продуманное архитектурное решение, а необходимость как-то бороться с platform-hell в винде. ·>Скажем, в дистрибутив java приложения делается специальный launcher (или несколько) под конкретную платформу (app.exe/app.sh/etc), а само приложение обычно кладётся как jar рядышком.
JRE тоже может быть несколько на системе, а может быть одна. С .нет ситуация более предсказуемая, потому разработчикам дали рычажок.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ·, Вы писали:
·>Это бессмысленно. Скажем в IDEA можно во время установки выбрать галочками какие ярлыки запуска помещать на рабочий стол — x84, x64 или оба.
И что выберет домохозяйка?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, ·, Вы писали:
Ops>·>Это бессмысленно. Скажем в IDEA можно во время установки выбрать галочками какие ярлыки запуска помещать на рабочий стол — x84, x64 или оба. Ops>И что выберет домохозяйка?
С IDEA — это уже не домохозяйка. А то давайте еще обсудим особенности работы домохозяйки с sbt, которому на 32битной яве стэка не хватает.
Здравствуйте, Слава, Вы писали:
С>С IDEA — это уже не домохозяйка. А то давайте еще обсудим особенности работы домохозяйки с sbt, которому на 32битной яве стэка не хватает.
Попался. В том-то и дело, что IDEA для спецов, потому и выбор предлагает. А как быть с книгой кулинарных рецептов? Предложить выбор, какой битности должен быть ярлык, или может проще самому решить, заранее, избежав лишних вопросов в поддержку?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>·>Это бессмысленно. Скажем в IDEA можно во время установки выбрать галочками какие ярлыки запуска помещать на рабочий стол — x84, x64 или оба. Ops>И что выберет домохозяйка?
Домохозяйка может и не выбирать. Дистрибутив содержит всё что надо, включая бинарики и VM нужной битности. А не домохозяйка может выбрать что требуется.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Домохозяйка может и не выбирать.
Тогда у части домохозяек ярлыка вообще не будет, или будет неправильный — это потенциальный геморрой для поддержки. Иногда лучше не оставлять лишнего выбора.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, alexzzzz, Вы писали:
A>·>Ну наверное Микрософту делать нечего было, ну и запилили на выходных эту тулзу ради прикола. A>Сами решают свои проблемы сами, не сваливая на пользователя.
Ты сам-то читал?
"Recommended Method: Run the Microsoft utility to repair corrupted registry keys". А уж если и это мелкомягкое поделие не сработает, можно и ручками один ключик реестра прибить.
Ява тут не причём. Это мелкомягкий MSI жжот напалмом и microsoft recommended way изготовления инсталлеров, без которого беджик "Certified for Microsoft Windows" не получишь.
A>В реестре. Из-за которых Java всё ещё висела в списке установленных программ, и из-за которых java-программа, которую я скачал для проверки, при запуске писала что-то типа «Ява вроде есть, а вроде и нет, запускаться не буду».
Не пользуйся виндой или смирись.
Кстати, отсюда http://www.oracle.com/technetwork/java/javase/downloads/ можно скачать jre-*-windows-*.tar.gz
A>·>Т.е. "/platform (C# Compiler Options)" это не опция компилятора, т.е. тулзы, которая компилирует? A>Кто тебя требует её указывать во время компиляции? Никто. Хочешь принять решение позже? Принимай. Хочешь изменить уже принятое решение? Изменяй.
Зачем тогда опция?
A>
/out:<file> Specify output file name (default: base name of
A> file with main class or first file)
A>К опции out есть аналогичные претензии?
Нет, ибо современные компьютеры данные хранят в файлах. Вывод компилятора — данные, данные без имени файла сохранять некуда.
A>А что, к IL отношения не имеет, но тем не менее зачем-то является опцией компилятора. Можно не указывать, но значение по умолчанию будет всё равно. Какой идиот придумал указывать имя файла на стадии компиляции?
Это имя артефкта выдаваемого процессом компиляции.
A>Можно ведь задавать правильное имя файлу во время деплоимента. Собрать специальный инсталлятор, чтобы он выставлял правильное имя файла прямо на машине пользователя. А также делал два ярлычка на рабочем столе.
Имя файла не влияет на работоспособность программы, флажок — влияет.
A>>>Конкретно такой комбинации не бывает, чтобы «x86+x64, но не ARM и Itanium». Там либо конкретная платформа, на которую программа заточена, либо AnyCPU. A>·>Комбинация, очевидно, бывает. Заточить программу можно под некое подмножество платформ. Просто компилятор так не умеет. A>А зачем? У тебя есть волшебная нативная dll, код которой можно загрузить и в x86-процесс, и в x64-процесс и он везде будет работать?
У меня есть две длл, под обе intel платформы, но нет под ARM/Itanium. Шо делать?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Ещё раз повторяю. java-софт для домохозяек обычно распространяется с bundled jvm, нужной версии с нужными native и т.п. — предсказуемее некуда, распаковывешь и запускаешь. О таком в .net только мечтать с их монструозным установщиками, которые втыкаются по самые гланды в систему, обязательно требуя админских прав, и как же без ребутов...
1. Современные установщики ничего не бандлят, и скачивают при необходимости.
2. При необходимости offline-инсталляции установщики подготавливают образ. (но домохозяйке это не нужно)
Так что можешььповторять дальше свою мантру.
То ли в Яве: скачали клиент банк, установили, а через месяц он не запускается, потому, что Яву все так ахренительно бандлят, что аж генерят ярлыки с гвоздями прибитыми путями. Разумеется после апдейта — они уплывают.
Здравствуйте, fddima, Вы писали:
F>·>Ещё раз повторяю. java-софт для домохозяек обычно распространяется с bundled jvm, нужной версии с нужными native и т.п. — предсказуемее некуда, распаковывешь и запускаешь. О таком в .net только мечтать с их монструозным установщиками, которые втыкаются по самые гланды в систему, обязательно требуя админских прав, и как же без ребутов... F> 1. Современные установщики ничего не бандлят, и скачивают при необходимости.
Если так нравится, есть java online installer.
А я вот ненавижу эти online инсталлеры.
F> 2. При необходимости offline-инсталляции установщики подготавливают образ. (но домохозяйке это не нужно)
Круто, а ещё можно стоя в гамаке. Настоящий комсомолец?
F> Так что можешььповторять дальше свою мантру.
А как насчёт обязательности админских прав?
F> То ли в Яве: скачали клиент банк, установили, а через месяц он не запускается, потому, что Яву все так ахренительно бандлят, что аж генерят ярлыки с гвоздями прибитыми путями. Разумеется после апдейта — они уплывают.
Ничё не понял. Гвоздями что угодно прибить можно к чему угодно. Просто не делайте так.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>А я вот ненавижу эти online инсталлеры.
Тем не менее они есть. Онлайн инсталлеры, обновления и прочие прелести жизни... без них уже не то. Я сам их недолюбливаю, но ту же студию чаще всего ставлю именно ими.
F>> 2. При необходимости offline-инсталляции установщики подготавливают образ. (но домохозяйке это не нужно) ·>Круто, а ещё можно стоя в гамаке. Настоящий комсомолец?
В чем конкретно проблемы?
F>> Так что можешььповторять дальше свою мантру. ·>А как насчёт обязательности админских прав?
Они нужны только когда мы хотим установить специфичные системные обновления (читай .net fw). Это приблизитель так же как требовать от apt устанавливать апдейты без рута. В остальных случаях ставить ничего не нужно, а fw уже на борту. Тут то и рулят онлайн инсталлеры, т.к. позволяют сократить размер дистрибутива, сохранив функциональность. В бандле ничего плохого тоже теоретически нет, но тогда обновлениями рантайма и стандартными библиотеками должен заниматься ты. Так что вопрос явно не неоднозначен.
·>Ничё не понял. Гвоздями что угодно прибить можно к чему угодно. Просто не делайте так.
Я с таким сталкивался, порадовало. Видимо разработчики не в курсе про ваш обычный бандлинг. Это конечно же все потому что вокруг одни... У множества задач более одного правильного решения.
Здравствуйте, fddima, Вы писали:
F>·>А я вот ненавижу эти online инсталлеры. F> Тем не менее они есть. Онлайн инсталлеры, обновления и прочие прелести жизни... без них уже не то. Я сам их недолюбливаю, но ту же студию чаще всего ставлю именно ими.
Это прелести плохой жизни... до сих пор нормального пакетного менеджера не изобрели в ms.
F>>> 2. При необходимости offline-инсталляции установщики подготавливают образ. (но домохозяйке это не нужно) F>·>Круто, а ещё можно стоя в гамаке. Настоящий комсомолец? F> В чем конкретно проблемы?
Зачем что-то подготавливать, когда можно строить сразу готовый в процессе билда? KISS, не?
F>·>А как насчёт обязательности админских прав? F> Они нужны только когда мы хотим установить специфичные системные обновления (читай .net fw). Это приблизитель так же как требовать от apt устанавливать апдейты без рута.
Когда рута нет, есть возможность вручную скачать/распаковать.
F> В остальных случаях ставить ничего не нужно, а fw уже на борту.
Он может быть не той версии.
F> Тут то и рулят онлайн инсталлеры, т.к. позволяют сократить размер дистрибутива, сохранив функциональность. В бандле ничего плохого тоже теоретически нет, но тогда обновлениями рантайма и стандартными библиотеками должен заниматься ты. Так что вопрос явно не неоднозначен.
Нифига они не рулят, просто выкручиваются как могут из-за отстутствия пакетного менеджера.
F>·>Ничё не понял. Гвоздями что угодно прибить можно к чему угодно. Просто не делайте так. F> Я с таким сталкивался, порадовало. Видимо разработчики не в курсе про ваш обычный бандлинг. Это конечно же все потому что вокруг одни... У множества задач более одного правильного решения.
И ещё больше неправильных. Прибивать что-то гвоздями — неправильное где угодно, даже в java.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Это прелести плохой жизни... до сих пор нормального пакетного менеджера не изобрели в ms.
Но есть работающее решение для системных обновлений куда входит дотнет.
F>> В чем конкретно проблемы? ·>Зачем что-то подготавливать, когда можно строить сразу готовый в процессе билда? KISS, не?
Зачем включать то, что является компонентом системы?
·>Когда рута нет, есть возможность вручную скачать/распаковать.
Ага, а поставить возможности толком нет.
F>> В остальных случаях ставить ничего не нужно, а fw уже на борту. ·>Он может быть не той версии.
Вот если он не той, только тогда и нужно спрашивать обновление и права админа. Вообще — идея ставить программы только под админом вовсе не порочна.
·>Нифига они не рулят, просто выкручиваются как могут из-за отстутствия пакетного менеджера.
Пакетные менеджеры сдуваются на конфликтах system-wide библиотек. В итоге бандлить чаще проще, что несколько ограничивает его применимость. В линуксах оно работает от того, что репозиторий фактически один центральный. Всякие внешние (дополнительные) источники, безусловно удобны, но как только появляются конфликты — оно перестает быть удобным. В итоге путь анархии — практически показал что это просто работает. А вот попытки контроллировать деплоймент централизованно (всякие сторы) — уже сложнее, чем могло-бы быть. KISS же.
·>И ещё больше неправильных. Прибивать что-то гвоздями — неправильное где угодно, даже в java.
То что кто-то что-то делает не так, — случается везде. Но с дотнетом описанной проблемы в принципе нет. Есть набор версий, да и то, защита от дурака встроенная, так что юзер сможет внятно обратиться в саппорт. Сама установка и последующие обновления дотнета — это то чем можно не ломать себе голову, и это плюс. Все что поверх — нужно делать руками, к счастью по части деплоймента в third party по большей мере все реализовано. По крайней мере это не то что 10+ лет назад, когда действительно надо было бандлить и фреймворк, и ставить специфичные фиксы на него.
Здравствуйте, fddima, Вы писали:
F>·>Это прелести плохой жизни... до сих пор нормального пакетного менеджера не изобрели в ms. F> Но есть работающее решение для системных обновлений куда входит дотнет.
Работающее не лучше (а точнее хуже), чем сдувающиеся пакетные менеджеры.
F>·>Зачем что-то подготавливать, когда можно строить сразу готовый в процессе билда? KISS, не? F> Зачем включать то, что является компонентом системы?
Так в том-то и дело, что оно _может_ являться компонентом системы, если очень хочеися, но _не должно_. Чем от меньшего числа компонент системы зависит некий софт — тем лучше.
F>·>Когда рута нет, есть возможность вручную скачать/распаковать. F> Ага, а поставить возможности толком нет.
Что значит "толком поставить"? Запускается и работает — этого не достаточно? Обязательно заколачивать в систему по самые гланды? Зачем?
F>·>Он может быть не той версии. F> Вот если он не той, только тогда и нужно спрашивать обновление и права админа. Вообще — идея ставить программы только под админом вовсе не порочна.
Она не порочна если абсолютно всё ставится из-под админа и никак по-другому ничего сделать нельзя. А в таком виде это тупо палки в колёса.
F>·>Нифига они не рулят, просто выкручиваются как могут из-за отстутствия пакетного менеджера. F> Пакетные менеджеры сдуваются на конфликтах system-wide библиотек. В итоге бандлить чаще проще, что несколько ограничивает его применимость. В линуксах оно работает от того, что репозиторий фактически один центральный. Всякие внешние (дополнительные) источники, безусловно удобны, но как только появляются конфликты — оно перестает быть удобным. В итоге путь анархии — практически показал что это просто работает. А вот попытки контроллировать деплоймент централизованно (всякие сторы) — уже сложнее, чем могло-бы быть. KISS же.
dll и прочий hell? Не, не слышал.
F>·>И ещё больше неправильных. Прибивать что-то гвоздями — неправильное где угодно, даже в java. F> То что кто-то что-то делает не так, — случается везде. Но с дотнетом описанной проблемы в принципе нет. Есть набор версий, да и то, защита от дурака встроенная, так что юзер сможет внятно обратиться в саппорт. Сама установка и последующие обновления дотнета — это то чем можно не ломать себе голову, и это плюс. Все что поверх — нужно делать руками, к счастью по части деплоймента в third party по большей мере все реализовано. По крайней мере это не то что 10+ лет назад, когда действительно надо было бандлить и фреймворк, и ставить специфичные фиксы на него.
Так для изврлюбителей и java есть ставящаяся в систему, с автообновлялкой и с теми же присущими глюками и заморочками.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Работающее не лучше (а точнее хуже), чем сдувающиеся пакетные менеджеры.
Но это данность. Хуже — на мой взгляд — да. Но работают они хорошо (отлично?).
·>Так в том-то и дело, что оно _может_ являться компонентом системы, если очень хочеися, но _не должно_. Чем от меньшего числа компонент системы зависит некий софт — тем лучше.
Нет, — дотнет неотъемлимый компонент целого ряда версий систем (и всех современных десктопных). Даже загрузчик модулей распознает дотнет модули. Правильно ли было делать так — вопрос иного толка, я совсем выше в этом топике кажется писал, но если кратко — мне лично, нравятся внешние интерпретаторы больше, но и плюсы от нативной интеграции есть.
F>>·>Когда рута нет, есть возможность вручную скачать/распаковать. F>> Ага, а поставить возможности толком нет. ·>Что значит "толком поставить"? Запускается и работает — этого не достаточно? Обязательно заколачивать в систему по самые гланды? Зачем?
А если не запускается? Исполнимый модуль, например, банально импортирует модуль по абсолютному пути (для записи смертным недоступный). Нужно уже совершать доп действия (например подредактировать шелл скрипт дабы втюхнуть переменные). Да и вообще там не простое копирование встречается. Просить от дотнета того же — странно. .net core теоретически можно бандлить (не знаю как просто это сделать, баловался только с ембедом рантайма в нэйтив).
F>>·>Он может быть не той версии. F>> Вот если он не той, только тогда и нужно спрашивать обновление и права админа. Вообще — идея ставить программы только под админом вовсе не порочна. ·>Она не порочна если абсолютно всё ставится из-под админа и никак по-другому ничего сделать нельзя. А в таком виде это тупо палки в колёса.
Везде по сути можно ставить программы без админских прав, с теми или иными ограничениями. Иначе это не комп а плеер/читалка/кому что по душе. Не все права даются юзеру, некоторый софт просто неспособен работать без соответствующих прав. В итоге неясно с чего такое безапелляционно е утверждение.
F>>·>Нифига они не рулят, просто выкручиваются как могут из-за отстутствия пакетного менеджера. F>> Пакетные менеджеры сдуваются на конфликтах system-wide библиотек. В итоге бандлить чаще проще, что несколько ограничивает его применимость. В линуксах оно работает от того, что репозиторий фактически один центральный. Всякие внешние (дополнительные) источники, безусловно удобны, но как только появляются конфликты — оно перестает быть удобным. В итоге путь анархии — практически показал что это просто работает. А вот попытки контроллировать деплоймент централизованно (всякие сторы) — уже сложнее, чем могло-бы быть. KISS же. ·>dll и прочий hell? Не, не слышал.
Нет, не слышал. Приватные зависимости носим с собой. Разве ад возникал не из-за тупого деплоймента?
·>Так для изврлюбителей и java есть ставящаяся в систему, с автообновлялкой и с теми же присущими глюками и заморочками.
Так и отлично. Просто в фаре набираю java ... и этого на винде мне хватает. Зачем бандлить рантайм для программы весом в метр. Тем кому важен специфичный рантайм бандлят. Но это скорее от неизбежности, так просто проще. Но с дотнетом этого не нужно.
Здравствуйте, ·, Вы писали:
A>>Сами решают свои проблемы сами, не сваливая на пользователя. ·>Ты сам-то читал? ·>"Recommended Method: Run the Microsoft utility to repair corrupted registry keys". А уж если и это мелкомягкое поделие не сработает, можно и ручками один ключик реестра прибить.
Читал, даже воспользовался. Оно просто убирает Java из списка установленных программ, чтоб не отсвечивало. Ручками потом тоже нужно. Ручками завсегда можно, но хотелось бы, чтобы оно само.
·>Ява тут не причём. Это мелкомягкий MSI жжот напалмом
Ява всегда не при чём.
A>>·>Т.е. "/platform (C# Compiler Options)" это не опция компилятора, т.е. тулзы, которая компилирует? A>>Кто тебя требует её указывать во время компиляции? Никто. Хочешь принять решение позже? Принимай. Хочешь изменить уже принятое решение? Изменяй. ·>Зачем тогда опция?
A>>К опции out есть аналогичные претензии? ·>Нет, ибо современные компьютеры данные хранят в файлах. Вывод компилятора — данные, данные без имени файла сохранять некуда.
1. /out можно не указывать.
2. «Имя файла не влияет на работоспособность программы».
3. Файл всегда можно переименовать.
Зачем тогда опция?
A>>А зачем? У тебя есть волшебная нативная dll, код которой можно загрузить и в x86-процесс, и в x64-процесс и он везде будет работать? ·>У меня есть две длл, под обе intel платформы, но нет под ARM/Itanium. Шо делать?
Раз программа сама разрешает свои зависимости => AnyCPU.
Здравствуйте, ·, Вы писали:
A>>1. /out можно не указывать. A>>2. «Имя файла не влияет на работоспособность программы». A>>3. Файл всегда можно переименовать. A>>Зачем тогда опция? ·>Эта опция относится непосредственно к процессу компиляции. Компилятор должен куда-то класть свой вывод, вариантов нет. Обсуждаемый флажок никакого отношения к компиляции не имеет, а влияет только на работоспособность на последнем этапе жизненного цикла проекта — запуск в системе пользователя.
/out никакого отношения к процессу компиляции не имеет. Компилятору всё равно, как называется конечный файл. Опция опциональна, указывать не требуется, т.к. есть значение по умолчанию. /platform тоже не имеет отношения к процессу компиляции, компилятору всё равно, что там указано. Опция также не требуется, т.к. есть значение по умолчанию.
A>>>>А зачем? У тебя есть волшебная нативная dll, код которой можно загрузить и в x86-процесс, и в x64-процесс и он везде будет работать? A>>·>У меня есть две длл, под обе intel платформы, но нет под ARM/Itanium. Шо делать? A>>Раз программа сама разрешает свои зависимости => AnyCPU. ·>Что значит сама?
Выбирает и подгружает нужную версию нативной dll в рантайме. Или разработчик озаботился, как в Яве, лаунчером в виде exe/bat, и подопытной программе уже на момент старта подсовываются правильные версии зависимостей.
·>Почему нельзя всегда самой? Зачем эти частные случаи?
Для удобства. Чтоб не ручками, а само автоматически.
·>Чем поддержка одной платформы из четырёх принципиально отличается от поддержки двух платформ из четырёх?
Когда нативные библиотеки, от которых ты зависишь, существует более чем под одну платформу, тебе в любом случае нужен какой-то ручной механизм разрешения зависимостей. Когда зависимости существуют только под одну платформу, то писать ручной механизм нет смысла, т.к. не из чего выбирать.
Здравствуйте, alexzzzz, Вы писали:
A>·>Эта опция относится непосредственно к процессу компиляции. Компилятор должен куда-то класть свой вывод, вариантов нет. Обсуждаемый флажок никакого отношения к компиляции не имеет, а влияет только на работоспособность на последнем этапе жизненного цикла проекта — запуск в системе пользователя. A>/out никакого отношения к процессу компиляции не имеет. Компилятору всё равно, как называется конечный файл. Опция опциональна, указывать не требуется, т.к. есть значение по умолчанию. /platform тоже не имеет отношения к процессу компиляции, компилятору всё равно, что там указано. Опция также не требуется, т.к. есть значение по умолчанию.
Не правда. Компилятор должен иметь какое-то имя файла, иначе ему некуда будет писать результат своей работы.
A>·>Почему нельзя всегда самой? Зачем эти частные случаи? A>Для удобства. Чтоб не ручками, а само автоматически.
Ок. Ладно, согласен на "для удобства", этим можно обосновать всё. Удобно же админские-права требовать для деплоймента fw, удобно же MSI использовать...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Это понятно. Непонятно почему этот флажок требуется на этапе компиляции проекта, а не его дистрибуции.
Для удобства разработки — обычно в разработке используется та же самая библиотека, что и в продакшене, потому отладочные билды точно так же нужно принудительно запускать в 32-битном режиме. Но вообще этот флажок можно поменять в любой момент без перекомпиляции с помощью утилитки corflags.
Здравствуйте, Ops, Вы писали:
S>>https://chocolatey.org/install Ops>Там свои тараканы.
?
гуй есть, обновление всего софта есть, селф-хостинг присутствует — что ещё для щастья надо-то?
Здравствуйте, Ops, Вы писали:
Ops>Ну вот пару дней назад vbox сломался, сам одной версии, extensions другой, виртуалка не пускается. Вообще, поддержка многих пакетов в лучших традициях опенсорса.
А, в этом смысле.
Ну да, изначально идея была такая: вендоры сами размещают пакеты, ленивых заменяет сообщество. Но что-то пошло каквсегда…
Здравствуйте, koandrew, Вы писали:
K>Нужна эта опция в основном для интеграции с легаси-кодом в виде COM-объектов (т.к. они бинарные, то для 32 и 64 бит нужны разные библиотеки, старые компоненты, соответственно, есть только в 32 битных билдах). У нас на работе полно такого хлама.
Это менее важная причина. Товарищ Точка выше уже описал главную причину, почему битность торчит -- заголовок PE-header'а.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Sharov, Вы писали:
S>>Это менее важная причина. Товарищ Точка выше уже описал главную причину, почему битность торчит -- заголовок PE-header'а.
K>Ты путаешь причину со следствием.
Не понял, чего путаю Заголовок PE требует битность, приходится ее всюду таскать. Для чего требуется битность PE заголовку -- дела давно минувших дней и неправда. Но это, увы, факт.
Здравствуйте, Sharov, Вы писали:
S>Не понял, чего путаю Заголовок PE требует битность, приходится ее всюду таскать. Для чего требуется битность PE заголовку -- дела давно минувших дней и неправда. Но это, увы, факт.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Sharov, Вы писали:
S>>Не понял, чего путаю Заголовок PE требует битность, приходится ее всюду таскать. Для чего требуется битность PE заголовку -- дела давно минувших дней и неправда. Но это, увы, факт.
K>У тебя точно всё хорошо с логикой?
Еще разок. Причина -- необходимая битность PE-header'а, следсвтие -- managed код под windows может зависть от битности, хотя не должен. Где я ошибся?
Можно просто сказать, а не рожи крючитьфейспалмить.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Sharov, Вы писали:
S>>Благодарю, так яснее. Хотя не согласен в том, что managed код совсем уж не отличается. Я точно не уверен, но думается мне, зная target битность компилятор может получше провести оптимизацию байт кода, нежели в случае AnyCpu. Но я ничего не утверждаю, просто логично было бы предположить...
K>Это же легко проверить. K>Тут ещё есть такой момент — даже если какие-то оптимизации по типу тех, о которых ты говоришь, и производятся, результирующий код всё равно остаётся переносимым между 32 и 64 битами. Ибо флаг битности можно поменять и без перекомпиляции (см. corflags.exe), при этом сборка остаётся работоспособной (опять же, при условии, что у неё нет платформо-зависимых dependencies).
Этот аргумент + дискуссии на SO убедили меня, что я не прав с платформенными оптимизациями.
Здравствуйте, Serginio1, Вы писали:
S>Это все интересно. Ответь для себя CIL это язык или Байт код? S>NGEN это скомпилированный код или КОД для VM?
Да всё правильно tranzit расписал. Терминология не совпадает с официальной от MS, да.
С CIL вечно путаница — под ним понимают и CIL bytecode и CIL как язык, из контекста обычно понятно. Ув. tranzit, очевидно, имел в виду первое.
Ну и вместо VM обычно используется или execution engine (если речь про конкретную реализацию) или virtual execution system (если речь об абстрактном описании аля ECMA-335).
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>Это все интересно. Ответь для себя CIL это язык или Байт код? S>>NGEN это скомпилированный код или КОД для VM?
S>Да всё правильно tranzit расписал. Терминология не совпадает с официальной от MS, да. S>С CIL вечно путаница — под ним понимают и CIL bytecode и CIL как язык, из контекста обычно понятно. Ув. tranzit, очевидно, имел в виду первое.
S>Ну и вместо VM обычно используется или execution engine (если речь про конкретную реализацию) или virtual execution system (если речь об абстрактном описании аля ECMA-335).
Угу
3 компилятор преобразует исходный текст программы в машинный код или в код виртуальный
машины (по другому абстрактной как раз этот код потом исполняется виртуальной машиной например Java, perl, Lua, .Net, ...)
как понимаешь виртуальная машина не абстрактное понятие а конкретное приложение и исполняет конкретный байт код
который сформировал соответствующий конкретный компилятор из конкретного языка программирования
Как это относится к NGEN?
4б Но средой исполнения, например для байт кода, может выступать и виртуальная машина, которая кроме исполнения
байт кода может предложить и дополнительные услуги,компиляция в нативный код, сборщик мусора, доступ к
оборудованию (например звуковой карте и т.д.)
Очень часто используется дополнительная компиляция и в нативном коде для обвязки не объектных Win Api (MakeObjectInstance в Delphi)
Опять же .Net Native предлагает сборку мусора. Она тоже VM? А про оборудование я так и не понял.
6 Виртуальная машина это программа которая является прослойкой между байт кодом и процессором.
виртуальная машина берет байт код и выполняет на целевой системе "интерпретируя" этот код, но заметьте виртуальная машина при этом не становится интерпретатором. Ранее мы уже сказали что интерпретатор анализирует текст программы а не байт код, само слово "код" — и есть ключевое понятие машины и в данном случае виртуальной.
NGEN под это определение не подходит.
Я бы нпросто назвал это среда выполнения. А VM пошло именно от Java, причем когда еще не было Jit компилятора.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Как это относится к NGEN?
ngen — это не компилятор, это часть VES.
S> Очень часто используется дополнительная компиляция и в нативном коде для обвязки не объектных Win Api
??? В смысле дополнительная компиляция? Обычные PIA (Primary Interop Assemblies), опционально встраиваются в саму сборку.
S>Опять же .Net Native предлагает сборку мусора. Она тоже VM? А про оборудование я так и не понял.
Именно поэтому MS предпочитает использовать термин execution engine, а не VM.
Если говорить про CLI как про абстрактную модель, то там VM разумеется присутствует, но когда дело доходит до готовых бинарников, то вся роль "VM" сводится к набору runtime services. Конкретный их состав зависит от таргетинга.
Простая аналогия: в принципе, ничего не мешает собирать JS сразу в натив, хотя бы для js-extensions браузеров. Что, js от этого перестанет быть языком, работающим в песочнице? Если смотреть на язык как на абстракцию — разумеется нет, но если сузить тему до конкретной реализации, то сова хоть и с треском, но на глобус натянется.
Тож самое — концепция владения в rust. Снова "песочница", которая обеспечивается только силами компилятора, без участия рантайма.
Народ постоянно путает логические абстракции с готовым кодом, отсюда и неразбериха.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Как это относится к NGEN? S>ngen — это не компилятор, это часть VES.
Но код то скомпилирован и JIT компиляции может и не быть, если нет рефлексии и подгрузки сборок. S>> Очень часто используется дополнительная компиляция и в нативном коде для обвязки не объектных Win Api S>??? В смысле дополнительная компиляция? Обычные PIA (Primary Interop Assemblies), опционально встраиваются в саму сборку.
Я про нативный код. Например в Delphi есть MakeObjectInstance в Delphi которя генерирует код для использования объектов в необъектных методах Win Api.
Я про то, что и в нативе существует аналог JIT. Но они VM не являются.
S>>Опять же .Net Native предлагает сборку мусора. Она тоже VM? А про оборудование я так и не понял. S>Именно поэтому MS предпочитает использовать термин execution engine, а не VM.
И я про это. S>Если говорить про CLI как про абстрактную модель, то там VM разумеется присутствует, но когда дело доходит до готовых бинарников, то вся роль "VM" сводится к набору runtime services. Конкретный их состав зависит от таргетинга.
И при этом CLI для .Net Native это аналог ассемблера. S>Простая аналогия: в принципе, ничего не мешает собирать JS сразу в натив, хотя бы для js-extensions браузеров. Что, js от этого перестанет быть языком, работающим в песочнице? Если смотреть на язык как на абстракцию — разумеется нет, но если сузить тему до конкретной реализации, то сова хоть и с треском, но на глобус натянется.
А вот CLI в .Net Native не работает в песочнице. S>Тож самое — концепция владения в rust. Снова "песочница", которая обеспечивается только силами компилятора, без участия рантайма.
S>Народ постоянно путает логические абстракции с готовым кодом, отсюда и неразбериха.
Ну опять же можно вспомнить Оберон так активно здеь когда то обсуждавшихся. Опять же Singularity https://ru.wikipedia.org/wiki/Microsoft_Singularity
Singularity — начатый в 2003 году проект исследовательского подразделения корпорации Майкрософт по созданию высоконадёжной операционной системы, в которой микроядро, драйверы устройств и приложения написаны на управляемом коде.
Отличительной особенностью данной ОС является использование идеологии программно-изолированных процессов (Software Isolated Processes, SIP), похожих на лёгкие процессы языка Erlang, общение между которыми происходит исключительно посредством сообщений. В отличие от традиционных ОС, защита таких процессов в Singularity производится не путём организации аппаратно-защищённых адресных пространств, а путём использования типобезопасного подмножества промежуточного языка (MSIL) и его верификации перед компиляцией в родной код процессора. Каждый SIP обладает своим объектным пространством, «сборщиком мусора» и средой периода исполнения. Для таких процессов не допускается совместное использование памяти, и они не имеют возможность модифицировать свой код, что усиливает гарантии надежности работы программы в SIP.
Низкоуровневый код обработки прерываний x86 написан на языке ассемблера и C. Библиотеки времени исполнения (англ. runtime) и сборщик мусора написаны на Sing# (специально доработанном для данного проекта диалекте C#) с использованием небезопасного режима (англ. unsafe mode). Также присутствует код на C, использующийся в целях отладки. BIOS компьютера вызывается только на этапе загрузки в 16-разрядном реальном режиме работы процессора. После перехода в 32-разрядный режим, BIOS больше никогда не вызывается, вместо него используются драйверы, написанные на Sing#. При установке ядра, оп-коды CIL компилируются в инструкции x86 при помощи компилятора Bartok.
Bartok [1] — это исследовательский проект по созданию на языке C# оптимизирующего компилятора из CIL в x86.
Singularity 1.0 была завершена в 2007 году. Исследовательский пакет Singularity 1.1 Research Development Kit (RDK) был выпущен под лицензией Shared Source и допускает академическое некоммерческое использование; пакет доступен на CodePlex. 14 ноября 2008 г. был выпущен Singularity RDK 2.0. Дальнейшая разработка прекращена.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> А вот CLI в .Net Native не работает в песочнице.
Ну о чём я и говорил — не надо натягивать термины, которые относятся к абстрактному описанию "как работает дотнет" на конкретную реализацию. Полный бред получается.
CLI — это спецификация. Она не может "работать / не работать". Она или соблюдается, или не соблюдается. Как именно соблюдается: силами рантайма, компилятора или расстрелом нерадивых программистов — эт уже дело десятое и к самой спецификации никакого отношения не имеет.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> А вот CLI в .Net Native не работает в песочнице. S>Ну о чём я и говорил — не надо натягивать термины, которые относятся к абстрактному описанию "как работает дотнет" на конкретную реализацию. Полный бред получается.
Для компиляции в .Net Native это язык. Ибо термины не компилируются S>CLI — это спецификация. Она не может "работать / не работать". Она или соблюдается, или не соблюдается. Как именно соблюдается: силами рантайма, компилятора или расстрелом нерадивых программистов — эт уже дело десятое и к самой спецификации никакого отношения не имеет.
А что тогда компилирует Jit или компилятор .Net Native?
В чем разница CLI от C#? Кстати первый прекрасно декомпилируется во второй.
Common Intermediate Language (сокращённо CIL) — «высокоуровневый ассемблер» виртуальной машины .NET. Промежуточный язык, разработанный фирмой «Microsoft» для платформы .NET Framework. JIT-компилятор CIL является частью CLR (англ. common language runtime) — общей среды выполнения программ, написанных на языках .NET. Ранее язык назывался «Microsoft Intermediate Language (MSIL)», однако был переименован для создания стандарта «ECMA-335».
Все компиляторы, поддерживающие платформу .NET, должны транслировать код с языков высокого уровня платформы .NET на язык CIL. В частности, код на языке CIL генерируют все компиляторы .NET фирмы «Microsoft», входящие в среду разработки «Microsoft Visual Studio» (C#, Managed C++, Visual Basic .NET, Visual J# .NET).
По синтаксису и мнемонике язык CIL напоминает язык ассемблера. Его можно рассматривать как ассемблер виртуальной машины .NET. В то же время язык CIL содержит некоторые достаточно высокоуровневые конструкции, повышающие его уровень по сравнению с ассемблером для любой реально существующей машины, и писать код непосредственно на CIL легче, чем на ассемблере для реальных машин. Поэтому CIL можно рассматривать как своеобразный «высокоуровневый ассемблер».
Язык CIL также нередко называют просто IL от англ. intermediate language — буквально «промежуточный язык».
Синтаксис и мнемоника языка CIL описываются стандартом «ECMA-335». Спецификация CIL является составной частью более общей спецификации — спецификации CLI (англ. common language infrastructure).
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>> А вот CLI в .Net Native не работает в песочнице. S> Для компиляции в .Net Native это язык. Ибо термины не компилируются CLI == Common Language Infrastructure, какой нафиг язык?
CIL, возможно? Так это просто формат данных и он тож не работает. Работает машинный код, который из него порождён. И до тех пор, пока этот код соблюдает требования спецификации, нам абсолютно пофиг, как это "соблюдает" обеспечивается. Именно поэтому в CLI соответствующая часть обозвана VES (Virtual Execution System) — нас интересует только соблюдение контракта, прописанного в требованиях к среде исполнения, но не конкретная реализация.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>>> А вот CLI в .Net Native не работает в песочнице. S>> Для компиляции в .Net Native это язык. Ибо термины не компилируются S>CLI == Common Language Infrastructure, какой нафиг язык?
S>CIL, возможно? Так это просто формат данных и он тож не работает. Работает машинный код, который из него порождён. И до тех пор, пока этот код соблюдает требования спецификации, нам абсолютно пофиг, как это "соблюдает" обеспечивается. Именно поэтому в CLI соответствующая часть обозвана VES (Virtual Execution System) — нас интересует только соблюдение контракта, прописанного в требованиях к среде исполнения, но не конкретная реализация.
То есть машинный код берется из формата?
Кстати насчет интерпретаторов
2 Интерпретатор — читает текст программы как есть и выполняет инструкцию (для c, c++, perl, ... есть интерпретатор)
например bash тоже интерпретатор не переводит даже в машинный код, или tcsh — этот shel тоже является
интерпретатором но "C" языка. Первые движки javascrip тоже являлись только интерпретатором. Конечно теперь у javascrip есть виртуальная машина и компилятор.
У Perl есть и интерпретатор и виртуальная машина и даже может компилить в нативные инструкции процессора (машинный код). Хотя когда запускаете perl script то идет компиляция на лету в байт код и потом виртуальная машина PERL исполняет этот код.
3 компилятор преобразует исходный текст программы в машинный код или в код виртуальный
машины (по другому абстрактной как раз этот код потом исполняется виртуальной машиной например Java, perl, Lua, .Net, ...)
как понимаешь виртуальная машина не абстрактное понятие а конкретное приложение и исполняет конкретный байт код
который сформировал соответствующий конкретный компилятор из конкретного языка программирования
Виртуальная машина исполняет некоторый машинно-независимый код (например, байт-код, шитый код, p-код) или машинный код реального процессора. Помимо процессора, ВМ может эмулировать работу как отдельных компонентов аппаратного обеспечения, так и целого реального компьютера (включая BIOS, оперативную память, жёсткий диск и другие периферийные устройства). В последнем случае в ВМ, как и на реальный компьютер, можно устанавливать операционные системы (например, Windows можно запускать в виртуальной машине под Linux или наоборот). На одном компьютере может функционировать несколько виртуальных машин (это может использоваться для имитации нескольких серверов на одном реальном сервере с целью оптимизации использования ресурсов сервера).
А вот натягивание этого понятия на CLR, да вообще на .Net в целом мало отличается от совы и глобуса.
Java назвала JVM и отсюда все, что связано с байт кодом и сборщиком мусора стали называть VM
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> То есть машинный код берется из формата?
S>С точки зрения VES — безусловно да. На входе данные в общепринятом формате, на выходе — исполняемый код.
Данные в общепринятом формате это что?
Почему этот формат легко декомпилировать в C# или Delphi.Net?
S>С точки зрения конкретной реализации вместо IL может быть что угодно, от своего диалекта и до генерации RyuJIT IR напрямую из текстовых исходников.
То есть это язык который компилируется в машинные коды?
Кстати
RyuJIT provides the just in time compilation service for the .NET runtime.
The runtime itself is variously called the EE (execution engine), the VM (virtual machine) or simply the CLR (common language runtime).
Depending upon the configuration, the EE and JIT may reside in the same or different executable files. RyuJIT implements the JIT side of the JIT/EE interfaces:
S>Вы сначала определитесь, какой именно уровень и чего именно мы обсуждаем, затем можно продолжать будет. S>Иначе получается очередная попытка натянуть нотный стан на струны рояля. А чо, и там и там музыка, ключи, и ноты и клавиши чорно-белые, да и молоточки на ноты (не)похожи. S>Вот как-то так оно выглядит
Ну дык мы говрим о натягивании понятия VM на все, что имеет байт код.
Например по твоему CIL это не байт код.
S>> Кстати насчет интерпретаторов S>> А вот натягивание этого понятия на CLR, да вообще на .Net в целом мало отличается от совы и глобуса. S>> Java назвала JVM и отсюда все, что связано с байт кодом и сборщиком мусора стали называть VM
S>Ну да, не надо смешивать описание реализаций в разных языках. В каждом из сложилась своя терминология и трактовка понятий "VM" в питоне и в яве пересекаются весьма слабо. Особенно если учесть, что вариантов питона штук двадцать, на любой вкус. S>Тынц как пример.
Во правильно. Но в .Net как то не прижилось понятие VM.
Я вообще упомянул, то что в интерпретаторах часто используется предварительная компиляция в байт код. А различие Питона и Явы без JIT только в статической типизации и сборке мусора.
При этом напомню что изначально в JVM не было JIT
Является ли AST VM?
Кстати пропустил статью https://habrahabr.ru/company/pt/blog/210060/
Надо почитать
S>Виртуальная машина исполняет некоторый машинно-независимый код (например, байт-код, шитый код, p-код) или машинный код реального процессора. Помимо процессора, ВМ может эмулировать работу как отдельных компонентов аппаратного обеспечения, так и целого реального компьютера (включая BIOS, оперативную память, жёсткий диск и другие периферийные устройства). В последнем случае в ВМ, как и на реальный компьютер, можно устанавливать операционные системы (например, Windows можно запускать в виртуальной машине под Linux или наоборот). На одном компьютере может функционировать несколько виртуальных машин (это может использоваться для имитации нескольких серверов на одном реальном сервере с целью оптимизации использования ресурсов сервера).
На вики с произошел перегруз термина "виртуальная машина".
То что писал раннее прочтите внимательно. S>[g]Помимо процессора, ВМ может эмулировать работу как отдельных компонентов аппаратного обеспечения, так и целого реального компьютера S>[/g]
там же четко написали что помимо виртуальной машины есть ЭМУЛЯТОР.
Роль Эмулятора заключается в замене реальной СТРУКТУРЫ (процессор, видео, периферия) на программную или электронную
Я не могу точно привести данные кто и когда применял эмуляцию. Но уже когда стали проектировать процессор 8086
стали создавать эмуляторы. Для чего делали Эти эмуляторы.
Прочтите внимательно
Когда начинают производство нового процессора то заказчики или координаты групп создают спецификацию этого
процессора в том числе и на команды.
Далее это спецификация поступает на отдел электронщиков и отдел программистов.
Конечно каждый из отделов особенно электронщики вносит некоторые изменения
Но самое главное программисты начинают создавать эмулятор этого процессора, этот эмулятор нужен
для того чтоб программисты могли уже писать OS и программы для не существующей системы.
И к моменту выпуска процессора уже будет готова все программное обеспечение.
Но эмулятором может быть не только программа но и электроника программируемая например ПЛМ-
программируемая логическая матрица
У многих тут обсуждающих нет полного понимания терминалогий
Частенько в качестве эмуляторов выступают программы которые могут эмулировать какие либо процессоры,
тогда можно установить на эти эмулируемы процессоры все программы которые для него написаны
но кроме процессора этот эмулятор может подключать эмуляторы внешних устройств.
но бывают ситуации когда программа эмулирует устройство например. Например CISCO предлогает
эмуляторы маршрутизаторов для учебных заведений. Это позволяет проводит обучение не имея реального
оборудования который может стоить до 200000$ и даже более.
Есть емулятор и берете бинарный образ OS CISCO и запускаете — получаете маршрутизатор (но виртуальный)
Когда вы запускаете виртуальную машину надо понимать что есть разные виртуальные машины
Все подробности расписывать нет смысла прочтете в инете но основные моменты отмечу
1 Две OS запускается паралельно через гипервизор он переключает процессор
между разными OS. Как понимаете процессор имее 4 уровня защиты (или контекста исполнения)
обычно Linux ядро и модули работают на зищищенном уровне 3 а пользовательские на уровне 4
также работают и другие OS
но первые два уровня свободны поэтому можно запустить гипервизор каторый будет переключать
OS-ы
2 вид. когда внутри OS созадется среда т.е. специальная программа которая будет предлогать
по внешнему виду пвседо среду на сомом деле использует все библиотеки основной OS и в том числе
оборудование через обычные системные вызовы.
3 вид. Когда программа создает виртуальную среду в том числе и биос и аппаратную среду и исполнение
происходит в контексте основной OS.
При этом программы выполняются на процессоре как есть, а доступ к оборудованю идет через запросы
из гостевой ос в ОСНОВНУЮ, но так как гостевая эмулирeет периферию то идет захват запросов(на оборудование)
гостевой ОС и виртуальная машина преобразует и делает бращение к ОСНОВНОЙ ОС.
Как видим в реальности все они являются эмуляторами но эмуляторами разного уровня
1 выриант это не эмулятор а виртуальная машина (но виртуализация на уровне процессорпа) т.к. разные OS имеют полноправный доступ к процессору,
и каждый из OS считает что имеет монопольный доступ, но процессор хитрый и обманывает все OS которые на нем работают.
Также есть оборудование которое также как и процессор предлагает виртуальную услугу серверные сетевые платы intel.
Кстати иногда эти опции можно увидеть в биосе (по поводу виртуального оборудования).
2 вариант тоже витруальная машина но при этом гостевая ос как зеркало совпадает с основной.
чаще всего такую услугу предлагают датацентрах т.к. меньше использует вычислительных мощностей ЦП
3 вариат является виртуальной машиной + эмулятором т.к. эмулирует периферию процессора(внешниие устройства).
к ТЕРМИНАМ язык программирования, интерпретатор, компилятор, среда исполнения, байт код, виртуальная машина
надо добавить
трансляцию, песочницу, дебагеры, КОНТЕЙНЕРЫ.
Текст длинный получился.
Попробую чуть позже написать про все эти термины и где лежит граница между терминами
Замечу что в браузере для javascript работает не виртуальная машина а контейнер.
Что CLR эмулирует? Он просто компилирует код. Там никакого понятия эмуляции не существут.
Прочитал. Где в CLR какая либо замена? CIL это язык, аналог ассемблера.
Опять же байт код выполняет не только Java, но и на питон и 1С и еще куча интерпритаторов. Если убрать JIT,
то по сути они тоже VM? Отличие от Java только в статической типизации и сборщике мусора.
трехадресный код это тоже VM
Так объясни мне где в .Net эмуляция, Весь код перед выполнением компилируется.
Ты так и не ответил про NGEN, Net Native.
Вот это и есть виртуальные машины, который выполняет код предназначенный для других Осей,процессоров.
В VS полно таких эмуляторо и бот они как раз и являются VM.
При этом код компилируется под определенную ось и процессор.
T>к ТЕРМИНАМ язык программирования, интерпретатор, компилятор, среда исполнения, байт код, виртуальная машина T>надо добавить T>трансляцию, песочницу, дебагеры, КОНТЕЙНЕРЫ.
Вот CLR это как раз среда выполнения, но в ней никакой эмуляции не происходит. Все компилируется в машинный код.
Эмуляция происходит только в Hyper-V T>Текст длинный получился. T>Попробую чуть позже написать про все эти термины и где лежит граница между терминами
T>Замечу что в браузере для javascript работает не виртуальная машина а контейнер.
А в чем различие? Уже есть WebAssembly по твоей териналогии тот же байт код.
WebAssembly определяет абстрактное синтаксическое дерево(AST), которое хранится в бинарном формате. Бинарность это здорово, так как позволяет создавать меньшие приложения. Наверняка вы задаетесь вопросом, как можно отлаживать бинарный код.
В: Почему бы не использовать JVM?
О: Попытки добавить JVM в браузеры с помощью плагинов были и не раз. К сожалению, ничего хорошего из этого не вышло. В JavaScript есть встроенная виртуальная машина, поэтому добавление еще одной приводит к появлению второго набора API подключений, чтобы дать виртуальной машине доступ к DOM, сетям, сенсорам, устройствам ввода и т.п. За это придется кое чем пожертвовать. Например, как будут процессы в виртуальной машине распределять между собой имеющиеся ресурсы? Ответить на этот вопрос сложнее, чем кажется.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, tranzit, Вы писали:
S> Что CLR эмулирует? Он просто компилирует код. Там никакого понятия эмуляции не существут.
.. S> Так объясни мне где в .Net эмуляция, Весь код перед выполнением компилируется.
.. S> Вот это и есть виртуальные машины, который выполняет код предназначенный для других Осей,процессоров. S> В VS полно таких эмуляторо и бот они как раз и являются VM. S> При этом код компилируется под определенную ось и процессор.
.. S> Вот CLR это как раз среда выполнения, но в ней никакой эмуляции не происходит. Все компилируется в машинный код.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, tranzit, Вы писали:
S> Что CLR эмулирует? Он просто компилирует код. Там никакого понятия эмуляции не существут.
CLR не компилирует ничего это среда исполнения для байт кода. т.е. эта среда содержит
виртуальную машину и вспомогательные утилиты и функции.
CLR не компилирует а исполняет байт код
S> Прочитал. Где в CLR какая либо замена? CIL это язык, аналог ассемблера. S>Опять же байт код выполняет не только Java, но и на питон и 1С и еще куча интерпритаторов. Если убрать JIT, S>то по сути они тоже VM? Отличие от Java только в статической типизации и сборщике мусора. S> трехадресный код это тоже VM
Совершенно верно любой байт код (код исполнения) является инструкцией машины следовательно кто-то должен исполнить
эту инструкцию но напрямую процессор не понимает, поэтому исполнение этой инструкции берет на себя виртуальная машина.
для каждого языка есть стандарт, так же как и стандарт для кода который получается путем компиляции.
Но нигде не говорится как должны компилироваться текст программы в код, ГЛАВНОЕ чтоб этот код был понимаем виртуальной машиной или процессором. Поэтому одни производители компиляторов лучше других т.к. генерируют код более оптимально.
Если этот код получен путем компиляции из языка java то и байт код может выполняться на виртуальной машине java.
если код был получен из .Net далее применен транслятор на язык CLI/CIL а к нему применили компилятор ilasm для получения байт кода CIL который будет исполняться в среде CLR который и содержит виртуальную машину CLR.
Если питон-то питон виртуальная машина исполняет байт код. Если Perl то виртуальная машина PERL исполняет
байт код. Если язык Erlang то компиляция erlang(в байт код) то виртуальная машина ERLANG выполняет этот код. Но нам все равно как CLR виртуальная машина будет выполнять этот код. Если хочет то пускай вызывает JIT для ускорения исполнения или сами запускайте ngen для компиляции из байт кода в машинный.
ТОЛЬКО не путайте CLR как среду исполнения (который может предлагать массу дополнительных утилит в том числе глубокую интеграцию с OS или с внешними библиотеками dll) и CLR как виртуальную машину которая исполняет CIL байт код.
Виртуальная машина CLR содержится в сред исполнения CLR и она для вас прозрачно т.к. вы взаимодействуете со средой
а не напрямую на виртуальную машину.
Но надо понимать различие между средой исполнения и контейнером, об этом чуть позже.
Я это говорю из-за того что CLR среда очень сильно подошла к понятию контейнер.
из WIKI
Common Language Runtime (англ. CLR — общеязыковая исполняющая среда) — исполняющая среда для байт-кода CIL (MSIL), в который компилируются программы, написанные на .NET-совместимых языках программирования (C#, Managed C++, Visual Basic .NET, F# и прочие). CLR является одним из основных компонентов пакета Microsoft .NET Framework.
В отличие от переносимых виртуальных машин Java, абстрагирующихся от нижележащих операционных систем, CLR позиционируется как не «виртуализированная» платформа, тесно связанная с операционной системой Microsoft Windows (в том числе для целей сохранения инвестиций Microsoft в операционную систему)[1]
Среда CLR является реализацией спецификации CLI (англ. Common Language Infrastructure), спецификации общеязыковой инфраструктуры компании Microsoft.
из WIKI
Common Intermediate Language (сокращённо CIL) — «высокоуровневый ассемблер» виртуальной машины .NET. Промежуточный язык, разработанный фирмой «Microsoft» для платформы .NET Framework.
как понимаем виртуальной машины .NET-не существует т.к. из языка .Net идет трансляция на язык CLI/CIL и потом компиляция в CIL байт код (а можно и напрямую в CIL байт код). следовательно виртуальная машина не .NET а CLR.
"Assembler" компилятор для языка CLI/CIL называется ilasm а на выходе CIL байт код. есть disassembler для CIL посмотрите проект mono.
ОБратите внимание мы говорим об assemblere который из текста программы на языке CLI/CIL(assembler) делает байт код CIL для виртуальной машины CLR
Читать инфу надо задумываясь.
Вы рассматриваете строго один из возможных вариантов исключая остальные
Давайте еще раз рассмотрим весь процесс.
Вы создаете программу на языке который имеет определенную структуры. Вы не можете произвольные инструкции
писать в тексте этой программы а должны придерживаться семантики и семантических структур.
Чаще всего языки программирования стандартизованы т.е. есть комитеты и масса людей которые принимают решения
о вводе новых или удалении старых семантических структур. Так рождается спецификация на язык программирования. Долгое время javascript, perl, и др. языки не были приняты международным комитетом
Далее производители процессоров создают свои компиляторы в первую очередь ассемблеры. и часто С/C++
эти компиляторы формируют код из ТЕКСТА программы в КОД машины. Процесс этот не регламентируется
главное требование чтоб код был исполняемым на процессоре и был как можно оптимален т.е. чтоб
выполнял как можно более передовые и оптимальные инструкции машины для увеличения производительности
например для x86_64 можно выполнять как одиночные команды сложения умножения так и для sse4 который
манипулирует 256bit регистрами и одна инструкция выполняет сразу действия над 4Хarg1 + 4xarg2 = 4 числа
для sse5 уже регистры имеют размер 512 бит и одна команда манипулирует уде 8 числами double float
производительность возврастает но только при условии что эти инструкции будут задействованы компилятором
Аналогично и с компиляторами байт кода, но байт код пока не меняется и виртуальная машина тоже
но виртуальная машина может выполнять инструкции байт кода как от своего имени и при этом задействует
новы возможности процессора или же может вызвать jit компиляцию. Но нам все равно как будет выполняться
эти виртуальные коды. Главное что мы может взять эти виртуальные коды и перенести на другую машину
и даже на машину с другой платформой(CPU+OS) и этот код должен выполняться.
CIL код должен так же исполняться на виртуальной машине CLR. Но проблема в Microsoft они не хотят
чтобы их клиенты которые покупают IDE уходили на другие платформы т.к. потеряют доход.
Т.к. сегодня opensource предлагает CLR среду https://habrahabr.ru/post/243065/ https://github.com/dotnet/core https://en.wikipedia.org/wiki/Mono_%28software%29
Не забываете что CLR был регламентирован как машинно независимый код.
Давайте теперь рассмотрим варианты компиляции
их очень много. Но сначала для Perl
1
после того как вы записали текст программы можно его выполнить
perl example.pl — в этом случает perl выступает как интерпретатор, но есть одно но. Дело в в том
что на лету perl формирует байт код в памяти (т.е. компиляция) и только потом ее исполняет.
но нам не интересно как выполняет perl текст написанный на языке perl, главное что мы передаем текст,
а perl интерпретатор выдает результат.
2
можно текст программы на perl скомпилировать в PERL байт код, например так
perl -MO=Bytecode,-H,-oexample.bl example.pl
в результате мы имеем PERL байт код и находится в файле example.bl
и если мы выполним инструкцию
perl example.bl — то perl программа уже выступает в роли PERL виртуальной машины которая исполняет PERL byte code
3
теперь попробуем выполнить следующую инструкцию perlcc (устанавливается отдельно)
perlcc -o example example.pl
perlcc скомпилирует example.pl в исполнимый файл на машинном коде
тогда ./example становится самоcтоятельным приложением и уже с perl никак не связан
4
мы можем выполнить следующую инструкцию
perlcc -c example.pl
на выходе будем иметь example.c и опять никак не связан уже с perl, данная
процедура называется трансляцией
5
если выполнить perljvm то получим из perl текста программы байт код для java виртуальной машины
и этот код надо будет выполнять уже на JAVA виртуальной машине а не PERL виртуальной машине
можно продолжать и далее, очень гибкий инструмент
Тоже самое можно делать и с "с/c++"
ну и чтоб совсем было весело с компиляторами можно рассмотреть gcc в качестве кросс компилятора
опции --build=x86_64 --host=sparc-sun-solaris2.10 --target=arm позволяют скомпилировать gcc на текущем компьютере например на x86_64 для sparc машины (т.е. программа gcc будет выполняться на spark) а компиляцию делать
для arm процессора
все это я привел для того чтобы было четкое понимание где текст программы, интерпретатор, виртуальная машина, транслятор
Теперь разберем .Net
перевод из одного языка в другой называется трансляцией
на самом деле можно трансляцию делать из одного языка в другой или из байт кода java в другой байт код
или из одного процессорного кода (бинарный уровень) в другой машинный код совершенно другого процессора.
например С текст программы можно преобразовать в assembler-ный текст программы
gcc -S -o exemple.s example.c
из машинного кода в другой машинный код objdump
или из перл в С
точно также .Net может сделать трансляцию на CLI/CIL(язык ассемблера)
далее применяя команду ilasm текст программы на assembler CIL в объектный код CIL
этот объектный код может выполнить CLR виртуальная машина возможно даже он применит
jit компиляцию (https://ru.wikipedia.org/wiki/JIT-%D0%BA%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%86%D0%B8%D1%8F)
прочтите доконца
Мы имеем CIL код(не путать с текстом на assembler CIL) но мы можем применить для этого кода команду
ngen для получения машинного кода. https://en.wikipedia.org/wiki/Native_Image_Generator https://ru.wikipedia.org/wiki/Ngen
но не забываем что можно сразу компилировать из любого языка CLI (https://en.wikipedia.org/wiki/List_of_CLI_languages) в CIL код
Также можно компилировать сразу в машинный код
ngen может компилировать и из текста программы на CIL assembler в машинный код
S> Так объясни мне где в .Net эмуляция, Весь код перед выполнением компилируется. S>Ты так и не ответил про NGEN, Net Native.
надеюсь ответил
S> Вот это и есть виртуальные машины, который выполняет код предназначенный для других Осей,процессоров. S> В VS полно таких эмуляторо и бот они как раз и являются VM. S> При этом код компилируется под определенную ось и процессор.
T>>к ТЕРМИНАМ язык программирования, интерпретатор, компилятор, среда исполнения, байт код, виртуальная машина T>>надо добавить T>>трансляцию, песочницу, дебагеры, КОНТЕЙНЕРЫ.
S> Вот CLR это как раз среда выполнения, но в ней никакой эмуляции не происходит. Все компилируется в машинный код.
да CLR есть виртуальная машина и нам не интересно что применяет jit компиляцию S>Эмуляция происходит только в Hyper-V T>>Текст длинный получился. T>>Попробую чуть позже написать про все эти термины и где лежит граница между терминами
T>>Замечу что в браузере для javascript работает не виртуальная машина а контейнере S> А в чем различие? Уже есть WebAssembly по твоей териналогии тот же байт код.
Совершенно верно это байт код и для выполнения нужна виртуальная машина WebAssembly который может применить jit компиляцию
некоторые люди уже попробовали запустить, сам пока не компилил https://habrahabr.ru/company/infopulse/blog/304362/
S>
S>WebAssembly определяет абстрактное синтаксическое дерево(AST), которое хранится в бинарном формате. Бинарность это здорово, так как позволяет создавать меньшие приложения. Наверняка вы задаетесь вопросом, как можно отлаживать бинарный код.
S>В: Почему бы не использовать JVM?
S> О: Попытки добавить JVM в браузеры с помощью плагинов были и не раз. К сожалению, ничего хорошего из этого не вышло. В JavaScript есть встроенная виртуальная машина, поэтому добавление еще одной приводит к появлению второго набора API подключений, чтобы дать виртуальной машине доступ к DOM, сетям, сенсорам, устройствам ввода и т.п. За это придется кое чем пожертвовать. Например, как будут процессы в виртуальной машине распределять между собой имеющиеся ресурсы? Ответить на этот вопрос сложнее, чем кажется.
Для javascript уже давно делают контейнер(а не встроенная виртуальная машина) который содержит javascript виртуальную машину и jit
Здравствуйте, pilgrim_, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, tranzit, Вы писали:
S>> Что CLR эмулирует? Он просто компилирует код. Там никакого понятия эмуляции не существут. _>.. S>> Так объясни мне где в .Net эмуляция, Весь код перед выполнением компилируется. _>.. S>> Вот это и есть виртуальные машины, который выполняет код предназначенный для других Осей,процессоров. S>> В VS полно таких эмуляторо и бот они как раз и являются VM. S>> При этом код компилируется под определенную ось и процессор. _>.. S>> Вот CLR это как раз среда выполнения, но в ней никакой эмуляции не происходит. Все компилируется в машинный код.
_>Для кругозора:
_>Например есть вот такой CLR для .NET Micro Framework
_>https://github.com/NETMF/netmf-interpreter
_>Вот тут есть обсуждение по поводу AOT и JIT, + AOT для MSIL -> IR (intermediate represenation) — https://github.com/NETMF/llilum
Спасибо я знаю. Изначально речь шлп про .Net. Когда сказали, что .Net включает в себя .Net Native, то стали говорить, что имели ввиду CLR/
Кстати CLR для микрофреймворка называется TinyCLR
Runtime Component Layer
Этот слой состоит из 3-х компонентов:
• .NET Micro Framework common language runtime (CLR);
• Hardware abstraction layer (HAL);
• Platform abstraction layer (PAL).
CLR
Среда исполнения .NET Micro Framework CLR (TinyCLR) является подмножеством .NET Framework CLR. TinyCLR отличается от «большой» CLR тем, что она была специально переработана для использования в небольших встраиваемых устройствах.
.Net Micro Framework Porting Kit поставляется вместе с исходными кодами TinyCLR. Данные коды представляют собой аппаратно-независимую библиотеку, которая может быть скомпилирована разными компиляторами для разных архитектур.
Здравствуйте, tranzit, Вы писали:
T>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, tranzit, Вы писали:
S>> Что CLR эмулирует? Он просто компилирует код. Там никакого понятия эмуляции не существут. T>CLR не компилирует ничего это среда исполнения для байт кода. т.е. эта среда содержит T>виртуальную машину и вспомогательные утилиты и функции. T>CLR не компилирует а исполняет байт код
То есть JIT компиляция, это не компиляция вовсе?
Еще раз как обстоит дела с NGEN, что выполняет 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.
• Образы NGEN, как правило, хрупкие. Например, обновление или изменение зависимости обычно требует, чтобы сборки, которые его используют, также были пересозданы NGEN. Это особенно верно для системных сборок в библиотеке классов .NET Framework. В противоположность этому .NET Native позволяет обслуживать приложения независимо друг от друга.
Читай выделенное. Все компилируется либо сразу либо во время выполнения.
S>> Прочитал. Где в CLR какая либо замена? CIL это язык, аналог ассемблера. S>>Опять же байт код выполняет не только Java, но и на питон и 1С и еще куча интерпритаторов. Если убрать JIT, S>>то по сути они тоже VM? Отличие от Java только в статической типизации и сборщике мусора. S>> трехадресный код это тоже VM
T>Совершенно верно любой байт код (код исполнения) является инструкцией машины следовательно кто-то должен исполнить T>эту инструкцию но напрямую процессор не понимает, поэтому исполнение этой инструкции берет на себя виртуальная машина. T>для каждого языка есть стандарт, так же как и стандарт для кода который получается путем компиляции. T>Но нигде не говорится как должны компилироваться текст программы в код, ГЛАВНОЕ чтоб этот код был понимаем виртуальной машиной или процессором. Поэтому одни производители компиляторов лучше других т.к. генерируют код более оптимально. T>Если этот код получен путем компиляции из языка java то и байт код может выполняться на виртуальной машине java. T>если код был получен из .Net далее применен транслятор на язык CLI/CIL а к нему применили компилятор ilasm для получения байт кода CIL который будет исполняться в среде CLR который и содержит виртуальную машину CLR. T>Если питон-то питон виртуальная машина исполняет байт код. Если Perl то виртуальная машина PERL исполняет
Еще раз NGEN нет там никакого байт кода. Другое дело, что CLR может подгрузить сборку и откомпилировать её например при reflection. Но если нет Рефлексии то и CLR ни какой байткодом не бедет исполнять.
ооооо. Теперь у нас все интерпритаторы стали VM. И трех адресный код это уже VM. Пишем интерпретатор трехадресного кода https://habrahabr.ru/post/117173/
T>байт код. Если язык Erlang то компиляция erlang(в байт код) то виртуальная машина ERLANG выполняет этот код. Но нам все равно как CLR виртуальная машина будет выполнять этот код. Если хочет то пускай вызывает JIT для ускорения исполнения или сами запускайте ngen для компиляции из байт кода в машинный.
То есть assembler это байт код? Тот же LLVM https://ru.wikipedia.org/wiki/Low_Level_Virtual_Machine
В основе LLVM лежит промежуточное представление кода (Intermediate Representation, IR), над которым можно производить трансформации во время компиляции, компоновки и выполнения. Из этого представления генерируется оптимизированный машинный код для целого ряда платформ, как статически, так и динамически (JIT-компиляция). LLVM 3.6 поддерживает статическую генерацию кода для x86, x86-64, ARM, PowerPC, SPARC, MIPS, Qualcomm Hexagon, NVPTX, SystemZ, Xcore. JIT-компиляция (генерация машинного кода во время исполнения) поддержана для архитектур x86, x86_64, PowerPC, MIPS, SystemZ, и частично ARM[4].
То есть статически скомпилированный LLVM или CIL в .Net Native это тоже VM?
T>ТОЛЬКО не путайте CLR как среду исполнения (который может предлагать массу дополнительных утилит в том числе глубокую интеграцию с OS или с внешними библиотеками dll) и CLR как виртуальную машину которая исполняет CIL байт код. T>Виртуальная машина CLR содержится в сред исполнения CLR и она для вас прозрачно т.к. вы взаимодействуете со средой T>а не напрямую на виртуальную машину. T>Но надо понимать различие между средой исполнения и контейнером, об этом чуть позже. T>Я это говорю из-за того что CLR среда очень сильно подошла к понятию контейнер.
Во наконец то. Еще раз CLR это среда выполнения. Она может вообще не иметь дела с CIL.
T>из WIKI
T>Common Language Runtime (англ. CLR — общеязыковая исполняющая среда) — исполняющая среда для байт-кода CIL (MSIL), в который компилируются программы, написанные на .NET-совместимых языках программирования (C#, Managed C++, Visual Basic .NET, F# и прочие). CLR является одним из основных компонентов пакета Microsoft .NET Framework.
T>В отличие от переносимых виртуальных машин Java, абстрагирующихся от нижележащих операционных систем, CLR позиционируется как не «виртуализированная» платформа, тесно связанная с операционной системой Microsoft Windows (в том числе для целей сохранения инвестиций Microsoft в операционную систему)[1]
T>Среда CLR является реализацией спецификации CLI (англ. Common Language Infrastructure), спецификации общеязыковой инфраструктуры компании Microsoft.
T>из WIKI T>
T>Common Intermediate Language (сокращённо CIL) — «высокоуровневый ассемблер» виртуальной машины .NET. Промежуточный язык, разработанный фирмой «Microsoft» для платформы .NET Framework.
T>как понимаем виртуальной машины .NET-не существует т.к. из языка .Net идет трансляция на язык CLI/CIL и потом компиляция в CIL байт код (а можно и напрямую в CIL байт код). следовательно виртуальная машина не .NET а CLR.
CLR это среда выполнения. А выполняется не байт код, а скомпилированный код из него. Это может быть заранее скомпилированный код. В том числе и для .Net Native где СДК не используется.
CIL это просто язык.
T>"Assembler" компилятор для языка CLI/CIL называется ilasm а на выходе CIL байт код. есть disassembler для CIL посмотрите проект mono. T>ОБратите внимание мы говорим об assemblere который из текста программы на языке CLI/CIL(assembler) делает байт код CIL для виртуальной машины CLR T>Читать инфу надо задумываясь.
TT>для linux T>https://en.wikipedia.org/wiki/Mono_%28software%29 T>https://github.com/dotnet/coreclr T>http://www.mono-project.com/
Вот ты бы сам ссылки почитал, а то утверждаешь, что .Net только для Windows
T>Давайте теперь рассмотрим варианты компиляции T>их очень много. Но сначала для Perl
T>1 T>после того как вы записали текст программы можно его выполнить T>perl example.pl — в этом случает perl выступает как интерпретатор, но есть одно но. Дело в в том T>что на лету perl формирует байт код в памяти (т.е. компиляция) и только потом ее исполняет. T>но нам не интересно как выполняет perl текст написанный на языке perl, главное что мы передаем текст, T>а perl интерпретатор выдает результат.
T>2 T>все это я привел для того чтобы было четкое понимание где текст программы, интерпретатор, виртуальная машина, транслятор
T>точно также .Net может сделать трансляцию на CLI/CIL(язык ассемблера) T>далее применяя команду ilasm текст программы на assembler CIL в объектный код CIL T>этот объектный код может выполнить CLR виртуальная машина возможно даже он применит T>jit компиляцию (https://ru.wikipedia.org/wiki/JIT-%D0%BA%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%86%D0%B8%D1%8F) T>прочтите доконца T>Мы имеем CIL код(не путать с текстом на assembler CIL) но мы можем применить для этого кода команду T>ngen для получения машинного кода. T>https://en.wikipedia.org/wiki/Native_Image_Generator T>https://ru.wikipedia.org/wiki/Ngen
T>но не забываем что можно сразу компилировать из любого языка CLI (https://en.wikipedia.org/wiki/List_of_CLI_languages) в CIL код T>Также можно компилировать сразу в машинный код T>ngen может компилировать и из текста программы на CIL assembler в машинный код
Сборка обладает следующими свойствами.
• Содержит код, выполняемый общеязыковой исполняющей средой. При отсутствии манифеста сборки код на промежуточном языке MSIL, находящийся в переносимом исполняемом (PE) файле, выполняться не будет. Имейте в виду, что каждая сборка может иметь только одну точку входа (т. е. DllMain, WinMain или Main).
if (!CreateDelegate(domainId, L"SetDelegate", (INT_PTR*)&pSetDelegate)) return false;
// Передадим ссылки на нужные методы
pSetDelegate(ManagedDomainLoader::GetMem, ManagedDomainLoader::AddError);
Внутри .Net я получаю ссылки на статические методы
Где здесь VM? Выполнение машинного кода.
S>> Так объясни мне где в .Net эмуляция, Весь код перед выполнением компилируется. S>>Ты так и не ответил про NGEN, Net Native. T>надеюсь ответил
S>> Вот это и есть виртуальные машины, который выполняет код предназначенный для других Осей,процессоров. S>> В VS полно таких эмуляторо и бот они как раз и являются VM. S>> При этом код компилируется под определенную ось и процессор.
T>>>к ТЕРМИНАМ язык программирования, интерпретатор, компилятор, среда исполнения, байт код, виртуальная машина T>>>надо добавить T>>>трансляцию, песочницу, дебагеры, КОНТЕЙНЕРЫ.
S>> Вот CLR это как раз среда выполнения, но в ней никакой эмуляции не происходит. Все компилируется в машинный код. T>да CLR есть виртуальная машина и нам не интересно что применяет jit компиляцию S>>Эмуляция происходит только в Hyper-V T>>>Текст длинный получился. T>>>Попробую чуть позже написать про все эти термины и где лежит граница между терминами
T>>>Замечу что в браузере для javascript работает не виртуальная машина а контейнере S>> А в чем различие? Уже есть WebAssembly по твоей териналогии тот же байт код. T>Совершенно верно это байт код и для выполнения нужна виртуальная машина WebAssembly который может применить jit компиляцию T>некоторые люди уже попробовали запустить, сам пока не компилил T>https://habrahabr.ru/company/infopulse/blog/304362/
S>>
S>>WebAssembly определяет абстрактное синтаксическое дерево(AST), которое хранится в бинарном формате. Бинарность это здорово, так как позволяет создавать меньшие приложения. Наверняка вы задаетесь вопросом, как можно отлаживать бинарный код.
S>>В: Почему бы не использовать JVM?
S>> О: Попытки добавить JVM в браузеры с помощью плагинов были и не раз. К сожалению, ничего хорошего из этого не вышло. В JavaScript есть встроенная виртуальная машина, поэтому добавление еще одной приводит к появлению второго набора API подключений, чтобы дать виртуальной машине доступ к DOM, сетям, сенсорам, устройствам ввода и т.п. За это придется кое чем пожертвовать. Например, как будут процессы в виртуальной машине распределять между собой имеющиеся ресурсы? Ответить на этот вопрос сложнее, чем кажется.
T>Для javascript уже давно делают контейнер(а не встроенная виртуальная машина) который содержит javascript виртуальную машину и jit
WebAssembly это продолжение asm.js
asm.js — это подмножество JavaScript. Скрипты, написанные на этом подмножестве, подлежат эффективной компиляции: типы данных переменных определяются статически с использованием вывода типов. Используется в основном в качестве промежуточного языка для компиляции с таких языков как C/C++ и используется в связке с такими инструментами, как Emscripten или Mandreel.
AOT-компиляция значительно ускоряет выполнение скриптов, написанных с использованием asm.js (в частности, такие скрипты не зависят от сборщика мусора).
asm.js — это подмножество JavaScript. Скрипты, написанные на этом подмножестве, подлежат эффективной компиляции: типы данных переменных определяются статически с использованием вывода типов. Используется в основном в качестве промежуточного языка для компиляции с таких языков как C/C++ и используется в связке с такими инструментами, как Emscripten или Mandreel.
AOT-компиляция значительно ускоряет выполнение скриптов, написанных с использованием asm.js (в частности, такие скрипты не зависят от сборщика мусора).
Вот у кого мешанина в голове так это ....
и солнце б утром не вставало, когда бы не было меня
Советую еще раз прочитать, трудно найти информацию в инете которую я тут для вас расписал.
S>
S>asm.js — это подмножество JavaScript. Скрипты, написанные на этом подмножестве, подлежат эффективной компиляции: типы данных переменных определяются статически с использованием вывода типов. Используется в основном в качестве промежуточного языка для компиляции с таких языков как C/C++ и используется в связке с такими инструментами, как Emscripten или Mandreel.
S>AOT-компиляция значительно ускоряет выполнение скриптов, написанных с использованием asm.js (в частности, такие скрипты не зависят от сборщика мусора).
S>asm.js — это подмножество JavaScript. Скрипты, написанные на этом подмножестве, подлежат эффективной компиляции: типы данных переменных определяются статически с использованием вывода типов. Используется в основном в качестве промежуточного языка для компиляции с таких языков как C/C++ и используется в связке с такими инструментами, как Emscripten или Mandreel.
S>AOT-компиляция значительно ускоряет выполнение скриптов, написанных с использованием asm.js (в частности, такие скрипты не зависят от сборщика мусора).
S> Вот у кого мешанина в голове так это ....
может вы правы но вот разработчики с вами не согласны
официальный проект находится https://github.com/WebAssembly/design
попробуйте скачать
git clone https://github.com/WebAssembly/design.git
и не читайте разную ересь, всегда есть сайт разработчика для получения информации
У меня сложилось впечатление что вы еще настолько молоды и все у вас впереди
Будете черпать информацию только из принятых стандартов, только там вы найдете правильную информацию
Обсуждение далее нет смысла
Читайте всегда первоисточник
В CLR каждая функция (метод) представляет собой набор IL-команд и вся информация о ней хранится в метаданных модуля. При загрузке модуля для каждого его класса система CLR создает таблицу MethodTable, содержащую информацию о методах класса. Каждый метод класса описывается структурой MethodDesc, одно из полей которой содержит адрес скомпилированного метода в памяти (при выполненной JIT-компиляции метода), а другое содержит индекс в таблице MethodTable, по которому указан адрес переходника (thunk), содержимое которого изменяется в процессе выполнения в зависимости от того, скомпилирован метод или нет.
Первоначально (до выполнения JIT-компиляции) в качестве переходника выступает один из четырех т.н. precode переходников CLR: StubPrecode, FixupPrecode, RemotingPrecode или NDirectImportPrecode. Поскольку последний переходник используется только для вызова API-функций Windows, которые можно перехватить и напрямую, то его мы рассматривать не будем.
Основной задачей каждого из precode-переходников является передача адреса структуры MethodDesc,
определяющей используемый метод, внутренней функции ThePreStub (ThePreStubAMD64 для платформы x64, на рисунке отмечена как Stub), которая выполняет следующие задачи:
1.JIT-компиляция метода, идентифицируемого структурой MethodDesc;
2.установка указателя в структуре MethodDesc на сгенерированный native-код;
3.перезапись переходника таким образом, чтобы он осуществлял безусловный переход (jmp) на сгенерированный native-код;
4.выполнение сгенерированного native-кода.
Таким образом, в результате первоначального вызова целевого метода не только сгенерируется и выполнится код метода, но и изменится содержимое переходника, что приведет к прямому вызову сгенерированного native-кода при последующих вызовах метода.
Любой метод .NET, вызываемый из среды CLR, проходит через адрес в таблице MethodTable методов класса. Однако среда CLR предоставляет возможность вызова метода из неуправляемой среды С/С++. Для этого служат следующие функции: GetFunctionPointer класса RuntimeMethodHandle и GetFunctionPointerForDelegate класса Marshal. Адреса, возвращаемые указанными функциями, также являются адресами переходников, среди которых могут быть уже упомянутые StubPrecode, FixupPrecode и RemotingPrecode. В результате первоначального вызова метода происходит его компиляция и выполнение, при последующем вызове – прямой переход на сгенерированный код. При этом важным для нас является то, что для некомпилированного метода при вызове его как через таблицу методов, так и через возвращаемые упомянутыми функциями указатели, происходит вызов внутренней функции ThePreStub.
Что я могу лично, так это сделать свою платформу, с джитом и байткодами, которая по крайней мере не будет заниматься мозготраханьем "вам чёрный Форд какого цвета?". 
)
.jpg)
