Сейчас активно ведётся разработка JIT-компилятора для PHP командой разработчиков из Zend. Скорее всего уже к PHP8 он будет готов. Но очень часто слышу, что JIT для PHP ненужен и что из-за столь радикальных изменений, технология утратит былую популярность. Что думаете?
Vaalel, Ну будет байткод или опкод( что там получается не знаю), будет хранится в памяти, вместо того, чтоб при каждом запросе интерпретироваться заново.
Чем это помешает программисту использовать php?
Ну немного может и потеряли, когда core-разработчики споткнулись при разработке php6, из-за того что решили делать его на utf16.
Но с выходом php7, как показывала статитиска hh.ru по вакансиям в статье на хабре , количество вакансий выросло в 2 раза(так же как и сам язык ускорился :)).
А с выпуском jit, который может так же раза в 2 ускорить, если не больше php, что покажет статистика :)
Достаточно прочитать вопрос чтобы не писать бред. Если сделают Jit — порог входа возрастёт резко. Отсутствие смерти скрипта заставит следить за памятью, а это мало у кого выходит хорошо. Именно про это я и спрашивал.
молодой человек, следите за тем что говорите, читаем свой же собственный вопрос:
ни одного слова о возрастающем пороге вхождения, об управлении памятью, ничего такого вы не упомянули.
Именно про это я и спрашивал.
тут по вашему телепаты собрались, мы что в ток-шоу "Тролльни Экстрасэнсов" играли?
Olek1, так, а кто вам сказал что у меня английский плохой?) И причем тут аббревиатура JIT? Я же не спрашивал, что такое jit, я же спросил как он повлияет на PHP)
Vaalel, вам лучше никто не ответит тех кто пилит его, но они не общаются на русском языке когда делают компиляторы, прямо спросить можно у них на форумах и на фринодах всякого рода, здесь же можно развести только пустые дискуссии и ни к чему так и не прийти. Или вам опять чтото показалось? лол
Когда в браузерах появился jit для js, для фронтенд разработчиков ничего не изменилось - все осталось под капотом браузера.
Для php разрабов тоже координально ничего не изменится.
Vaalel, Есть различные варианты реализации Jit. Не смотрел как именно сейчас в php пилят. Скорее всего, как сейчас кешируются op коды zendvm, также в будущем будут кешироваться результаты jit компиляции между вызовами скриптов.
DAGpro, я имел ввиду виртуальную машину, а не Hack. Им нужно было сохранить кодовую базу и при этом ускорить тот же код, поэтому и изворачивались как могли. Тот же случай и с kPHP.
Vaalel, HHVM это всё таки не костыль, а главная причина по которой парни из Zend начали задумываться над скоростью PHP и над добавлением строгой типизации как в языке Hack(потому что hack очень похож на php). На момент php 5 разница между Zend и HHVM была больше чем в 2 раза, а в математических задачах больше чем в 10 раз. После выхода HHVM парни в Zend хотели сделать JIT для php на LLVM , но у них получилось медленнее чем HHVM и поэтому они пошли по другому пути и изменили базовые структуры данных и начали почти всё хранить на стэке через alloca что дало прирост примерно в 2 раза. На математических задачах HHVM всё ещё в 10 раз обходит Zend PHP за счет JIT, но математику на php пишут редко, поэтому это мало кому интересно.
И впредь HHVM будет совместим и "паразитировать" на экосистеме PHP7. И HHVM - это не про скорость на текущий момент, хотя когда-то скорость была основополагающей причиной создания. Все ребята расписали, решать за них - моветон.
Если сохранится простота в деплое, то однозначно Jit не помешает. Чуваки из Zend уже показали, что умеют в оптимизацию и производительность, поэтому с Jit, думаю, все будет хорошо.
