Здравствуйте, Философ, Вы писали:
_>>Единственно стоит заметить, что это проблемы любого байт-кода, а не только .net. И в борьбе с этим пожалуй дальше всех продвинулась Java, благодаря их escape-анализу. Однако это всё равно всё полумеры, не решающие базовую проблему. Ф>Это проблемы JIT'ера, а не IL.
Это проблемы идеи "приложение — файл с байт-кодом". А соответственно если выкинуть эту идею, то и IL не особо нужен становится.
_>>На мой взгляд реальным универсальным решением была бы компиляция приложения при установке не пользовательскую машину. Т.е. разработчики генерируют байт-код (скажем какой-нибудь там llvm), а при инсталляции он превращается (с полноценной оптимизацией) в нормальный нативный. Ф>ngen?
Ну для начала я пока что не слышал про компилятор с приличной оптимизацией для .net. Естественно в теории он возможен (хотя многие части идеологии .net будут противоречить быстродействующему коду и до уровня того же C++ не добраться никогда, даже с максимально оптимизирующим компилятором, но это уже тема для другой дискуссии), но на данный момент с этим проблемы. Но даже если MS и сделают его, это всё равно только часть задачи. Кроме этого требуется соответствующая инфраструктура распространения. И пока что я не видел движений в этом направление. Есть отдельно обычный .net (распространение байт-кода) и отдельно в перспективе существует .net native (соответственно распространение машинных инструкций). А вот про инфраструктуру с распространением байт-кода, компилируемого при инсталляции — про такое у MS я не слышал. Хотя на других платформах примеров реализации подобной техники весьма не мало.
Здравствуйте, ·, Вы писали:
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 и избавь пользователей от ненужного ни им, ни тебе геморроя, а то и по воскресеньям начнут звонить.
Здравствуйте, 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>Хотя есть подозрение что там только заголовок файла разный.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, wraithik, Вы писали:
W>>Да хрен там. W>>Я так мелкую утилиту собрал для х64 (стоит по умолчанию, я на на шарпе пишу крайне редко), так эта гадина под Вынь 7 х86 не запустилась, проорав "я не х86". W>>Какая к черту разница какая битность в .НЕТе
W>>Хотя есть подозрение что там только заголовок файла разный.
S>http://rsdn.org/forum/flame.comp/6576282.1
Здравствуйте, 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. Я так и поступаю.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alexzzzz, Вы писали:
A>Стоит у пользователя 64-разрядная Ява, он программу запускает, а она не запускается. Ему что, обязательно знать, что проблема из-за того, что Явы, оказывается, бывают разные? Ну допустим так, но 64 ведь лучше, чем 32. Должно же работать. Или нужно 86-разрядную? Да он даже не знает, что такое Ява. Остров вроде, а может мотоцикл.
Реплика в сторону — однако же, что такое трамблёр, шрус, дром.ру, курс доллара и соединение металлопластика "под пресс" — этот пользователь таки выучил. Иногда после того, как лишился изрядного количества денег и нервов. И про яву выучит, не бином Ньютона.
Дополнительное следствие: чтобы пользователь быстрее учился, программа его должна ощутимо бить по голове.
·>Собственно напрямую. У майкрософта "здесь торчит изолента", не потому что байткод, а потому что в майкрософте фигню наиндусокодили с сабжем. В яве этого бреда нет и не надо. Битность таргет-платформы JVM вообще никак не относится к тому как компилится исходный код. Почему компилятору нужно знать во что транслируется байткод? Байткод при желании можно и в рантайме генерить, без всяких компиляторов.
Значит любая jvm программа будет запускать дольше аналого под .net.
S>>> Одна из основных причина это использование через интероп нативного кода
W>>Уроды. Вся фишка .НЕТа в том что ему по идее пофиг где исполняться, если есть необходимый фреймворк.
W>>Собирал я программку на Дельфе или С++ вопросов бы не было. S> Я когда на Win CE программировал, то там был голимый InterOP. S>Но если ты не используешь Интероп к библиотекам которые есть только для одной платформы, то можешь все собирать под AnyCPU. Я так и поступаю.
Пасиб. Хорошо на 1Ске, там пофиг на ЦПУ
Если бы я юзал где выход в неуправляемый код, то мне сразу понятно зачем ЦПУ указывать. А так они уроды.
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.
Я так понял, что без соотв. железа разработчики так и будут кувыркаться с битностью.
Здравствуйте, 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. Либо ограничение, не знаю как, вдруг возникло по ошибке. Если ты в этом уверен, убираешь ограничивающий флажок ручками взад и пользуешься.
Убираешь где?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
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. Либо ограничение, не знаю как, вдруг возникло по ошибке. Если ты в этом уверен, убираешь ограничивающий флажок ручками взад и пользуешься. ·>Убираешь где?
Ну где установлен (в библиотеке), там и убираешь. Логично вроде.
EP>>>>Речь о том, что нативные библиотеки могут быть только под одну платформу. Это уже несколько раз было озвучено выше
EP>>Например есть только x32 библиотека, купленная у стороннего поставщика N лет назад, со своей работой справляется на ура. ·>Ну запускай своё приложение на x32 vm. В чём проблема-то?
Этот флажок и есть подсказка запускать приложение на x32 VM, коей в грубом приближении и является wow64 подсистема
Как много веселых ребят, и все делают велосипед...
