January 4th, 2011

околорабочее

Изучал язык C на примере MMORPG; точнее, вспоминал. И ещё проверял одну идею.

Кажется мне, что <нупростодифига>головый сервер с кучей памяти, тормозящий на 4-5 тыс. игроков online есть что-то неправильное. Вот эту идею и проверял.

Пусть есть бой, в котором участвует <дофига> персонажей. Каждый в каком-то приближении зависит от каждого, точнее - от соседа, но понятие "сосед" условное - так что от каждого.

Придумал структуры данных (обошёлся даже без OOP), пригодные для хранения и обработки информации о битве. Засунул туда 45000 игроков, натравил на них функцию перебора соседей, получил время обработки действия в одну микросекунду. Посмотрел ключи компиляции; включил -O2 - ускорилось в три раза. Офигел мрачно.

Облазил код, нашёл ошибку (проверялся ровно один сосед из каждой клетки), исправил, добавил в перебор соседей полезную функцию, запустил - висит. Ну или почти висит (500 микросекунд). Матюгнулся, оставил тысячу игроков (а то они на поле были по 450 на клетку), получил что-то чуть меньшее, чем 10 микросекунд. То есть обработка всех игроков заняла бы 10 миллисекунд - опять же без оптимизации.

Хорошо, что функция перебора соседей вызывается далеко не всегда и даже такой ресурсоёмкий способ работает достаточно быстро. Конечно, реальная игровая механика сложнее, но и работать будет не без оптимизации и не на P3 1.266 ГГц.

Как вывод - сервер, обслуживающий собственно бой может быть однопоточным (по крайней мере, один поток - один бой) и его мощности хватит без распараллеливания даже одного боя.