Нужен ли PHP JIT-компилятор?

Question

[Vaalel]

Сейчас активно ведётся разработка JIT-компилятора для PHP командой разработчиков из Zend. Скорее всего уже к PHP8 он будет готов. Но очень часто слышу, что JIT для PHP ненужен и что из-за столь радикальных изменений, технология утратит былую популярность. Что думаете?

Comments

[DAGpro]

О каких изменениях и технологии идет речь?
Разве jit не должен сделать php просто быстрей?

Хейтеры php не хотят, чтоб php сохранял свои позиции в вебе? :)

[Vaalel]

DAGpro, переход от интерпретатора к jit-компилятору это не изменения?)

Хейтеры php не хотят, чтоб php сохранял свои позиции в вебе? :)

Свои позиции он медленно, но верно теряет последние лет 5.

[DAGpro]

Vaalel, Ну будет байткод или опкод( что там получается не знаю), будет хранится в памяти, вместо того, чтоб при каждом запросе интерпретироваться заново.
Чем это помешает программисту использовать php?

Ну немного может и потеряли, когда core-разработчики споткнулись при разработке php6, из-за того что решили делать его на utf16.
Но с выходом php7, как показывала статитиска hh.ru по вакансиям в статье на хабре , количество вакансий выросло в 2 раза(так же как и сам язык ускорился :)).
А с выпуском jit, который может так же раза в 2 ускорить, если не больше php, что покажет статистика :)

[Vaalel]

DAGpro, Намного больше чем в два раза)

[Interreto]

Достаточно прочитать в википедии что такое JIT-компиляция что бы не задавать таких вопросов.

[Johny Smith]

достаточно выучить английский язык чтобы интуитивно за 1 секунду понять что такое just in time, ТС его точно не знает, согласитесь

[Vaalel]

Достаточно прочитать вопрос чтобы не писать бред. Если сделают Jit — порог входа возрастёт резко. Отсутствие смерти скрипта заставит следить за памятью, а это мало у кого выходит хорошо. Именно про это я и спрашивал.

[Johny Smith]

Vaalel,

Достаточно прочитать вопрос

молодой человек, следите за тем что говорите, читаем свой же собственный вопрос:

ни одного слова о возрастающем пороге вхождения, об управлении памятью, ничего такого вы не упомянули.

Именно про это я и спрашивал.

тут по вашему телепаты собрались, мы что в ток-шоу "Тролльни Экстрасэнсов" играли?

[Vaalel]

Olek1, я кажется, спросил о том что думают другие о появлении jit в php, о том как измениться технология. Вы же меня начали учить английскому.

[Johny Smith]

куда вы идёте, в IT без английского, это днище, знали бы английский то понимали бы что такое JIT без вопросов

я кажется, спросил о том что думают другие о появлении jit в php, о том как измениться технология. Вы же меня начали учить английскому.

если вам кажется то креститься надо

[Vaalel]

Olek1, так, а кто вам сказал что у меня английский плохой?) И причем тут аббревиатура JIT? Я же не спрашивал, что такое jit, я же спросил как он повлияет на PHP)

[Vaalel]

Olek1,

ни одного слова о возрастающем пороге вхождения, об управлении памятью, ничего такого вы не упомянули.

Вы хотите чтобы я свой же вопрос отвечал?) Опять таки, я хотел услышать мысли других людей по этому поводу.

[Johny Smith]

Vaalel, вам лучше никто не ответит тех кто пилит его, но они не общаются на русском языке когда делают компиляторы, прямо спросить можно у них на форумах и на фринодах всякого рода, здесь же можно развести только пустые дискуссии и ни к чему так и не прийти. Или вам опять чтото показалось? лол

[Johny Smith]

Vaalel, нужна ли вам ферарри в гараже вместо жигуля "если надо переучиваться", "выше порог входа" и сложнее управляемость?

лол

Answer 1

[Александр Таратин]

Когда в браузерах появился jit для js, для фронтенд разработчиков ничего не изменилось - все осталось под капотом браузера.
Для php разрабов тоже координально ничего не изменится.

Comments

[Vaalel]

Вы же понимаете что с jit скрипт умирать уже не будет, придется следить за памятью?

[Александр Таратин]

Vaalel, Есть различные варианты реализации Jit. Не смотрел как именно сейчас в php пилят. Скорее всего, как сейчас кешируются op коды zendvm, также в будущем будут кешироваться результаты jit компиляции между вызовами скриптов.

Answer 2

[asd111]

Так ведь есть уже. HHVM называется, там даже язык есть в виде улучшенного PHP - Hack называется.

Comments

[Vaalel]

Огромный костыль, который был актуален для фейсбука во времена 5.х, но не сейчас. 7 сравнялась по скорости с HHVM.

[DAGpro]

Vaalel, А чем костыль? Я про hack ничего не знаю, но раз фреймворки на php его поддерживали, это был тот же php, только с плюшками.

[Vaalel]

DAGpro, я имел ввиду виртуальную машину, а не Hack. Им нужно было сохранить кодовую базу и при этом ускорить тот же код, поэтому и изворачивались как могли. Тот же случай и с kPHP.

[asd111]

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 пишут редко, поэтому это мало кому интересно.

[ktulhu]

Парни, сами HHVM-щики все давно расписали.

И впредь HHVM будет совместим и "паразитировать" на экосистеме PHP7. И HHVM - это не про скорость на текущий момент, хотя когда-то скорость была основополагающей причиной создания. Все ребята расписали, решать за них - моветон.

Answer 3

[noce_toster]

Если сохранится простота в деплое, то однозначно Jit не помешает. Чуваки из Zend уже показали, что умеют в оптимизацию и производительность, поэтому с Jit, думаю, все будет хорошо.