[Malstrime]

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

(показать/скрыть)

В случае с двумя мозгами для рук даже задача про погладить голову и побить по животу упрощается

Настоящая проблема многопоточности это шареные ресурсы и задержки из-за ожидания доступа к ним
Если возвращаться к примеру то нужно было просто добавить условия что готовить завтрак и чай мы будем в железной посуде и на одной комфорке, а не каждый в своём устройстве и тогда да, хоть вдесятером заходите на кухню но пока вода в чайнике не нагреется, сковородку с завтраком на комфорку не поставишь и в итоге поесть всё равно можно будет в одно время
И тут возникает проблема целесообразности, ведь пока вторую комфорку не организуешь в принципе можно и одному все делать, а вторая комфорка может стоить нереально дорого, если её вообще можно сделать

Своим примером я хотел отобразить то, как сложно сделать многопоточность в условиях, когда она архитектурно не закладывалась (конечно, наш мозг на фоне контролирует много процессов, но в целом то же самое делает и комплюктерная операционная система).

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

Подумал сейчас ещё про чогалла из хотса: если два игрока сыгрались на нем, то это машина для убийства, а если нет, то груша для битья (при прочих равных).

[Райзе]

Количество школьников, ни бельмеса не смыслящих ни в программировании вообще, ни в игроделании в частности, активно транслирующих свое суперценное мнение по поводу разных технических особенностей движка ВоВ, просто поражает. Это уже прямо традиция сообщества, грезить то о какой-то многопоточности, то о какой-то новой графике, в упор не замечая подслеповатыми глазенками, что из этого внедряют в ВоВ и когда. Ну понятно, когда не знаешь о чем говоришь, и не понимаешь для чего оно нужно - кроме херни ничего не скажешь.

[Dart Raiden]

Кстати, на CurseForge есть библиотека под названием WoWThreads, которая пыталась решить эту проблему, но, похоже, она давно не обновлялась и не получила широкой популярности.

Оно и понятно, потому что это не волшебная пуля, которая сама делает всё збс, а лишь библиотека, которую автор каждой конкретной модификации должен себе встроить и адаптировать свой код. Но авторам это не интересно, ведь и так всё кое-как работает.

Ну и я бы не сказал, что она заброшена, видно, что интерес у автора ещё не совсем угас, хотя основная работа и остановилась почти год назад.

[AlanMix]

Кхем. Отвечу.

Коротко: а фиг вам, нету короткого ответа, WoW долбится в 1 ядро по серверным (онлайн) причинам и ситуация усугбляется уже текущими горе-разработчиками, а многопоток оптимизировали в БфА для уже совсем уж многоядерных процов (руйзены и прочее), но недавних времен все еще 1 основное разогнанное ядро влияет на процесс игры лучше, чем 64 ядра хламузенов. А 3дкеш это костыль связанный с памятью.

Более детально ...
Начнем с базы которую мало кто понимает и даже здесь чет несут околесицу. На процессе установлено ядро, это физический исполнительный "инструмент" на котором полноценно выполняется полностью вся задача которую ему назначил компуктер. Поток - это виртуальное разбивание ядра на два логических ядра, то есть условно "4 ядра, 8 потоков" = это 4 физических ядра которые разделены на двое, т.е. 8 потоков которые выполняют параллельно. Но это не увеличивает быстродействие компьютера в 2 раза, у вас так же остаются 4 ядра, просто они нагружаются разными уровнями задач равномерно, в чистой теории. На практике мы имеем такую вещь что очередное АААА-хлам долбится в одно ядро (2 потока) на 99%, а остальные 2-3-7-11-31 ядро простаивает или нагрузка минимальна, об этом позже.
Поток - задача(и), ядро - исполнитель.

