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

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

N>>>Ну так если подробности архитектуры видны только системным программистам — авторам AOT/JIT генераторов — то что до этого остальным программистам?
lpd>>Если компилировать программы из промежуточного кода в коды процессора сразу после инсталляции, то ты прав. А JIT-компиляция уже не совсем прозрачна, т.к. усложняет процесс запуска программы.

N>Ты это усложнение и не заметишь. Поставил продукт в виде бинарников IL, файлов данных и т.п. — а старт бинарника по любому исполняет RTLD.
Мне больше всего не нравится отладка при JIT-компиляции. В нативном коде есть только исходник и бинарный код, причем второе легко сопоставить с первым. При JIT-компиляции добавляется промежуточный код, и уже не так просто понять что к чему без помощи VM, просто посмотрев и дизассемблировав память процесса.
Вроде как Linux потому и нравится программистам, что его можно разобрать на составляющие и отладить или заменить их. Промежуточный код же отдаляет низкоуровневые операции от пользователя. Хотя при написании высокоуровневых программ разница не столь значительна.

lpd>>Получается, проблема несовместимости осталась в 90х когда новые процессоры появлялись чаще.

N>Да, частично она решена. Но далеко не полностью.
Процессоры достигли хорошего уровня(если не максимума), и дальнейшее увеличение скорости нужно только на серверах, для процесса разработки(инженеров и дизайнеров) и для игр + для javascript. Причем игры все равно оптимизируют векторными инструкциями. Получается, промежуточный код решает только нишевые проблемы (софт для дизайнеров/проектировщиков).
Я же рассматриваю вопрос с позиций Linux, и для open source промежуточный код нужен как машине пятое колесо, решающее достаточно гипотетические проблемы процессоростроителей. Вот с компиляцией промежуточного кода в бинарный в момент установки приложения я бы не спорил, если бы разнообразие процессоров привело к необходимости распространения программ таким способом.