Речь идёт сугубо о разработке игр на Go. Не бекендов, не чего-то консольного, а именно графических игр с клиентом (!) на Go. У нас нет графического редактора шейдеров, нет графической IDE для разработки игр (в отличие от других языков, где обычно таки есть хотя бы один движок с IDE, типа Godot, Unity, Game Maker, etc). А с библиотеками есть трудности при поиске эффективной либы: есть около 4-5 библиотек для поиска пути (A*, greedy BFS), но все они слишком неэффетивные и для игруше не годятся, где есть квант времени на фрейм и в него надо уложиться. Если хотите, я могу продолжить список, чего ещё не хватает, но думаю и без этого моё уточнение понятно.
Пожалуйста, не упускайте контекст из виду. Если вам интересно погрузиться в разработку игр на Go и пообщаться на эту тему, приглашаю в чатик: https://t.me/go_gamedev
Красивое. У меня очень мало опыта с шейдерами, поэтому почти всегда вместо лаконичного преобразования получается какое-то императивное шаманство с пикселями и кучей if/else. :)
Я могу ещё в статью что-нибудь из шейдеров закинуть (только не дублируя то, что уже есть в ebitengine примерах), если будут пожелания. При этом на звание хорошего шейдерописца я претендовать не могу, поэтому оптимальных решений не ждите. :)
Фаззер для PHP/KPHP не вполне доделан, так что рановато пока говорить о результатах. Там сейчас очень плохой раннер, которые запускает генератор и проверяет результаты, а генератор более-менее нормальный. Какие-то проблемы нашлись, но хотелось бы большего.
В нашем конкретном случае есть ещё проверка того, что output у программ, запущенных на двух реализациях (компилируемый KPHP и интерпретатор PHP), одинаковый.
Как в эту картину вписываются генераторы программ, типа csmith, gosmith, phpsmith? Они генерируют вход для компилятора/интерпретатора, а потом проверяют output и крашнулся ли он или нет.
ktest гоняет бенчмарки со включенным JIT-компилятором в режиме PHP. В целом, разрыв стал меньше, хотя KPHP теперь тоже оптимизациями обрастает. Если интересно на недавние сравнения посмотреть, можете глянуть https://habr.com/ru/company/vk/blog/698532/ Там есть бенчмарки и сравнение PHP8+ с KPHP на задаче шаблонизации.
Идея интересная, я не сталкивался с такими решениями. Возможно потому что никогда не генерировал из шаблонов мегабайты данных. Обычно даже десятки вложенных шаблонов создают относительно скромные объёмы текста.
В целом можно сделать возможность потоковой обработки результатов шаблонизации. Вопрос в том, где эти точки передачи данных вставлять. Если слишком часто - будут какие-то мелкие куски и высокий overhead на эту логику. А вообще было бы любопытно на каких-то больших объёмах глянуть, будет ли там прирост скорости или нет. Потому что для средних шаблонов я почти уверен, что писать всё в строку будет быстрее.
Я немного расширил статью. У меня спросили, почему в исходниках KTemplate используются phpdoc комментарии вместо тайпхинтов. Ответ в том, что тайпхинты в этом случае могут вызвать измеримое замедление (цифры приведены в статье). Для KPHP разницы, откуда брать информацию о типах, нет, поэтому типизацию я проверяю при компиляции в KPHP, а при запуске на PHP считаем, что проверять типы уже не нужно, пусть в рантайме хотя бы немного быстрее будет работать. Быстрее Twig для PHP оно всё равно не будет, но по крайней мере отставание можно сократить.
Ещё добавил опции JIT, использованные для бенчмарков. Я пробовал opcache.jit=1235 и некоторые другие комбинации, но on оказался лучше всех. Считаю, что это оптимальный и разумный default.
Занимательный факт: если использовать KPHP, а не PHP, то подгрузить новый шаблон или изменить существующий без перекомеляции будет очень проблематично, ведь эти PHP-скрипты станут частью бинарника.
Движки типа KTemplate как раз решают это ограничение. Они реализуют ту малую часть динамизма в рантайме, которая нужна для задачи динамической шаблонизации. Если динамичные шаблоны не нужны, то можно и другие решения рассмотреть. KTemplate тут играет роль маленького компилятора и интерпретатора, который умеет прямо во время исполнения что-то новое собрать и запустить.
Внутри рантайма KPHP использовать что-то, что использует стандартный аллокатор ("системный"), может быть чревато утечками памяти.
Например, исполнение кода может быть прервано сигналом при таймауте. В этом случае управление перейдёт обработчику сигнала, который потом через getcontext переключится в сетевой контекст и... исполнение прерванного кода никогда не продолжится. Деструкторы всяких std::regex вызваны не будут.
Для того, чтобы использовать динамическую аллокацию памяти подобного рода нужно или критическую секцию выставить, чтобы сигнал в этот момент не прилетел, либо подменять аллокатор на скриптовый (примеры кода можно найти в самом рантайме). Память скриптового аллокатора автоматически чистится при завершении запроса.
Оптимизации на низком уровне часто позволяют создавать эффективные фундаментальные блоки. Например, какие-нибудь библиотеки, производительность которых важна для работы систем. Если сам язык не позволяет такую написать на нём же, то придётся в случае PHP писать расширения. Для таких библиотек эффективные низкоуровневые оптимизации могут давать прирост выше, чем 10-15%.
KPHP интересен тем, что он позволяет многие такие фундаментальные вещи писать на самом же PHP и они будут приемлемы по производительности. Задача компилятора тут дать нужные оптимизации и распознавать идиомы.
Гнев - довольно сильное чувство. Забавно, что техническая статья может так триггерить.
Ваши нападки на меня и мою команду гнева у меня не вызывают, но вот демотивируют и вызывает некоторое удивление - да.
P.P.S. А потом участники таких проектов приходят на собеседование и не могут банально рассказать про то, как что такое BSS, TEXT, elf и чем отличается uint32_t* от void*. Зато они могут положить на лопатки 64 ядра с 5 ТБ ОЗУ на сборку проекта "рабасной" игры из ВК.
Как-то не очень похоже на "всем добра", какие-то осуждения и сомнения в квалификации. Для начала, я не считаю незнание чего-либо пороком, не знать что-то - это нормально. Я далеко не эксперт, но свой вклад сделал в более чем один компилятор (и язык программирования), сделал много статей и докладов, чтобы как-то делиться знаниями, веду более одного популярного open source проекта.
Ваши домыслы о людях, которых вы не знаете, весьма сомнительны на этом фоне. А ещё это не очень приятно и не вполне вежливо. Технологии и код подвергать критике - это ОК, за этим мы здесь и собрались. Но вот о людях так высказываться в этом контексте мне кажется лишним.
У всех бывает синдром самозванца и в целом быть уверенным в своих достижениях - это не так просто. Когда вы так обесцениваете всё, то лишь увеличиваете количество негатива. Вы же не думаете, что помогаете ими кому-то?
Меня уже больше, чем должна, напрягает подобная позиция некоторых хабравчан ("всё говно, вы дурачки, а вот у меня софт хороший"). Ваше мнение услышано, но если вы практически лично людей оскорбляете, то будьте готовы получить ответ.
Есть ещё одна, менее очевидная причина. Я общался с автором FFI в PHP, мы обсуждали проблемы, дизайн, производительность. Желание такое: лучше понять применимость этой фичи, увеличить её распространение, а потом улучшить производительность за счёт JIT и некоторых других трюков.
Если мы не будем говорить о FFI и делать на нём библиотеки, он всегда будет таким, какой есть.
В компилируемом KPHP полезно иметь возможность использовать динамические плагины.
Скриптовый язык - термин не точный, а скорее жаргон. Язык редко бывает интерпретируемым или компилируемым, это свойство реализации. PHP чаще всего используется с интерпретатором, а KPHP имеет только компилируемую реализацию. На KPHP можно писать десктопные приложения, игры и прочие серьёзные штучки (на PHP тоже можно, но коробочный дистрибутив в виде одного почти полностью статически слинкованного бинарника распространять там гораздо сложнее).
FFI Lua работает и там, и там. Если вы работали с компилируемыми языками, то понимаете, что там не так просто обеспечить расширяемость. Это или dlopen на отдельно собранные либы, либо встраивание какого-то интерпретатора. Вот FFI в PHP/KPHP - это как раз dlopen. И через него мы встраиваем Lua.
Так можно собрать KPHP приложение в бинарь, отдать заказчику как чёрную коробку, а расширяемость обеспечить через Lua скрипты. Так заказчику не нужны исходники приложения. Всё, что нужно - положить в правильное место скрипты.
Вообще примеров, где нативные приложения используют встроенные интерпретаторы много. Это почти все игровые движки, сервера приложений типа Nginx, софт для работы с изображениями и полно чего ещё.
Зачем же тогда нам Lua в PHP? Чаще всего, приложения на KPHP приятно тестировать на PHP. А ещё это оставляет нам простор для того, чтобы, в случае чего, было проще переходить туда-сюда, ведь наш код всегда валиден и там, и там.
Но это всё если отбросить образовательный момент. По FFI мало материалов, особенно таких нетривиальных. Неужели плохо, что их становится больше? Здесь и примеры как самому сделать, и готовая библиотека для подглядывания. :)
Вообще статья и так вышла довольно крупной и сложной, поэтому мне не хотелось дополнительно добавлять много букв об этой детали. 1-го предложения достаточно для тех, кто когда-нибудь пробовал делать нативные приложения расширяемыми. А если этого опыта нет, то это уже почти тема для отдельной статьи, ведь там больше одного подхода.
Сначала заранее прошу прощения за не очень доброжелательный тон моего сообщения. Буду честен, ваш комментарий мне настроения не поднял. Надеюсь, вы понимаете, что вы просто ткнули в меня палкой.
Мне не очень хотелось отвечать, потому что статья действительно старая это раз. А два - вы так говорите, как будто бы я перед тем, как что-то заявлять, не пробовал это. Я же жил какое-то время на emacs и кодил используя этот проект. Мне было интересно и удобно. Кому-то тоже понравилась идея. Разве этого не достаточно, чтобы ответить на ваше "зачем?"
autocomplete для Go тоже не сможет работать
Почему? Он вполне себе работал. Там был способ описать что-то типа стабов, чтобы го видел эти функции как внешние, а компилятор goism для них создавал нужные обёртки с учётом типизации.
статическая типизация Go (кстати проект Elsa - хороший статический анализатор для Elisp) работать не будет
Опять не понимаю, почему такой вывод? Возможно, я просто чего-то не понял.
У нас код транслироваться не будет, если там есть ошибки. А то, что в рантайме там уже не те представления - это деталь реализации. У вас на уровне машинного кода тоже нет типизации, но высокоуровневые языки как-то работают. Статическая типизация на то и статическая, что она на этапе компиляции известна и там мы с ней работает. Как рантайм это потом исполняет - отдельный вопрос.
Статические анализаторы лиспа, конечно, работать не будут. Но зачем они нужны, если для Go у нас больше анализаторов и есть коммерческие в том числе?
Серьезно, документация Go, которая вам нравится, не будет иметь смысла для Emacs
Документация того, что написано на elisp доступна напрямую не будет, но я выше писал про стабы. Стабы причём я программно генерил, через сам elisp. Ведь документация и сигнатуры доступны через сам emacs. И вот уже у нас из Go есть go to definition с документацией.
На всю stdlib Go тоже документация работает. Вопрос только в правильной компиляции stdlib.
На все пакеты для emacs, написанные на Go, тоже документация работала бы.
Лучше тогда awesome-ebitengine приводить в качестве примера.
Речь идёт сугубо о разработке игр на Go. Не бекендов, не чего-то консольного, а именно графических игр с клиентом (!) на Go. У нас нет графического редактора шейдеров, нет графической IDE для разработки игр (в отличие от других языков, где обычно таки есть хотя бы один движок с IDE, типа Godot, Unity, Game Maker, etc). А с библиотеками есть трудности при поиске эффективной либы: есть около 4-5 библиотек для поиска пути (A*, greedy BFS), но все они слишком неэффетивные и для игруше не годятся, где есть квант времени на фрейм и в него надо уложиться. Если хотите, я могу продолжить список, чего ещё не хватает, но думаю и без этого моё уточнение понятно.
Пожалуйста, не упускайте контекст из виду. Если вам интересно погрузиться в разработку игр на Go и пообщаться на эту тему, приглашаю в чатик: https://t.me/go_gamedev
Красивое.
У меня очень мало опыта с шейдерами, поэтому почти всегда вместо лаконичного преобразования получается какое-то императивное шаманство с пикселями и кучей if/else. :)
Я могу ещё в статью что-нибудь из шейдеров закинуть (только не дублируя то, что уже есть в ebitengine примерах), если будут пожелания. При этом на звание хорошего шейдерописца я претендовать не могу, поэтому оптимальных решений не ждите. :)
Доклад посмотрю, спасибо!
Фаззер для PHP/KPHP не вполне доделан, так что рановато пока говорить о результатах. Там сейчас очень плохой раннер, которые запускает генератор и проверяет результаты, а генератор более-менее нормальный. Какие-то проблемы нашлись, но хотелось бы большего.
В нашем конкретном случае есть ещё проверка того, что output у программ, запущенных на двух реализациях (компилируемый KPHP и интерпретатор PHP), одинаковый.
Как в эту картину вписываются генераторы программ, типа csmith, gosmith, phpsmith? Они генерируют вход для компилятора/интерпретатора, а потом проверяют output и крашнулся ли он или нет.
ktest гоняет бенчмарки со включенным JIT-компилятором в режиме PHP.
В целом, разрыв стал меньше, хотя KPHP теперь тоже оптимизациями обрастает.
Если интересно на недавние сравнения посмотреть, можете глянуть https://habr.com/ru/company/vk/blog/698532/
Там есть бенчмарки и сравнение PHP8+ с KPHP на задаче шаблонизации.
Идея интересная, я не сталкивался с такими решениями.
Возможно потому что никогда не генерировал из шаблонов мегабайты данных.
Обычно даже десятки вложенных шаблонов создают относительно скромные объёмы текста.
В целом можно сделать возможность потоковой обработки результатов шаблонизации. Вопрос в том, где эти точки передачи данных вставлять. Если слишком часто - будут какие-то мелкие куски и высокий overhead на эту логику. А вообще было бы любопытно на каких-то больших объёмах глянуть, будет ли там прирост скорости или нет. Потому что для средних шаблонов я почти уверен, что писать всё в строку будет быстрее.
Я немного расширил статью. У меня спросили, почему в исходниках KTemplate используются phpdoc комментарии вместо тайпхинтов. Ответ в том, что тайпхинты в этом случае могут вызвать измеримое замедление (цифры приведены в статье). Для KPHP разницы, откуда брать информацию о типах, нет, поэтому типизацию я проверяю при компиляции в KPHP, а при запуске на PHP считаем, что проверять типы уже не нужно, пусть в рантайме хотя бы немного быстрее будет работать. Быстрее Twig для PHP оно всё равно не будет, но по крайней мере отставание можно сократить.
Ещё добавил опции JIT, использованные для бенчмарков. Я пробовал
opcache.jit=1235и некоторые другие комбинации, ноonоказался лучше всех. Считаю, что это оптимальный и разумный default.Занимательный факт: если использовать KPHP, а не PHP, то подгрузить новый шаблон или изменить существующий без перекомеляции будет очень проблематично, ведь эти PHP-скрипты станут частью бинарника.
Движки типа KTemplate как раз решают это ограничение. Они реализуют ту малую часть динамизма в рантайме, которая нужна для задачи динамической шаблонизации. Если динамичные шаблоны не нужны, то можно и другие решения рассмотреть. KTemplate тут играет роль маленького компилятора и интерпретатора, который умеет прямо во время исполнения что-то новое собрать и запустить.
Небольшое предостережение для читателей.
Внутри рантайма KPHP использовать что-то, что использует стандартный аллокатор ("системный"), может быть чревато утечками памяти.
Например, исполнение кода может быть прервано сигналом при таймауте. В этом случае управление перейдёт обработчику сигнала, который потом через getcontext переключится в сетевой контекст и... исполнение прерванного кода никогда не продолжится. Деструкторы всяких
std::regexвызваны не будут.Для того, чтобы использовать динамическую аллокацию памяти подобного рода нужно или критическую секцию выставить, чтобы сигнал в этот момент не прилетел, либо подменять аллокатор на скриптовый (примеры кода можно найти в самом рантайме). Память скриптового аллокатора автоматически чистится при завершении запроса.
Оптимизации на низком уровне часто позволяют создавать эффективные фундаментальные блоки. Например, какие-нибудь библиотеки, производительность которых важна для работы систем. Если сам язык не позволяет такую написать на нём же, то придётся в случае PHP писать расширения. Для таких библиотек эффективные низкоуровневые оптимизации могут давать прирост выше, чем 10-15%.
KPHP интересен тем, что он позволяет многие такие фундаментальные вещи писать на самом же PHP и они будут приемлемы по производительности. Задача компилятора тут дать нужные оптимизации и распознавать идиомы.
Я человек простой: вижу статью про KPHP - скидываю ссылку на чатик сообщества.
https://t.me/kphp_chat
Автора статьи там уже вижу. ;)
Прочитал статью, но не нашёл ни ссылки на проект, ни названия. :)
Можете ссылкой поделиться?
P.S. - рад, что FFI вам оказался полезен.
Гнев - довольно сильное чувство. Забавно, что техническая статья может так триггерить.
Ваши нападки на меня и мою команду гнева у меня не вызывают, но вот демотивируют и вызывает некоторое удивление - да.
Как-то не очень похоже на "всем добра", какие-то осуждения и сомнения в квалификации. Для начала, я не считаю незнание чего-либо пороком, не знать что-то - это нормально. Я далеко не эксперт, но свой вклад сделал в более чем один компилятор (и язык программирования), сделал много статей и докладов, чтобы как-то делиться знаниями, веду более одного популярного open source проекта.
Ваши домыслы о людях, которых вы не знаете, весьма сомнительны на этом фоне. А ещё это не очень приятно и не вполне вежливо. Технологии и код подвергать критике - это ОК, за этим мы здесь и собрались. Но вот о людях так высказываться в этом контексте мне кажется лишним.
У всех бывает синдром самозванца и в целом быть уверенным в своих достижениях - это не так просто. Когда вы так обесцениваете всё, то лишь увеличиваете количество негатива. Вы же не думаете, что помогаете ими кому-то?
Меня уже больше, чем должна, напрягает подобная позиция некоторых хабравчан ("всё говно, вы дурачки, а вот у меня софт хороший"). Ваше мнение услышано, но если вы практически лично людей оскорбляете, то будьте готовы получить ответ.
Спасибо за внимание.
По традиции, продублирую ссылочку на сообщество KPHP:
https://t.me/kphp_chat
https://t.me/kphp_chat
Продублирую и тут ссылочку. В этом чатике собирается сообщество KPHP.
Разработчики компилятора там тоже есть.
Есть ещё одна, менее очевидная причина.
Я общался с автором FFI в PHP, мы обсуждали проблемы, дизайн, производительность.
Желание такое: лучше понять применимость этой фичи, увеличить её распространение, а потом улучшить производительность за счёт JIT и некоторых других трюков.
Если мы не будем говорить о FFI и делать на нём библиотеки, он всегда будет таким, какой есть.
В разделе "мотивация" старался описать. Вот:
Скриптовый язык - термин не точный, а скорее жаргон. Язык редко бывает интерпретируемым или компилируемым, это свойство реализации. PHP чаще всего используется с интерпретатором, а KPHP имеет только компилируемую реализацию. На KPHP можно писать десктопные приложения, игры и прочие серьёзные штучки (на PHP тоже можно, но коробочный дистрибутив в виде одного почти полностью статически слинкованного бинарника распространять там гораздо сложнее).
FFI Lua работает и там, и там. Если вы работали с компилируемыми языками, то понимаете, что там не так просто обеспечить расширяемость. Это или dlopen на отдельно собранные либы, либо встраивание какого-то интерпретатора. Вот FFI в PHP/KPHP - это как раз dlopen. И через него мы встраиваем Lua.
Так можно собрать KPHP приложение в бинарь, отдать заказчику как чёрную коробку, а расширяемость обеспечить через Lua скрипты. Так заказчику не нужны исходники приложения. Всё, что нужно - положить в правильное место скрипты.
Вообще примеров, где нативные приложения используют встроенные интерпретаторы много. Это почти все игровые движки, сервера приложений типа Nginx, софт для работы с изображениями и полно чего ещё.
Зачем же тогда нам Lua в PHP? Чаще всего, приложения на KPHP приятно тестировать на PHP. А ещё это оставляет нам простор для того, чтобы, в случае чего, было проще переходить туда-сюда, ведь наш код всегда валиден и там, и там.
Но это всё если отбросить образовательный момент. По FFI мало материалов, особенно таких нетривиальных. Неужели плохо, что их становится больше? Здесь и примеры как самому сделать, и готовая библиотека для подглядывания. :)
Вообще статья и так вышла довольно крупной и сложной, поэтому мне не хотелось дополнительно добавлять много букв об этой детали. 1-го предложения достаточно для тех, кто когда-нибудь пробовал делать нативные приложения расширяемыми. А если этого опыта нет, то это уже почти тема для отдельной статьи, ведь там больше одного подхода.
Сначала заранее прошу прощения за не очень доброжелательный тон моего сообщения. Буду честен, ваш комментарий мне настроения не поднял. Надеюсь, вы понимаете, что вы просто ткнули в меня палкой.
Мне не очень хотелось отвечать, потому что статья действительно старая это раз. А два - вы так говорите, как будто бы я перед тем, как что-то заявлять, не пробовал это. Я же жил какое-то время на emacs и кодил используя этот проект. Мне было интересно и удобно. Кому-то тоже понравилась идея. Разве этого не достаточно, чтобы ответить на ваше "зачем?"
Почему? Он вполне себе работал.
Там был способ описать что-то типа стабов, чтобы го видел эти функции как внешние, а компилятор goism для них создавал нужные обёртки с учётом типизации.
Опять не понимаю, почему такой вывод? Возможно, я просто чего-то не понял.
У нас код транслироваться не будет, если там есть ошибки. А то, что в рантайме там уже не те представления - это деталь реализации. У вас на уровне машинного кода тоже нет типизации, но высокоуровневые языки как-то работают. Статическая типизация на то и статическая, что она на этапе компиляции известна и там мы с ней работает. Как рантайм это потом исполняет - отдельный вопрос.
Статические анализаторы лиспа, конечно, работать не будут. Но зачем они нужны, если для Go у нас больше анализаторов и есть коммерческие в том числе?
Документация того, что написано на elisp доступна напрямую не будет, но я выше писал про стабы. Стабы причём я программно генерил, через сам elisp. Ведь документация и сигнатуры доступны через сам emacs. И вот уже у нас из Go есть go to definition с документацией.
На всю stdlib Go тоже документация работает. Вопрос только в правильной компиляции stdlib.
На все пакеты для emacs, написанные на Go, тоже документация работала бы.
Update: https://github.com/hajimehoshi/ebiten/issues/2143
Возможно, в ebiten появится какое-то API для более дружелюбного позиционирование текста.
Будем следить за обновлениями.