Сообщение Re[14]: 32/64/AnyCPU - что за @$^%$? от 10.10.2016 17:15
Изменено 10.10.2016 17:19 ·
Здравствуйте, 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 тоже под капотом получается ВНЕЗАПНО совсем не указатель. И дальше что?
В С++ понятие платформы — в стандарте языка, зачем это же в тащить в байткод, который собственно и создавался для того, чтобы обеспечить платформонезависимость?
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 тоже под капотом получается ВНЕЗАПНО совсем не указатель. И дальше что?
В С++ понятие платформы — в стандарте языка, зачем это же в тащить в байткод, который собственно и создавался для того, чтобы обеспечить платформонезависимость?
Re[14]: 32/64/AnyCPU - что за @$^%$?
Здравствуйте, 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 тоже под капотом получается ВНЕЗАПНО совсем не указатель. И дальше что?
В С++ понятие платформы — в стандарте языка, зачем это же в тащить в байткод, который собственно и создавался для того, чтобы обеспечить платформонезависимость?
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 тоже под капотом получается ВНЕЗАПНО совсем не указатель. И дальше что?
В С++ понятие платформы — в стандарте языка, зачем это же в тащить в байткод, который собственно и создавался для того, чтобы обеспечить платформонезависимость?