Планируете ли добавить поддержку Profile-Guided Optimization (PGO) в ваш компилятор (возможно переиспользуя LLVM инфраструктуру для этого) для повышения производительности итоговых программ?
Хотели поисследовать это как и LTO, и знаем что на простых тестах это даёт некоторый процент выйгрыша.
По моим ссылкам выше я вроде старался использовать достаточно уважаемые в среде БД бенчмарки, которые приближены к реальным кейсам, а не синтетике (тот же ClickBench). По всем этим бенчам, оптимизация инструкций через LTO/PGO очень даже работает даже без оптимизации блокировок и прочего.
PGO насколько помню вносит требование что расширения тоже должны быть собраны таким же или особым способом
Не слышал про такое требование ни в одном компиляторе и ни разу не сталкивался с таким на практике. Вы можете собрать PostgreSQL с PGO, но при этом модули могут отлично работать без PGO.
но лучше boost производительности дают именно улучшения кода с точки зрения алгоритмов и lock-free вещей.
Одно другому не мешает. Даже более эффективные алгоритмы улучшаются за счёт LTO/PGO, так как у компилятора больше информации для проведения оптимизаций. Например, в случае PGO, для вашего более эффективного алгоритма может лучше расставить инлайны и сделать намного более качественный branch prediction.
Пробовали оптимизировать работу PostgreSQL (ванильного или Shardman) при помощи пересборки с Profile-Guided Optimization (PGO)? Если да, то интересно было бы посмотреть на ваши результаты. По имеющимся бенчмаркам выглядит достаточно интересно: тык
Очень прошу зарепортить в апстрим данный баг, так как он звучит достаточно важным. Потому что если не зарепортите, то шанс на его починку намного меньше, чем с репортом :) Возможно, что дело не в баге, а в какой-то "скрытой" настройке или чём-то странном ещё.
На количество issue можете не ориентироваться особо - они могут быть разной приоритетности и тому прочее.
Именно для FTP сразу на ум не приходит ничего, кроме самописных скриптов по крону. Быстрый поиск дал вот такой плагин для fluentd: https://github.com/kzk/fluent-plugin-ftp . Но поциент-плагин скорее мёртв, чем жив.
Я ни в коем случае не ставил своей целью убедить кого-либо переходить на Vector. По проблемам, описанным в статье - это скорее уж анти-реклама, чего таить :)
Решение о том, нужен ли вам Vector в конкретно вашей ситуации - зависит исключительно от выбирающего, его контекста и множества других факторов. Я всего лишь подсвечиваю грабли, которые ждут вас, если вы таки подумаете в сторону вектора.
С другой стороны, Vector уже тоже достаточно известен-популярен - просто смотря с чем сравнивать.
на это ловятся все бездарные тупорылые дошколята, которые нажрались пропаганды и пошли блеять. Т.е. ЦА раста является дошколятский биомусор, который код писать не может
почему ЦА говнораста - это веб-обезьяны и бездарные докшоялта? Почему всё, что пишется - это всякая дристня, которую пишут на жс/дристоне/другой скриптухе?
ещё раз. Какой может быть с тобою "по делу", если ты жертва пропаганды? Ты не можешь существовать вне
в любом случае молодец
Зная вышеперечисленные факты (и многие другие), сложно воспринимать сравнение так называемого языка программирования Rust с чем-то нормальным всеръёз. Для более подробного и глубокого обсуждения рекомендую присоедениться к чату: https://t.me/proriv_zaparti2
Кстати и обычные STL контейнеры довольно просто можно сделать constexpr. Я занимался подобным патчингом libc++, когда готовил предложения по constexprфикации STL-ных контейнеров. Из минусов хочу отметить, что там по дороге нужно разметить как constexpr большую часть библиотеки. И ещё компилятор на тот момент (Clang trunk) очень часто уходил в ICE.
Порешал все проблемы с Conan путём перехода на Cargo, чего и всем советую ;)
Profile-Guided Optimization (PGO)
Планируете ли добавить поддержку Profile-Guided Optimization (PGO) в ваш компилятор (возможно переиспользуя LLVM инфраструктуру для этого) для повышения производительности итоговых программ?
По моим ссылкам выше я вроде старался использовать достаточно уважаемые в среде БД бенчмарки, которые приближены к реальным кейсам, а не синтетике (тот же ClickBench). По всем этим бенчам, оптимизация инструкций через LTO/PGO очень даже работает даже без оптимизации блокировок и прочего.
Не слышал про такое требование ни в одном компиляторе и ни разу не сталкивался с таким на практике. Вы можете собрать PostgreSQL с PGO, но при этом модули могут отлично работать без PGO.
Одно другому не мешает. Даже более эффективные алгоритмы улучшаются за счёт LTO/PGO, так как у компилятора больше информации для проведения оптимизаций. Например, в случае PGO, для вашего более эффективного алгоритма может лучше расставить инлайны и сделать намного более качественный branch prediction.
Пробовали оптимизировать работу PostgreSQL (ванильного или Shardman) при помощи пересборки с Profile-Guided Optimization (PGO)? Если да, то интересно было бы посмотреть на ваши результаты. По имеющимся бенчмаркам выглядит достаточно интересно: тык
SQLite можно ускорить и сильно проще: https://sqlite.org/forum/forumpost/19870fae957d8c1a?t=h
Не хотите ещё попробовать для пущего ускорения Vault попробовать законтрибутить в него сборку с Profile-Guided Optimization(PGO)? :)
Если вы интересуетесь вопросами ускорения программ, то могу посоветовать пересобрать PostgreSQL с Profile-Guided Optimization (PGO): https://ru.wikipedia.org/wiki/Profile-guided_optimization . Я собираю результаты применения PGO к разным приложениям (в том числе и БД) вот тут - https://github.com/zamazan4ik/awesome-pgo , с результатами для PostgreSQL можно ознакомиться здесь - https://github.com/zamazan4ik/awesome-pgo/blob/main/postrgresql_results.md .
Очень прошу зарепортить в апстрим данный баг, так как он звучит достаточно важным. Потому что если не зарепортите, то шанс на его починку намного меньше, чем с репортом :) Возможно, что дело не в баге, а в какой-то "скрытой" настройке или чём-то странном ещё.
На количество issue можете не ориентироваться особо - они могут быть разной приоритетности и тому прочее.
В апстрим зарепортили проблему? Если да, то можете дать ссылку на репорт, пожалуйста?
Хм, не знал о таком поведении. Спасибо! Плюс одни грабли для высоконагруженной среды :)
Оставлю для истории ссылку на большее количество материалов о PGO, вдруг кому интересно будет: https://github.com/ZaMaZaN4iK/awesome-pgo
Именно для FTP сразу на ум не приходит ничего, кроме самописных скриптов по крону. Быстрый поиск дал вот такой плагин для fluentd: https://github.com/kzk/fluent-plugin-ftp . Но поциент-плагин скорее мёртв, чем жив.
Я ни в коем случае не ставил своей целью убедить кого-либо переходить на Vector. По проблемам, описанным в статье - это скорее уж анти-реклама, чего таить :)
Решение о том, нужен ли вам Vector в конкретно вашей ситуации - зависит исключительно от выбирающего, его контекста и множества других факторов. Я всего лишь подсвечиваю грабли, которые ждут вас, если вы таки подумаете в сторону вектора.
С другой стороны, Vector уже тоже достаточно известен-популярен - просто смотря с чем сравнивать.
Зная вышеперечисленные факты (и многие другие), сложно воспринимать сравнение так называемого языка программирования Rust с чем-то нормальным всеръёз. Для более подробного и глубокого обсуждения рекомендую присоедениться к чату: https://t.me/proriv_zaparti2
Это что получается, обратно свой продакшн веб-сервисы с ржавы на С++ переписывать? :)
Рассматривался ли Matrix в качестве протокола для чата?
Кстати и обычные STL контейнеры довольно просто можно сделать constexpr. Я занимался подобным патчингом libc++, когда готовил предложения по constexprфикации STL-ных контейнеров. Из минусов хочу отметить, что там по дороге нужно разметить как constexpr большую часть библиотеки. И ещё компилятор на тот момент (Clang trunk) очень часто уходил в ICE.
О мертвых либо хорошо, либо никак.
Не хватает описания того, зачем собственно он вообще нужен ещё один такой.