Решения принимаются сообществом PHP, принять RFC или нет.
Я сомневаюсь что у вк настолько специфичные потребности в изменениях в коде, которые будут работать только у них, и не принесут пользу сообществу, чтоб они решили отклонить RFC от вконтакте.
Сколько наблюдаю за предложениями RFC, к каждому RFC каждый высказывал свои замечания и по этим замечаниям правили RFC и спокойно проходило голосование. Если нет можно сделать расширение к PHP.
В PHP 7.4 добавили FFI с ним можно код на C++ использовать в PHP.
Если бы убедили команду что новые фичи имеют смысл
Процесс RFC вроде не сложный две недели для обсуждения плюсов и минусов предложения для улучшения, две недели для голосования, никаких сложностей не вижу, это если изменяется API PHP.
К тому же, будь у команды PHP хоть какой-то интерес к этому — они вполне могли и сами что-то взять — благо наработки open source, но этого не случилось.
У них же был транслятор в C++, что команда PHP могла взять из kphp? Новую версию только открыли.
Насколько знаю JIT для PHP разрабатывается еще с версии 7.0, за это время могли предложить улучшения, чтоб получить профит в их проекте.
Потому что компилятор, имея доступ ко всему коду (или значительной его части), «понимает» чего хочет разработчик и может применить оптимизации недоступные JIT.
Весь код необходимый для выполнения запроса будет доступен JIT и его компилятор может по максимуму оптимизировать. Зачем оптимизировать то, что не будет использовано в запросе?
Делать своё и для себя всегда быстрее чем делать для всех с учётом их интересов и ждать одобрения (причём без всяких гарантий его получения в итоге).
Делать одному дольше чем вдвоем. Если присоединились бы к команде core PHP, оптимизация и новые фичи в языке добавлялись бы гораздо быстрей.
А Так получается одно и тоже дублируется в разных форках PHP.
youROCK Почему JIT не сможет приблизиться по скорости коду на плюсах? Там и там компилируемый код, на плюсах заранее скомпилится, с jit на лету, на следующих запросах будет использоваться скомпилированные файлы из кэша.
Интересно сейчас посмотреть сравнение kphp с php8, а не 7.4
pronskiy Так автор поста пишет что потребовалось около двух лет, чтоб вдохнуть новую жизнь в kphp и плюс еще сколько лет сделать первую версию kphp и это только процедурный код, без ООП (или я что-то пропустил). Не похоже, что этот подход быстрей RFC в PHP.
Почему разработчики предпочитают создавать свой велосипед, вместо того, чтоб контрибьютить в PHP?
Может если приложили бы усилия для повышения производительности в PHP, jit появился бы на пару лет раньше и увеличил производительней языка. За следующие пару лет дооптимизировать jit до максимума производительности, и отпадет обходимость в использовании kphp и hiphop.
В твиттере Тейлор писал, что отказались от LTS из-за issue в симфони, чтоб в версии симфони 6.1 поднять требования до php 8.1
Под этот RFC https://wiki.php.net/rfc/partial_function_application первый шаг был.
Я сомневаюсь что у вк настолько специфичные потребности в изменениях в коде, которые будут работать только у них, и не принесут пользу сообществу, чтоб они решили отклонить RFC от вконтакте.
В PHP 7.4 добавили FFI с ним можно код на C++ использовать в PHP.
Процесс RFC вроде не сложный две недели для обсуждения плюсов и минусов предложения для улучшения, две недели для голосования, никаких сложностей не вижу, это если изменяется API PHP.
У них же был транслятор в C++, что команда PHP могла взять из kphp? Новую версию только открыли.
Насколько знаю JIT для PHP разрабатывается еще с версии 7.0, за это время могли предложить улучшения, чтоб получить профит в их проекте.
Весь код необходимый для выполнения запроса будет доступен JIT и его компилятор может по максимуму оптимизировать. Зачем оптимизировать то, что не будет использовано в запросе?
Делать одному дольше чем вдвоем. Если присоединились бы к команде core PHP, оптимизация и новые фичи в языке добавлялись бы гораздо быстрей.
А Так получается одно и тоже дублируется в разных форках PHP.
Интересно сейчас посмотреть сравнение kphp с php8, а не 7.4
pronskiy Так автор поста пишет что потребовалось около двух лет, чтоб вдохнуть новую жизнь в kphp и плюс еще сколько лет сделать первую версию kphp и это только процедурный код, без ООП (или я что-то пропустил). Не похоже, что этот подход быстрей RFC в PHP.
Может если приложили бы усилия для повышения производительности в PHP, jit появился бы на пару лет раньше и увеличил производительней языка. За следующие пару лет дооптимизировать jit до максимума производительности, и отпадет обходимость в использовании kphp и hiphop.
herbertograca.com/2017/07/03/the-software-architecture-chronicles