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

V>> Это тот самый технологический тупик, который всех нас зажал в узкие рамки на ближайшие несколько десятилетий. В общей, вот этот груз "легаси-совместимости" на данном этапе невозможно никак перепрыгнуть. Это полная ж-па как она есть, сорри за обилие эпитетов. ))
CC>Мда, куча эмоций а толком ничего и не сказано.
CC>Задайся лучше вопросом почему никто не заморочился идеей перекомпиляции. По сути что P-code что машинный — один фиг, описание что надо сделать в итоге. Может потому что отличия не только в инструкциях?

Почему же "никто не заморочился"? Apple исполнял на своих PowerPC машинах код от M68k такой перетрансляцией при запуске.
Эльбрус (обсуждаемый в соседней ветке) транслирует коды x86 (от неизбежности, но делает же).
Есть qemu, в которой команды эмулируемого процессора переводятся в цепочки, которые затем JITʼятся в хозяйский процессор.
Но по любому скорость, конечно, падает по сравнению с тем, что было бы при чисто нативной компиляции. Из абстрактного кода было бы прямее.

CC>Чтобы получить максимум производительности на другой архитектуре надо писать логику, которая будет использовать преимущества этой архитектуры.

Так сейчас и компиляторы не используют все преимущества.
GCC, LLVM, например, делают такую арифметику, которая годится для архитектур, где нет вообще флагов условий (это как минимум MIPS, Alpha, RISC-V). Зато она легче транслируется на другие процессоры.

V>> И как раз в первую очередь в плане загружаемых "на лету" по-настоящему переносимых и безопасных приложений (и/или их частей), что должно было стать стандартом де-факто работы гипотетического "современного компьютера".
CC>Надеюсь никогда не станет. Ибо до сих пор где правильный кошерный бинарь: мало ест и работает быстро. Где байт-код — тормоза и пожирание памяти.
CC>Какая самая большая проблема в тех же браузерах? Правильно, Javascript.

С Javascript проблемы, по данным народа типа разработчиков V8, растут от затрат типа "определить тип данного при каждом вызове операции" и "каждое поле приходится пролукапить через два прототипа с хэш-функцией на каждом", и основные оптимизации идут на кэширование именно этих данных.
В языках типа Java, C# этих затрат уже нет, типы определены в байткоде (и JIT получает данные о них без дополнительных затрат), лукапы сразу переводятся в смещение от указателя на объект.

UPD:
CC> Дыра в безопасности зависит от ошибок в коде а не от бинарности.

От бинарности тоже. Невозможность проанализировать код на предмет того, куда он неположенно лезет, приводит к тому, что коду нельзя доверять. Код для виртуальной машины легче проконтролировать потому, что места ссылки на всякие внешние сущности легче огораживаются.

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

V>> Это тот самый технологический тупик, который всех нас зажал в узкие рамки на ближайшие несколько десятилетий. В общей, вот этот груз "легаси-совместимости" на данном этапе невозможно никак перепрыгнуть. Это полная ж-па как она есть, сорри за обилие эпитетов. ))
CC>Мда, куча эмоций а толком ничего и не сказано.
CC>Задайся лучше вопросом почему никто не заморочился идеей перекомпиляции. По сути что P-code что машинный — один фиг, описание что надо сделать в итоге. Может потому что отличия не только в инструкциях?

Почему же "никто не заморочился"? Apple исполнял на своих PowerPC машинах код от M68k такой перетрансляцией при запуске.
Эльбрус (обсуждаемый в соседней ветке) транслирует коды x86 (от неизбежности, но делает же).
Есть qemu, в которой команды эмулируемого процессора переводятся в цепочки, которые затем JITʼятся в хозяйский процессор.
Но по любому скорость, конечно, падает по сравнению с тем, что было бы при чисто нативной компиляции. Из абстрактного кода было бы прямее.

CC>Чтобы получить максимум производительности на другой архитектуре надо писать логику, которая будет использовать преимущества этой архитектуры.

Так сейчас и компиляторы не используют все преимущества.
GCC, LLVM, например, делают такую арифметику, которая годится для архитектур, где нет вообще флагов условий (это как минимум MIPS, Alpha, RISC-V). Зато она легче транслируется на другие процессоры.

V>> И как раз в первую очередь в плане загружаемых "на лету" по-настоящему переносимых и безопасных приложений (и/или их частей), что должно было стать стандартом де-факто работы гипотетического "современного компьютера".
CC>Надеюсь никогда не станет. Ибо до сих пор где правильный кошерный бинарь: мало ест и работает быстро. Где байт-код — тормоза и пожирание памяти.
CC>Какая самая большая проблема в тех же браузерах? Правильно, Javascript.

С Javascript проблемы, по данным народа типа разработчиков V8, растут от затрат типа "определить тип данного при каждом вызове операции" и "каждое поле приходится пролукапить через два прототипа с хэш-функцией на каждом", и основные оптимизации идут на кэширование именно этих данных.
В языках типа Java, C# этих затрат уже нет, типы определены в байткоде (и JIT получает данные о них без дополнительных затрат), лукапы сразу переводятся в смещение от указателя на объект.

UPD:
CC> Дыра в безопасности зависит от ошибок в коде а не от бинарности.

От бинарности тоже. Невозможность проанализировать код на предмет того, куда он неположенно лезет, приводит к тому, что коду нельзя доверять. Код для виртуальной машины легче проконтролировать потому, что места ссылки на всякие внешние сущности легче огораживаются. Это не абсолютная разница, но практически существенная.