У нас была гипотеза, что Fargate за счёт легковесности стоит дороже EC2. Планировали перевести контейнеры на виртуалки EC2. Но, когда посчитали стоимость, оказалось, что Fargate стоит ровно столько же. Один из burstable инстансов (T) выходил чуть дешевле, но мы бы скорее всего упёрлись в CPU credits.
Я порекомендую разработку Романа Дворнова для работы с JSON: JSON Discovery. Кроме красивого вывода JSON она позволяет делать богатые отчеты на их основе.
тесты производительности с C++ без хотя бы опции "-O3"
Мы мерили с -O2, из тех соображений, что при -O3 компилятор уже жертвует размером файла ради скорости (если я ничего не путаю). -O2 ближе к тому, что будет в реальном проекте.
Более подробно «методика» тестирвоания описана в репозитории проекта github.com/andrnag/wasm_cpp_bench Мы не выкладывали ещё нативную реализацию (забежал вперед, как я уже сказал), но вычислительное ядро там то же самое, что и для wasm. Добавлена просто CLI обёртка и работа с файлами, за рамками измеряемого кода.
И правильно что удивило — там точно что-то не так. )
Очень даже может быть :-) Буду рад вашим замечаниям к коду проекта.
Если у вас там видео воспроизводится, то можно посмотреть различные латентности, особенно в 4K и со сложными кодеками. )
Да, если бы мы воспроизводили видео, то это был бы хороший стресс-тест. Но непосредственным воспроизведением видео занимается браузер с помощью HTML-элемента <video> и нативных кодеков.
Наша разработка только поставляет данные для браузерного плеера. Поэтому больше всего времени мы занимаемся пересылкой по сети.
Спасибо за развёрнутый комментарий и классную дискуссию.
Я действительно сильно забежал вперед анонсировав результаты нашего нативного теста, поэтому немного расскажу про него.
1. Исполняется тот же код, что в бенчмарке с графическими фильтрами.
2. Никаких особых оптимизаций в C++ мы не делали. Мы согласны с тем, что если покрутить правильные ручки у компилятора, то можно выжать совсем другие цифры.
3. Одна из этих ручек, например, SIMD, который мы не использовали. А для обработки изображений он значит многое. Хотя, на мой взгляд, это уже будет не совсем верное сравнение технологий. Другая весовая категория.
4. Мы очень бегло потестировали код, не проверили все кейсы. Именно поэтому я не стал включать результаты в доклад.
Лично я ожидал, что нативный код будет выполняться значительно быстрее Wasm. Но первые полученные результаты показали, что это не так. И это меня довольно сильно удивило. Планирую вернуться к этому бенчмарку позже.
Что касается нашего продукта, то все замеры производительности значат мало что, т.к. на сетевых задержках мы потеряем гораздо больше времени. Мы честно пытались найти хоть какой-то мало-мальски вычислительный код в продукте. Взяли например обработчик плейлистов. Но на реальных данных код выполняется микросекунды, поэтому бенчмаркать там нечего. К тому же, это совсем не критический участок кода.
Немного не так. Вы пишете программу, которая должна выдавать требуемый результат, при правильных входных данных. А также, должна коректно обрабатывать ошибочные входные данные.
Вы пишете тесты с корректными входными данными, в них проверяете что результат требуемый. Также, вы пишете тесты с невалидными входными данными, и в них проверяете, что программа не упала и корректно залогировала ошибку, например.
Как придумать с какими данными запускать вашу программу? Об это суть есть наука о тестировании ПО. Там придумали ряд методик и подходов, позволяющих с одной стороны покрыть всевозможные граничные случаи, а с другой стороны не наплодить миллион тестов.
Гарантирует ли это то, что вы покроете все возможные ошибочные сценарии и в продакшене ошибки не произойдет? Конечно же нет. И конечно же всё зависит от вашего опыта.
Как приблизиться к идеальному результату? Изучать тестирование. Практиковаться в написании тестов. Ну и писать новые тесты на те баги, которые у вас нашлись в продакшене.
Главная ценность модульных тестов в том, что вы автоматизируете регрессионное тестирование, а это значит, что вы сможете быстрее выкатывать релизы, и не бояться менять существующий код, например для рефакторинга.
В WebAssembly принципиально нет и никогда не будет доступа к системе. Доступ есть только к хосту, в случае веба это браузер. Поэтому нужно смотреть в сторону WebCrypto API и на основе него уже можно что-то соорудить.
Вы C# компилировали в Wasm? Расскажите об этом подробнее. Что вы использовали? Какие остались впечатления?
А, вас смущают Mangled имена? Emscripten поддерживает опцию компиляции -s DEMANGLE_SUPPORT, при включении которой в стектрейсах появляются уже размотанные имена.
Вот недавно появился такой конструктор: https://www.youtube.com/watch?v=QrkiJZKJfpY
Возможно. Но в нашем случае мы не хотели размещать больше одного контейнера на машине, чтобы не управлять этим дополнительным уровнем масштабирования.
Спасибо!
У нас была гипотеза, что Fargate за счёт легковесности стоит дороже EC2. Планировали перевести контейнеры на виртуалки EC2. Но, когда посчитали стоимость, оказалось, что Fargate стоит ровно столько же. Один из burstable инстансов (T) выходил чуть дешевле, но мы бы скорее всего упёрлись в CPU credits.
Интересное предложение, спасибо. С лямбдами вообще экспериментируем, но к этому сервису не прикладывали.
А Puppeteer на них заведётся? Он довольно требователен к окружению, т.к. поднимает настоящий Headless Chrome.
Привет! Спасибо за классную статью. А ты смотрел, что Фабрис Беллард сам делает с QEMU? Имею в виду проект JS Linux: https://bellard.org/jslinux/
Я работал в компании Инетра, которая его открыла. Мне очень нравится этот проект и я всячески стараюсь им помогать.
Там любой организатор может бесплатно сделать митап, если будет свободный вход.
Будете у нас в Новосибирске — приходите в гости!
chrome.google.com/webstore/detail/jsondiscovery/pamhglogfolfbmlpnenhpeholpnlcclo
Andrey Nagikh (Engineer 2009 РПиРПУ РЭФ НЭТИ Новосибирск Сибирь)
Олег. Моё почтение за вашу миссию.
Мы мерили с -O2, из тех соображений, что при -O3 компилятор уже жертвует размером файла ради скорости (если я ничего не путаю). -O2 ближе к тому, что будет в реальном проекте.
Более подробно «методика» тестирвоания описана в репозитории проекта github.com/andrnag/wasm_cpp_bench Мы не выкладывали ещё нативную реализацию (забежал вперед, как я уже сказал), но вычислительное ядро там то же самое, что и для wasm. Добавлена просто CLI обёртка и работа с файлами, за рамками измеряемого кода.
Очень даже может быть :-) Буду рад вашим замечаниям к коду проекта.
Да, если бы мы воспроизводили видео, то это был бы хороший стресс-тест. Но непосредственным воспроизведением видео занимается браузер с помощью HTML-элемента <video> и нативных кодеков.
Наша разработка только поставляет данные для браузерного плеера. Поэтому больше всего времени мы занимаемся пересылкой по сети.
Я действительно сильно забежал вперед анонсировав результаты нашего нативного теста, поэтому немного расскажу про него.
1. Исполняется тот же код, что в бенчмарке с графическими фильтрами.
2. Никаких особых оптимизаций в C++ мы не делали. Мы согласны с тем, что если покрутить правильные ручки у компилятора, то можно выжать совсем другие цифры.
3. Одна из этих ручек, например, SIMD, который мы не использовали. А для обработки изображений он значит многое. Хотя, на мой взгляд, это уже будет не совсем верное сравнение технологий. Другая весовая категория.
4. Мы очень бегло потестировали код, не проверили все кейсы. Именно поэтому я не стал включать результаты в доклад.
Лично я ожидал, что нативный код будет выполняться значительно быстрее Wasm. Но первые полученные результаты показали, что это не так. И это меня довольно сильно удивило. Планирую вернуться к этому бенчмарку позже.
Что касается нашего продукта, то все замеры производительности значат мало что, т.к. на сетевых задержках мы потеряем гораздо больше времени. Мы честно пытались найти хоть какой-то мало-мальски вычислительный код в продукте. Взяли например обработчик плейлистов. Но на реальных данных код выполняется микросекунды, поэтому бенчмаркать там нечего. К тому же, это совсем не критический участок кода.
Вы пишете тесты с корректными входными данными, в них проверяете что результат требуемый. Также, вы пишете тесты с невалидными входными данными, и в них проверяете, что программа не упала и корректно залогировала ошибку, например.
Как придумать с какими данными запускать вашу программу? Об это суть есть наука о тестировании ПО. Там придумали ряд методик и подходов, позволяющих с одной стороны покрыть всевозможные граничные случаи, а с другой стороны не наплодить миллион тестов.
Гарантирует ли это то, что вы покроете все возможные ошибочные сценарии и в продакшене ошибки не произойдет? Конечно же нет. И конечно же всё зависит от вашего опыта.
Как приблизиться к идеальному результату? Изучать тестирование. Практиковаться в написании тестов. Ну и писать новые тесты на те баги, которые у вас нашлись в продакшене.
Главная ценность модульных тестов в том, что вы автоматизируете регрессионное тестирование, а это значит, что вы сможете быстрее выкатывать релизы, и не бояться менять существующий код, например для рефакторинга.
Тем не менее, заслуг Беллара это ни сколько не умаляет.
Вы C# компилировали в Wasm? Расскажите об этом подробнее. Что вы использовали? Какие остались впечатления?
Так они и попадают в Sentry, от Debug-сборок. Выглядит это вот так.