не, думаю в 2100 там уже будет кубитное программировие и квантовая типизация динамических мета транзакций модов!
производителям невыгодно будет делать такие платы, ща под каждое поколение меняется сокет, чтобы новые покупали, будет еще хуже.
Ну так бери и сразу, какая проблема? От того, что ты повозмущаешься на богом забытом форуме, вряд ли что-то поменяется. Вообще говоря, так уже давно делается в CLR (.NET) и JVM (Java), можно, конечно, говорить о более низком уровне, чем байткод стековой ВМ, но есть ли в этом смысл, если это и так нормально работает и предоставляет достаточно нужной информации для JIT-компилятора. Ну и да, технически JIT может генерировать код для конкретного железа, на котором запущен, и проводить оптимизации исходя из этого, а после чего кэшировать нативный код, чтобы повторные его запуски были быстрее.
VM технически ограничены в своих программных моделях и не могут выйти за их рамки. Ближе всего приближение к этой идее произошло на мой взгляд с другой стороны - на линуксах. Там программа распространяется в исходниках готовых к компиляции и если ты достаточно красноглазен, то соберёшь её с нужными ключами компиляции конкретно под твой ксеон или бульдозер на полных раскочегарках и без всяких ограничений виртуальных машин. Но недостатков тоже прилично - только опенсорц так нормально может распространяться. Поэтому надо дать возможность так распространяться закрытому ПО - в виде плохо воспримчивом к тому чтобы можно было копаться в исходниках - вот я и говорю что бизнес в эту область впустит когда распространяться будет серединная фаза компиляции - абстрактное синтаксическое дерево где уже не будет названий переменных и функций - только суть происходящих операций запеченных в кросс-платформенный бинарник над которым последний этап компилятора уже сможет родить выполнимый код под конкретную платформу.
Rel В идеале создать такую ос, чтобы в ней не было места исполняемым файлам. Вместо них: тысячи исходников программ на java и .net которые бы автоматически собирались в байткод при запуске.
Не понял, чем ограничены? Если что и в CLR и в JVM есть JIT-компилятор соответствующего байткода. Основной недостаток в том, что какой-нибудь Генту таким образом будет добрую пару дней обновляться. Абстрактное синтаксическое дерево - это практически нигде не серединная фаза, может быть, только в каком-нибудь FreePascal'е. В большинстве компиляторов серединная фаза - это SSA (типа LLVM IR или GIMPLE в GCC). Но байткод стековой виртуальной машины, как CIL у дотнетов, чем не серединная фаза тебе? Разве что его просто декомпилировать, говоря в твоей парадигме.
alex_dz, чтобы не было зловредов в имуно-дефицитной среде виндовс. При открытии каждой программы, чтобы было маленькое окошко, для того, чтобы написать автору программы о багах буфер оверлов. Чтобы 'запускались' программы на всех языках погромирования, и для всех ос. Чтобы все было опенсорсным, а драйвера, генерировались на лету нейросетью...))
Это слишком долго объяснять. Если не знаешь почему на твоём андроиде игры которые все технологически работают под явой используют JNI чтобы быть конкурентными, то ей богу, я за пару слов не объясню. --- Сообщение объединено, 4 апр 2025 в 20:21 --- P.S. Подсказка: на мобилках если сильно трясти виртуальной машиной, то батарея садится раньше других и это пользователи остро и сразу чувствуют. ТЧК.
Так в чем суть флейма ? Петухоний по сути интерпретатор .... естественно он будет медленнее в десятки раз чем любой нормальный компилятор.(С) Ваш капитан очевидность. Где нужна реальна скорость пишут на С /С++ . Все библиотеки для Петухона где нужна скорость ...написанны на C/C++. Те же либы для нейросетей OpenCV ...Keras ... Tensor Flow. Чистый петухоний используют для прототипирования и как обертки для библиотек написанных на нормальных ЯП. А касаемо видео .. это вообще смешно. Из питончика дергает какую то там API из внешней библиотеки ... петухончик тут тупо врапер и на производительность вообще не влияет.
Не угадал. Тестируется код на питоне. По теме есть разьяснения. --- Сообщение объединено, 5 апр 2025 в 06:44 --- А по виртуальным машинам - это даже забавно - андроид изначально нацелился на ява-машину как основу выполнения для приложений аргументируя это тем, что на мобильных платформах мало памяти, поэтому виртуальная машина всё улучшит и ускорит грамотно распределяя память по приложениям - как только где то нехватка - фигак, можно же сборку мусора запустить и выбить много свободной памяти. Прямо гордились, что щас то вот заборем проблемы все мобильных устройств. Итог немного предсказуем - тормозящее говно с лагучим интерфейсом где по настоящему производительные приложения тупо вызывают через JNI .so-шки написанные на плюсах.
Я бы тебе предложил еще проверить, сколько из "тормозящего говна с лагучим интерфейсом" на чем построено, есть некоторая вероятность, что большая часть из них использует веб-технологии. Да и потом, мне наверное просто так повезло, что я довольно редко встречаю "тормозящее говно".
