производителям невыгодно будет делать такие платы, ща под каждое поколение меняется сокет, чтобы новые покупали, будет еще хуже.
Ну так бери и сразу, какая проблема? От того, что ты повозмущаешься на богом забытом форуме, вряд ли что-то поменяется. Вообще говоря, так уже давно делается в CLR (.NET) и JVM (Java), можно, конечно, говорить о более низком уровне, чем байткод стековой ВМ, но есть ли в этом смысл, если это и так нормально работает и предоставляет достаточно нужной информации для JIT-компилятора. Ну и да, технически JIT может генерировать код для конкретного железа, на котором запущен, и проводить оптимизации исходя из этого, а после чего кэшировать нативный код, чтобы повторные его запуски были быстрее.
VM технически ограничены в своих программных моделях и не могут выйти за их рамки. Ближе всего приближение к этой идее произошло на мой взгляд с другой стороны - на линуксах. Там программа распространяется в исходниках готовых к компиляции и если ты достаточно красноглазен, то соберёшь её с нужными ключами компиляции конкретно под твой ксеон или бульдозер на полных раскочегарках и без всяких ограничений виртуальных машин. Но недостатков тоже прилично - только опенсорц так нормально может распространяться. Поэтому надо дать возможность так распространяться закрытому ПО - в виде плохо воспримчивом к тому чтобы можно было копаться в исходниках - вот я и говорю что бизнес в эту область впустит когда распространяться будет серединная фаза компиляции - абстрактное синтаксическое дерево где уже не будет названий переменных и функций - только суть происходящих операций запеченных в кросс-платформенный бинарник над которым последний этап компилятора уже сможет родить выполнимый код под конкретную платформу.
Rel В идеале создать такую ос, чтобы в ней не было места исполняемым файлам. Вместо них: тысячи исходников программ на java и .net которые бы автоматически собирались в байткод при запуске.
Не понял, чем ограничены? Если что и в CLR и в JVM есть JIT-компилятор соответствующего байткода. Основной недостаток в том, что какой-нибудь Генту таким образом будет добрую пару дней обновляться. Абстрактное синтаксическое дерево - это практически нигде не серединная фаза, может быть, только в каком-нибудь FreePascal'е. В большинстве компиляторов серединная фаза - это SSA (типа LLVM IR или GIMPLE в GCC). Но байткод стековой виртуальной машины, как CIL у дотнетов, чем не серединная фаза тебе? Разве что его просто декомпилировать, говоря в твоей парадигме.
Это слишком долго объяснять. Если не знаешь почему на твоём андроиде игры которые все технологически работают под явой используют JNI чтобы быть конкурентными, то ей богу, я за пару слов не объясню. --- Сообщение объединено, 4 апр 2025 --- P.S. Подсказка: на мобилках если сильно трясти виртуальной машиной, то батарея садится раньше других и это пользователи остро и сразу чувствуют. ТЧК.
Так в чем суть флейма ? Петухоний по сути интерпретатор .... естественно он будет медленнее в десятки раз чем любой нормальный компилятор.(С) Ваш капитан очевидность. Где нужна реальна скорость пишут на С /С++ . Все библиотеки для Петухона где нужна скорость ...написанны на C/C++. Те же либы для нейросетей OpenCV ...Keras ... Tensor Flow. Чистый петухоний используют для прототипирования и как обертки для библиотек написанных на нормальных ЯП. А касаемо видео .. это вообще смешно. Из питончика дергает какую то там API из внешней библиотеки ... петухончик тут тупо врапер и на производительность вообще не влияет.
Не угадал. Тестируется код на питоне. По теме есть разьяснения. --- Сообщение объединено, 5 апр 2025 --- А по виртуальным машинам - это даже забавно - андроид изначально нацелился на ява-машину как основу выполнения для приложений аргументируя это тем, что на мобильных платформах мало памяти, поэтому виртуальная машина всё улучшит и ускорит грамотно распределяя память по приложениям - как только где то нехватка - фигак, можно же сборку мусора запустить и выбить много свободной памяти. Прямо гордились, что щас то вот заборем проблемы все мобильных устройств. Итог немного предсказуем - тормозящее говно с лагучим интерфейсом где по настоящему производительные приложения тупо вызывают через JNI .so-шки написанные на плюсах.
Я бы тебе предложил еще проверить, сколько из "тормозящего говна с лагучим интерфейсом" на чем построено, есть некоторая вероятность, что большая часть из них использует веб-технологии. Да и потом, мне наверное просто так повезло, что я довольно редко встречаю "тормозящее говно".
Автор ещё под накинул. Теперь питухону никакой намбу не помог. Тут ещё можно на шейдерах попробовать.
Ну все, пора переходить на моджо или эль-петухон (lpython) или кто там еще быстрого петухона трудящимся обещал?
В течение последнего месяца разбираю код на С++, в Ида; вспоминаю одного мужика, который рассказывал что лучшая защита от Ав и реверса - ООП, мол при "умелом" написании наследования и интерфейсов, там черт ногу сломит, а то и две. Вот оно и есть. Умеючи мб и да, но большинство на плюсах пишут так, что куда там Си - там питон не обгонят.
M0rg0t, недавно встроенный антивирус стал ругаться на семпл времен хр для запуска ехе в памяти. Задумался, есть ли простой способ это верещание обойти, например через интерфейсы/наследование ради спорт. интереса.
Research, ну зависит, на что он ругается. Если на вызов апи то конечно нет, а если по сигнатурам, то да.
Кстати, тут можно ещё одну оптимизацию применить! Сложение косинусов. И убрать косинусы из цикла, скорость возрастёт даже питухоне. Надо только вручную. Кстати, это называется запекания текстур, только требования к памяти несколько возрастёт. Типа так: cos(res * 0.9 + amplitude) = cos(res * 0.9)*cos(amplitude)-sin(res * 0.9)*sin(amplitude)
Сделал, и... ФПС стал больше, ровно 200 кадров. Но прежний вариант выдавал 180, не сильно быстро, правда я использовал скалярные SSE, если использовать параллельные, то может это и ускорит код ещё больше. В прочим и так получилось в десять раз быстрей оригинала, у автора ноут(Ryzen 7 5800H) не сильно быстрей ряженки 3600Х, если не медленней в однопотоке. Хотя если переписать на тот же С++, может компилятор довольно тривиальный код лучше оптимизирует. Кстати, такая оптимизация ещё хороша для JS, для браузерных демок.
Попробовал сделать параллельные SSE операции, и получил те же 200 ФПС, это у меня версия 1.05. Откатил до 1.04, где я использовал просто скалярные SSE т.к. на них считать намного проще чем на FPU, немного оптимизировал код, и ФПС 210, вероятно компилятор сможет ещё больше в оптимизацию. Вывод, далеко не всегда целесообразно использовать параллельные SSE. Код получился довольно простым, значит компилятор С++ сможет очень хорошо оптимизировать, при этом нет нужды использовать интринстики SSE, так что рулит прежде всего оптимизация, при этом компилятор додумался использовать предвычисление функции mandelbrot, но не додумался убрать крайне тормозные косинусы из цикла, по факту около 90% времени занимают выполнения этих косинусов. Ещё можно попробовать помучить демку для браузера, JS вроде как быстрей питухона. ЗЫ Мой 666-й пост.
