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