Работа проделана огромная, вопрос лишь в том, насколько она релевантна поставленной задаче. Подавляющее большинство тестов относится к серверным задачам, при чём тут клиентские веб страницы, не совсем понятно.
Работа была интересна мне лично для понятия двух кейсов: 1) имеет ли смысл полностью переходить на WASM 2) в приложениях какого типа лучше использовать компиляцию под WASM, и где лучше оставить всё на JS - это главная причина.
По поводу того что большинство задач серверные - не соглашусь, вычисления - они везде вычисления, за время развития веба грань между клиентскими и серверными вычислениями извивается как змея.
В (46) для всех сборок указан одинаковый результат 0.014, при этом утверждается, что WASM в 13.07 раза быстрее.
Спасибо за внимательное прочтение! В тесте 46 вычисления во всех трёх столбцах выполнял один и тот же Wasm-модуль. Менялась сборка Flutter, которая его вызывала:
Flutter, собранный в JavaScript → вызывает Wasm-модуль → около 0,014 мс.
Flutter, собранный в Wasm ST → вызывает тот же модуль → около 0,014 мс.
Flutter, собранный в Wasm MT → вызывает тот же модуль → около 0,014 мс.
В тесте 45 все три сборки Flutter — JavaScript, Wasm ST и Wasm MT — вызывают одну и ту же JavaScript-функцию с BigInt.
Ускорение 13,07 раза относится к сравнению тестов 45 (JavaScript-функция с BigInt) и 46 (Wasm-функция с i64). И кстати, 13,07 - это медиана
Я бы сказал так - всё зависит от кейсов, в веб приложении, в некоторых кейсах однозначно WASM бьёт, но это узкие направления.
И, думаю, WASM на dart и WASM на C - это один и тот же WASM, т е профита не даст, но хорошо бы это проверить.
А насчёт надёжности, вряд-ли типа Rust, скорее стабильность кадров отрисовки в WASM лучше, т е именно производительность на один кадр, но не думаю, что он очень безопасный по памяти как Rust, хотя можно писать через Rust-Dart bridge или напрямую Rust->WASM.
А вот такой вопрос: кальций, цинк, медь и магний все двухвалентные и я часто вижу в интернете тексты типа сочетать их в одном приёме нельзя, но так же вижу довольно именитые минеральные добавки которые содержат именно все эти элементы в куче. Как с ними быть в сочетании?
Кликбейт вполне конкретен - СМИ в статье есть, причём даже игровые.
у меня нет полмиллиона аудитории как у автора, но у меня был такой же кейс, как у автора в заголовке: на инди продукте за неделю получил около тысячи желаний, поэтому с абсолютной точки зрения - никакого кликбейта не вижу.
а относительно: любой заголовок статьи - это немножко кликбейт для привлечения внимания.
и да, я согласен с автором, суть статьи не в заголовке, а в тексте. А то в последнее время очень умно стало не читать статью, но читать заголовок и комменты и делать из этого выводы о статье.
Конкретного кликбейта нет, статья как статья, всё вполне нормально, но это и есть та причина, по которой вас минусуют. Ошибка не в статье, а в ожиданиях: от токсичного в своем большинсте сообщества ждать адекватной оценки. Вспомните, как гадким утенком называли лебедя. Примерно так же выглядит статья без токсикоза среди токсикоза.
Оптимизация не проводилась не только на C++, все трое сравнивались на стандартных настройках, цифры на 600 запросах видно из таблицы. Если дарт заточить по оптимизации, то там тоже много магии получится.
я могу вам этот же синтетический тест прогнать на других языках программирования, как минимум на Дарте и на C++, но он не будет отражать реальное поведение приложений и различие в производительности этих языков
Один абзац из бенчмарков ничего не означает, прогоните тесты, будут видны реальные цифры + там по ссылке тест синтетический (SELECT 1 as ok), это не реальное поведение приложения с кучей бизнес логики и разнообразными сложными запросами. Это нельзя брать за эталон реальной производительности. Это далеко от реальности, Карл.
По крайней мере от авторизации и системы ролей я бы ничего большего не ожидал.
ABAC системы ролей - это далеко не просто дернуть инфу из одной таблицы, там очень много динамически меняющихся факторов.
Под небольшой нагрузкой разница не сильно ощутима - это да. C++ под высокой нагрузкой дал очень хорошие результаты и в среднем по памяти выигрыш в 3 раза, в выводе я об этом написал. Время транспорта в сети так же необходимо учитывать, т к это не локальное тестирование. Но неоднозначное удивление не только у вас. Я продолжаю тестировать на потери и другие кейсы, буду обновлять статью.
Статья показывает возможный прирост +14,4% в конкретном тесте, т е в одном кейсе, как я писал выше, но не доказывает такое ускорение PHP в среднем для Laravel/Symfony/WordPress, инфа с 0% improvement в другом кейсе в этой статье тоже есть.
Проект огромный, я не переписывал весь бэкенд, а попробовал переписать части, которые отвечают за авторизацию, систему ролей, расширенные операции в интерфейсе над сущностями и чат (он кстати на wss) между сотрудниками, это примерно 4 из 40 по объему кода, чтобы проверить, даст ли по факту значимое ускорение переписывание бэкенда на Дарт или C++. Проект на фронте полностью на Flutter, поэтому в качестве вариантов для сервера был выбран Дарт, а Drogon был выбран из-за своей нашумевшей производительности. Исходники показать не могу из-за политик, но ваше предположение об элементарных запросах к базе в данном случае не верно.
Факты будут или только слова? Выше по ссылке есть факт реальной производительности. Аргументы и факты газету помните?) так вот да, без фактов аргумент не достаточный. У меня на сервере стоят обе версии и в среднем работают примерно с одинаковой производительностью, 15 процентов оверхеда там не видно. Вот факты: https://kinsta.com/blog/php-benchmarks https://tideways.com/profiler/blog/php-benchmarks-8-5-vs-8-4-8-3-and-7-4 И я наблюдаю примерно такой же прирост в среднем.
Есть ещё WooCommerce: +33,07% и CodeIgniter: +54,37%, но там на PHP 8.5 существенно уменьшился размер возвращаемой страницы. Поэтому эти цифры нельзя приписывать чистому ускорению PHP. Grav - отдельный результат конкретного теста, переносить его на другие приложения нельзя.
Жду ваши факты.
отучайтесь говорить за всех.
это к предыдущему оратору
А я писал про сравнение с нодой, гошкой и растом.
Статья не про них. Определитесь с тем, кого вы считаете конкурентами PHP. Это не я с трудом воспринимаю, это вы в своем уме почему-то решили сравнивать PHP с нодой, гошкой и растом.
Всё условия теста и тестовый стенд я описал, вначале статьи, wasm сейчас не хуже js, просто для полного перехода пока нет необходимости
Работа была интересна мне лично для понятия двух кейсов:
1) имеет ли смысл полностью переходить на WASM
2) в приложениях какого типа лучше использовать компиляцию под WASM, и где лучше оставить всё на JS - это главная причина.
По поводу того что большинство задач серверные - не соглашусь, вычисления - они везде вычисления, за время развития веба грань между клиентскими и серверными вычислениями извивается как змея.
Спасибо за внимательное прочтение! В тесте 46 вычисления во всех трёх столбцах выполнял один и тот же Wasm-модуль. Менялась сборка Flutter, которая его вызывала:
Flutter, собранный в JavaScript → вызывает Wasm-модуль → около 0,014 мс.
Flutter, собранный в Wasm ST → вызывает тот же модуль → около 0,014 мс.
Flutter, собранный в Wasm MT → вызывает тот же модуль → около 0,014 мс.
В тесте 45 все три сборки Flutter — JavaScript, Wasm ST и Wasm MT — вызывают одну и ту же JavaScript-функцию с BigInt.
Ускорение 13,07 раза относится к сравнению тестов 45 (JavaScript-функция с BigInt) и 46 (Wasm-функция с i64). И кстати, 13,07 - это медиана
Я бы сказал так - всё зависит от кейсов, в веб приложении, в некоторых кейсах однозначно WASM бьёт, но это узкие направления.
И, думаю, WASM на dart и WASM на C - это один и тот же WASM, т е профита не даст, но хорошо бы это проверить.
А насчёт надёжности, вряд-ли типа Rust, скорее стабильность кадров отрисовки в WASM лучше, т е именно производительность на один кадр, но не думаю, что он очень безопасный по памяти как Rust, хотя можно писать через Rust-Dart bridge или напрямую Rust->WASM.
Скорее, флаттер работает, гугл работает, остальные нет
То есть правильная инструкция по применению продукции компании вызывает странное чувство?
А вот такой вопрос: кальций, цинк, медь и магний все двухвалентные и я часто вижу в интернете тексты типа сочетать их в одном приёме нельзя, но так же вижу довольно именитые минеральные добавки которые содержат именно все эти элементы в куче. Как с ними быть в сочетании?
у меня нет полмиллиона аудитории как у автора, но у меня был такой же кейс, как у автора в заголовке: на инди продукте за неделю получил около тысячи желаний, поэтому с абсолютной точки зрения - никакого кликбейта не вижу.
а относительно: любой заголовок статьи - это немножко кликбейт для привлечения внимания.
и да, я согласен с автором, суть статьи не в заголовке, а в тексте.
А то в последнее время очень умно стало не читать статью, но читать заголовок и комменты и делать из этого выводы о статье.
Да, это верно.
Конкретного кликбейта нет, статья как статья, всё вполне нормально, но это и есть та причина, по которой вас минусуют. Ошибка не в статье, а в ожиданиях: от токсичного в своем большинсте сообщества ждать адекватной оценки. Вспомните, как гадким утенком называли лебедя. Примерно так же выглядит статья без токсикоза среди токсикоза.
Два чая вам за истину!)
Создатели Дарта не отваливают взятки в Тиобе, поэтому язык не включают в список
Оптимизация не проводилась не только на C++, все трое сравнивались на стандартных настройках, цифры на 600 запросах видно из таблицы. Если дарт заточить по оптимизации, то там тоже много магии получится.
Что странного? Всё три стека сравнивались на стандартных настройках. Странно что phpшники так болезненно реагируют на вполне неплохой результат PHP.
я могу вам этот же синтетический тест прогнать на других языках программирования, как минимум на Дарте и на C++, но он не будет отражать реальное поведение приложений и различие в производительности этих языков
Один абзац из бенчмарков ничего не означает, прогоните тесты, будут видны реальные цифры + там по ссылке тест синтетический (SELECT 1 as ok), это не реальное поведение приложения с кучей бизнес логики и разнообразными сложными запросами. Это нельзя брать за эталон реальной производительности. Это далеко от реальности, Карл.
Cтатья не про LLM.
Контекст, выдернутый из общего - это не пруфы, а медицина тут не причем
ABAC системы ролей - это далеко не просто дернуть инфу из одной таблицы, там очень много динамически меняющихся факторов.
Под небольшой нагрузкой разница не сильно ощутима - это да. C++ под высокой нагрузкой дал очень хорошие результаты и в среднем по памяти выигрыш в 3 раза, в выводе я об этом написал. Время транспорта в сети так же необходимо учитывать, т к это не локальное тестирование. Но неоднозначное удивление не только у вас.
Я продолжаю тестировать на потери и другие кейсы, буду обновлять статью.
Статья показывает возможный прирост +14,4% в конкретном тесте, т е в одном кейсе, как я писал выше, но не доказывает такое ускорение PHP в среднем для Laravel/Symfony/WordPress, инфа с 0% improvement в другом кейсе в этой статье тоже есть.
Проект огромный, я не переписывал весь бэкенд, а попробовал переписать части, которые отвечают за авторизацию, систему ролей, расширенные операции в интерфейсе над сущностями и чат (он кстати на wss) между сотрудниками, это примерно 4 из 40 по объему кода, чтобы проверить, даст ли по факту значимое ускорение переписывание бэкенда на Дарт или C++. Проект на фронте полностью на Flutter, поэтому в качестве вариантов для сервера был выбран Дарт, а Drogon был выбран из-за своей нашумевшей производительности. Исходники показать не могу из-за политик, но ваше предположение об элементарных запросах к базе в данном случае не верно.
Факты будут или только слова? Выше по ссылке есть факт реальной производительности. Аргументы и факты газету помните?) так вот да, без фактов аргумент не достаточный. У меня на сервере стоят обе версии и в среднем работают примерно с одинаковой производительностью, 15 процентов оверхеда там не видно.
Вот факты:
https://kinsta.com/blog/php-benchmarks
https://tideways.com/profiler/blog/php-benchmarks-8-5-vs-8-4-8-3-and-7-4
И я наблюдаю примерно такой же прирост в среднем.
Есть ещё WooCommerce: +33,07% и CodeIgniter: +54,37%, но там на PHP 8.5 существенно уменьшился размер возвращаемой страницы. Поэтому эти цифры нельзя приписывать чистому ускорению PHP. Grav - отдельный результат конкретного теста, переносить его на другие приложения нельзя.
Жду ваши факты.
это к предыдущему оратору
Статья не про них. Определитесь с тем, кого вы считаете конкурентами PHP. Это не я с трудом воспринимаю, это вы в своем уме почему-то решили сравнивать PHP с нодой, гошкой и растом.
Думаю, нет)