Здравствуйте, 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 ложно.

А ноги растут из JVM https://ru.wikipedia.org/wiki/Java_Virtual_Machine

Виртуальные машины Java обычно содержат Интерпретатор байт-кода, однако, для повышения производительности во многих машинах также применяется JIT-компиляция часто исполняемых фрагментов байт-кода в машинный код.

В CLR весь код компилируется при первом обращении к классу.

А что касается зачем нужны разные платформы то ответ дан здесь

http://rsdn.org/forum/flame.comp/6576282.1

Автор: Sinix
Дата: 09.10.16

Здравствуйте, 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-всемогутеры, эти универсальные решения менее эффективны, чем архитектура хорошо заточенная под конкретную задачу.

Здравствуйте, ·, Вы писали:

EP>>Играет. На x32 больше 2-4 GiB откусить не получится (без хаков типа PAE).
·>Понятно, но это не связано с байткодом.

Это связано с тем во что транслируется байткод, собственно сабжевый флажок это и контролирует.

EP>>А то что у Java проблема с созданием массива в 8млрд байт на x64 — это ортогонально
·>При наличии поддержки в vm — создашь, теоретически ограничений нет.
·>Хотя на практике, насколько я знаю, такой имплементации vm никто не делал, т.к. бессмысленно, проще взять 64-битное железо. А так я слыхал о реализациях jvm для 16 или даже 8-битных процов.

Ну да, я же говорю — без хаков. А с хаками да, можно — но там уже будет указатель не указатель, а некий синтезированный индекс, и соответствующие penalty и т.п.

Здравствуйте, 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 тоже под капотом получается ВНЕЗАПНО совсем не указатель. И дальше что?

Здравствуйте, 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 тоже под капотом получается ВНЕЗАПНО совсем не указатель. И дальше что?
В С++ понятие платформы — в стандарте языка, зачем это же в тащить в байткод, который собственно и создавался для того, чтобы обеспечить платформонезависимость?

Здравствуйте, 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 тоже под капотом получается ВНЕЗАПНО совсем не указатель. И дальше что?
·>В С++ понятие платформы — в стандарте языка, зачем это же в тащить в байткод, который собственно и создавался для того, чтобы обеспечить платформонезависимость?

Давай пруфлинк на то что это есть в байткоде, ты уже несколько раз это сказал на протяжении последних сообщений.

Здравствуйте, ·, Вы писали:

·>В яве этого бреда нет и не надо. Битность таргет-платформы 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>·>Наличие 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>>>·>Все эти оптимизации того что "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 реализацию.