Теперь про сам WoW. Игра - полностью сервернозависимая игра на которой в реалтайм происходит обработка данных (в пакетах) и получение их. То есть игра отправляет на сервер пакет, сервер сканирует (от других участниках в мире, действие итд), отправляет на клиент игрока, клиент расставляет полученные данные, выводит изображение, клиент получает новые команды от клиента и/или получает новый пакет итд. И все эти основные вычисления (отправка/получение) выполняет одно ядро и/или один поток. Он является основным, по этому нагружен на максимум, по этому он узкое горлышко ибо всё что происходит у игрока проходит через одно ядро. От чего ошибочно думается что игра однопотоковая до сих пор. Это не так, по скольку после получения информации игра распаралелливают полученную информацию на другие ядра, но они не в "реалтайме" обменивают информацию, например загрузка мобов, карты, текстур, звуков, эффектов итд.

Чтобы избежать бутылочного горлышка, необходимо чтоб одно ядро было максимально быстрым, по этому интел был впереди планеты в рамках WoW. Плюс к этому - количество разных процессов в игре было условно ограничено, по этому с увеличением ядре, нагрузка не распределялась должным образом и в некоторых ситуациях не было нагружена. По этому в BfA игру слегка подлопатили чтоб она начала использовать не ограниченное количество ядер/потоков, а максимальное доступное.

И дальше следует новая проблема, быстродействие. Как мы поняли, игра использует 1 ядро для выполнение задач связанные с сервером, она постоянно нагружено обновлением данных и эти данные пишутся во временное хранилище, сначала кеш процессора (L1-L2-L3), потом вызывается информация в ОЗУ и выводится на компуктере. Как уже сказано, если поставить 3D-cache (Ryzen 5800x3D), то быстродействие вырастит по скольку количество необходимого времени на связку Ядро > ЦП > Мост > Озу и обратно падает, сразу идет запись информации в кеше процесса, он увеличен > быстродействие компуктера > выше фпс. Но это палка в никуда.

Чего нужно? Переделывать в первую очередь серверную логику клиента на обработку данных. По скольку у нас 1 ядро выделено под общие задачи, то либо разделить уже на 4 ядра разные компоновку вопроса, например
Ядро 1 - принятие/отправка данных.
Ядро 2 - запись действий игрока.
Ядро 3 - принятие серверных действий.
Ядро 4 - асимметричные задачи (текстуры, звук, прочее).

Но этого не будет по очень печальной причине - кривожопые мудаки на псевдоразрабах. Пример выше требует синхронизации различных систем. Но эти синхронизации сейчас гробятся под простым "а давайте хреначить друг на друга системы которые проверяют друг на друга в виде аур, чтоб насиловать данные как клиента, так и игрока". О чем речь.

В ШЛ добавили Соулбайнды и Ковенанты которые, по какой то неизвестной причине, были реализованы в виде аур на игрока. Зачем? Никто не знает. Результат - при любой потери соединения клиента/сервера при перезаходе игрок терял "соулбайнд" и он попросту переставал работать в ключах, иногда рейдах или пвп. И если в ключах была проверка закрепленная спека, то тут ...

Хуже всего - это добавление в том же бфа (ранее) кучу прокового на азеритках итд. То есть у игрока появлялись куча внешних проверочных элементов которые были не родные клиенту игрока, а промежуточные (как тринкеты), по этому каждый раз перед проком клиент-сервер проверяли "а нужно сейчас прокать, а давай не сейчас прокать", при этом были же Легионские Артефакты и не было на столько плохо.

Но ближе к текущей ситуации - ДФ. Какой урок мы вынесли из БфА+ШЛ? Правильно, добавляем все таланты игрока теперь как пермоауры (сейчас она как то по другому прописано), добавляем еще больше проковых вещей которые постоянно проверяются игроком и сервером, нагружаем дополнительно ЦП новой постоянной информацией. Но этого мало, сделаем еще чтоб вывод информации через сам клиент был наглухо сломан, да, я про UI и про API самого клиента. Испортим много функций, не предупредим, не будем фиксить уже 3-й год миллиард багов и только множить их. Почему? Ну просто.

