Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multithreaded loading support #2764

Draft
wants to merge 8 commits into
base: develop
Choose a base branch
from

Conversation

IvanSavenko
Copy link
Member

@IvanSavenko IvanSavenko commented Sep 5, 2023

Early WIP.

Goals:

  • Allow loading of game in multiple threads, improving game startup and server startup times
  • Allow general tasks support, in any part of our code, including running tasks from inside tasks - e.g. run parallel load of each handler inside parallel load of each mod

Changes:

  • Moved ThreadPool class from RMG to root directory of library
  • Removed old version of ThreadPool that was used in VCAI
  • Simplified usage of ThreadPool and removed excessive waits / locks
  • Added parallel loading of Json's in mod loading
  • Made thread pool global instead of creating it in place
  • Allow running tasks from inside tasks without spawning dozens of threads

Progress:

  • allow multithreaded access to IdentifiersStorage during loading
  • parallelize ObjectTemplate::readTxt
  • parallelize CModHandler::loadMod per mod
  • parallelize CModHandler::loadMod per handler
  • parallelize CModHandler::loadMod per object
  • parallelize CModHandler::preloadModData per handler
  • parallelize CModHandler::preloadModData per mod
  • parallelize CModHandler::calculateModChecksum per mod
  • parallelize or remove CModHandler::validateTranslations

Regressions:

  • add async schema loading or load all schemas before validation stage

Possible improvements:

  • check profiler for any remaining issue, such as delays caused by wait/sleep
  • consider some optimization to logging API or remove excessive logging during parallel stage if necessary


inline ThreadPool & ThreadPool::global()
{
static ThreadPool globalInstance;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure we should keep static instance in header. Also we have TBB anyway with its own thread pool. So maybe it is less convenient to use it, I do not know

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably TBB is more complex.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Static inside inline function should work as intended, so that part is OK.

Thread pool from TBB - will look into it.
If they have persistent, preconfigured thread pool - then probably makes sense to use it. But probably an overkill for our needs.

I am aiming for minimal overhead / minimal configuration to a point where you can parallelize operation that takes 1-2 ms. Meanwhile TBB:

CAUTION:
Typically a loop needs to take at least a million clock cycles to make it worth using parallel_for. For example, a loop that takes at least 500 microseconds on a 2 GHz processor might benefit from parallel_for.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants