Python против C++

не, думаю в 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-шки написанные на плюсах.