Насколько быстр Go? Симуляция миллионов частиц на смарт-ТВ
https://habr.com/ru/articles/953434/
Автор проверил производительность Go на практике — написал симуляцию миллионов частиц с мультиплеером, которая работает только на CPU, причём настолько легковесно, что запускается даже на смарт-телевизоре.
Задача: симулировать миллионы частиц, синхронизировать их между сотнями клиентов через WebSocket, но при этом не заставлять клиент ничего симулировать — только рисовать.
Подход как из GPU-программирования:
- Используется g-buffer из deferred shading: как там отвязывают количество полигонов от расчёта освещения, так и здесь количество частиц отвязывается от объёма передаваемых данных
- Сервер рендерит всё сам и отправляет клиентам готовые кадры-буферы
- Клиент просто рисует пиксели в canvas — работает везде, где есть браузер
- Стоимость передачи фиксирована разрешением экрана, а не числом частиц
Математика:
Для разрешения 1920×1080 при 1 бите на пиксель получается примерно 260 КБ на кадр. При 30 fps это около 7.8 МБ/с (≈ 62 Мбит/с) на одного клиента. На сервере с пропускной способностью 2.5 Гбит/с можно теоретически обслужить порядка 40 клиентов при Full HD, или 300+ клиентов при мобильных разрешениях (например, 640×360).
Оптимизации:
- Воркер-пулы вместо создания горутин в цикле — pprof показал, что создание горутин не бесплатное
- Lookup-таблицы для побитовых операций вместо прямой упаковки/распаковки — ускорило в разы
- Простой трюк с
- Двойная буферизация кадров, каналы для неблокирующей отправки, пул буферов
Результат: 2.5 миллиона частиц на 60 fps симуляции + 30 fps отправка клиентам. Работает на смарт-ТВ.
Попробовать можно тут: howfastisgo.dev
————
Статья очень крутая, рекомендую.
Автор честно признаётся в разочаровании: Go без SIMD в чистых вычислениях проигрывает даже JavaScript, не говоря уж про Rust (который на одном ядре обошёл Go на восьми).
Но Go и не позиционируется как язык для тяжёлых вычислений — он про сетевые сервисы и конкурентность.
Мне понравился подход с g-buffer'ом — изящное решение проблемы масштабирования. Дельта-кодирование с зигзаг-кодированием в итоге забросили из-за сложности кода, но это правильный выбор — иногда простота важнее оптимальности.
#article #performance #websocket
https://habr.com/ru/articles/953434/
Автор проверил производительность Go на практике — написал симуляцию миллионов частиц с мультиплеером, которая работает только на CPU, причём настолько легковесно, что запускается даже на смарт-телевизоре.
Задача: симулировать миллионы частиц, синхронизировать их между сотнями клиентов через WebSocket, но при этом не заставлять клиент ничего симулировать — только рисовать.
Подход как из GPU-программирования:
- Используется g-buffer из deferred shading: как там отвязывают количество полигонов от расчёта освещения, так и здесь количество частиц отвязывается от объёма передаваемых данных
- Сервер рендерит всё сам и отправляет клиентам готовые кадры-буферы
- Клиент просто рисует пиксели в canvas — работает везде, где есть браузер
- Стоимость передачи фиксирована разрешением экрана, а не числом частиц
Математика:
Для разрешения 1920×1080 при 1 бите на пиксель получается примерно 260 КБ на кадр. При 30 fps это около 7.8 МБ/с (≈ 62 Мбит/с) на одного клиента. На сервере с пропускной способностью 2.5 Гбит/с можно теоретически обслужить порядка 40 клиентов при Full HD, или 300+ клиентов при мобильных разрешениях (например, 640×360).
Оптимизации:
- Воркер-пулы вместо создания горутин в цикле — pprof показал, что создание горутин не бесплатное
- Lookup-таблицы для побитовых операций вместо прямой упаковки/распаковки — ускорило в разы
- Простой трюк с
p := &particles[i] вместо particles[i].x дал +30% за счёт меньшего числа bounds checks- Двойная буферизация кадров, каналы для неблокирующей отправки, пул буферов
Результат: 2.5 миллиона частиц на 60 fps симуляции + 30 fps отправка клиентам. Работает на смарт-ТВ.
Попробовать можно тут: howfastisgo.dev
————
Статья очень крутая, рекомендую.
Автор честно признаётся в разочаровании: Go без SIMD в чистых вычислениях проигрывает даже JavaScript, не говоря уж про Rust (который на одном ядре обошёл Go на восьми).
Но Go и не позиционируется как язык для тяжёлых вычислений — он про сетевые сервисы и конкурентность.
Мне понравился подход с g-buffer'ом — изящное решение проблемы масштабирования. Дельта-кодирование с зигзаг-кодированием в итоге забросили из-за сложности кода, но это правильный выбор — иногда простота важнее оптимальности.
#article #performance #websocket
1👍27🔥7❤5