Parallel.hpp File Reference

Thin wrapper around server-side parallel execution. More...

#include <SDL3/SDL.h>
#include <algorithm>
#include <atomic>
#include <cstddef>
#include <cstdlib>
#include <iterator>
#include <utility>
#include <condition_variable>
#include <deque>
#include <exception>
#include <functional>
#include <memory>
#include <mutex>
#include <thread>
#include <vector>

Include dependency graph for Parallel.hpp:

This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Classes
class	group2::perf::ParallelFlagGuard
class	group2::perf::FallbackThreadPool

Namespaces
namespace	group2
namespace	group2::perf

Functions
unsigned	group2::perf::fallbackWorkerCountFromEnv ()
FallbackThreadPool &	group2::perf::fallbackPool ()
void	group2::perf::initParallelFromEnv ()
	Initialize from environment.
template<class Iter, class Fn>
void	group2::perf::parallelFor (Iter begin, Iter end, Fn &&fn)
	Call fn(*it) for every element in [begin, end).

Variables
std::atomic< bool >	group2::perf::parallelEnabled {true}
	Master switch for parallel execution.
constexpr std::size_t	group2::perf::k_parallelThreshold = 8
	Minimum items below which parallelFor runs sequentially even when the master switch is on.
bool	group2::perf::inParallelKernel = false

Detailed Description

Thin wrapper around server-side parallel execution.

PR-3 (server-perf): the per-system game-thread work is largely embarrassingly parallel across players (animation update, hitbox capsule transform, swept collision, etc.). This header gives the systems a single, opinionated entry point — group2::perf::parallelFor(begin, end, fn) — that hides the platform/runtime details.

Implementation policy:

• With TBB installed (the common dev / CI path), we route through TBB's task-group scheduler directly.
• On platforms without TBB (currently a CMake fallback path: macOS Homebrew without explicit install, some Linux distros), we use a small persistent std::thread pool. CMake defines GROUP2_HAVE_TBB when the parallel-STL path is wired.

Determinism: lag-comp + hitscan rely on the simulation being deterministic across the network/recording boundary. Parallel execution may reorder operations across iterations BUT operates only on independent per-entity slots, so the observable result is identical to a sequential pass. We add a GROUP2_SERVER_PARALLEL=0 kill-switch (read once at startup) to fall back to sequential if a regression turns up — the brain wants the diff to be exactly "thread count" so repro is easy.