И теперь TWW, эпическое творение. Что нужно сделать, чтоб избавить игроков от лагов? Правильно, унифицируем внутренние API и добавляем в ретейл универсальный классик-клиент. Это вроде не должно никак влияеть на производительность? Ну не должно, по этому ... для полноценного ответа необходимо заниматься реверсом всех функций и сравнивать полученную/отправленную информацию в разные этапы игры. Я этим не занимался, примерно понимаю как делать, но смысла в этом не вижу. На форумах и без меня пишут погромисты аддонов чтоб пофиксили те или иные дыры в ux/ui/api/lua, но форумы остаются без ответа месяцами, если уже не годами. Что то фиксят, да, но очень произвольно. Наверное ждут когда минимальный фпс без аддонов будет хотя бы 10-ку.

[Ascend]

На самом деле действительно забавно читать подобные треды.
"Вов игра немногопоточная" - Сказал Петя из 8А Васе из 9Б.
"Вот используй он равномерно все дохренилион потоков моего компьютера, то и игра работала бы в дохренилион раз быстрее, ну или хотя бы в дохренилион * 0.5" - Добавил Петя.

Для начала стоит помнить, что большинство задач в клиенте не такие тривиальные как может показаться на первый взгляд и много чего попросту нельзя нормально распараллелить. Я думаю многие, кто хоть раз пытался решить продакшен задачу в сложном проекте, часто сталкивались с тем что многопоточные системы как правило работают ХУЖЕ чем простой однопоточный проект, если бездумно пытаться параллелить всё что движется. И если честно мне не особо интересно вдаваться во все тонкости и рассказывать про это подробно, когда любому человеку маломальски знакомому с тем как работает компьютер и так понятно что на использование потоков на каждом такте процессора (свитч/синхронизация и т.д.) также уходят накладные расходы. И вместо того чтобы впитывать как губка идеализированные ответы чата gpt нужно хоть раз самому попытаться распараллелить какой-то процесс, работающий не в вакууме, и тогда подобного понтозерства станет меньше.

То что нагрузка во время работы идет в основном на главный поток - абсолютно нормально. Я даже не особо понимаю как вы видите эту ситуацию иначе, учитывая что главный поток на то и главный, что должен оркестрировать, сверять и выполнять множество логики, которую невозможно распараллелить.

Кто-то особо недалекий также писал что РЕНДЕРИНГ в вове не распараллелен. Это на самом деле настолько смешно, что даже комментировать стыдно.
Что dx12 что вулкан изначально проектировались под многопоточность. И как минимум самая простая схема работы (первый поток готовит данные, другой обновляет, третий рендерит) будет использоваться в любом, даже школьном проекте, где применяется графическое апи нового поколения. Разумеется генерировать батч команд для отправки их на GPU (кстати тоже очень нетривиальный процесс синхронизации CPU и GPU, когда речь заходит об оптимизации) можно в несколько потоков. Кроме того, ситуация усугубляется тем что Вов ещё и сетевая игра, и должна обеспечивать согласованную отрисовку кадров пре непредсказуемой задержки сети, учитывать интерполяцию и хранить снепшоты состояний. Разумеется в таком проекте будут использоваться как минимум кастомные аллокаторы, тредпулы, вычислительные шейдеры (хотя последнее в Вове вроде бы не наблюдал, но смотрел во времена легиона так что все скорее всего давно изменилось). В случае Вова скорее всего уже давно используются более централизованные и продвинутые системы чем тредпулы.

В общем что я хочу сказать. Написал я очевидно очень мало теории и в случае с мморпг таких масштабов всё намного труднее. Вов, пожалуй, учитывая его комплекцию, является хорошо оптимизированным проектом со своим проприетарным движком, специально рассчитанным под 3д ммо. Безусловно, всегда можно сделать лучше, но нытье комнатных экспертов в данной ситуации им ничем не поможет и только повысит градус кринжа.