Intel TBB support ?

For code related discussions and questions

Intel TBB support ?

Postby Vincent » 25 Aug 2017, 22:26

Hi,

I planned to used Intel TBB to make part of the engine multi threaded.
Game engines often relies on a job system to handle scalable multi threading : the code is split in small independent job, or task, which can in turn spaw other task. Some scheduling heurisitc is then used to dispatch task to cpu cores in order to preserve cache coherency and avoid synchronisation step (usually this is done via task stealing algorithm).

Intel TBB is an almost standard implementation of a job system infrastructure : it's used in unreal engine 4 for instance. It provides several high level c++ construction like tbb::parallel_for or tbb::parallel_pipeline, parallel_invoke... that can be used for tree traversal, loop spliting and so on.
The big issue is that TBB is not available on MXE. I suspect some thread Library compatibility here (some thread related stdlib are unavailable with MXE) which is rather annoying. As far as I know there's no competing solution.
It's possible to guard TBB code with ifdef however this means that the MXE generated code won't be multithreaded. Is this an issue at the moment from a development perspective ?
Vincent
Trained
Trained
 
Posts: 75
Joined: 06 Aug 2016, 17:24

Re: Intel TBB support ?

Postby pastdue » 25 Aug 2017, 23:30

What part(s) of the engine are you looking to make multi-threaded? Having dug into the code over the last weeks, there are a *lot* of obstacles to doing this without introducing race conditions and thread-safety issues. (It was on my "wish-list" too, but I bumped it down the list because of this.)

EDIT: To clarify, the Intel TBB doesn't magically solve the issue of concurrency-safety, and that's the concern. There are implicit assumptions throughout the code that the only thing accessing / modifying various data/pointers/etc is the main thread.

EDIT[2]: Also, an additional possible concern with Intel TBB specifically: it appears as though people have had difficulty getting it to work on non-x86 processors (ex. ARM). At the moment, the Warzone sources *should* be compilable (with some minor tweaking) on non-x86 processors. Intel TBB might make that, at a minimum, considerably more difficult.
pastdue
Rookie
Rookie
 
Posts: 16
Joined: 13 Aug 2017, 17:44

Re: Intel TBB support ?

Postby cybersphinx » 26 Aug 2017, 02:34

Vincent wrote:MXE generated code won't be multithreaded. Is this an issue

Kinda, since releases are built with MXE.
We want information... information... information.
cybersphinx
Inactive
Inactive
 
Posts: 1666
Joined: 01 Sep 2006, 19:17

Re: Intel TBB support ?

Postby Vincent » 26 Aug 2017, 20:35

pastdue wrote:What part(s) of the engine are you looking to make multi-threaded? Having dug into the code over the last weeks, there are a *lot* of obstacles to doing this without introducing race conditions and thread-safety issues. (It was on my "wish-list" too, but I bumped it down the list because of this.)

EDIT: To clarify, the Intel TBB doesn't magically solve the issue of concurrency-safety, and that's the concern. There are implicit assumptions throughout the code that the only thing accessing / modifying various data/pointers/etc is the main thread.

EDIT[2]: Also, an additional possible concern with Intel TBB specifically: it appears as though people have had difficulty getting it to work on non-x86 processors (ex. ARM). At the moment, the Warzone sources *should* be compilable (with some minor tweaking) on non-x86 processors. Intel TBB might make that, at a minimum, considerably more difficult.


The goal is not to split the whole code into several threads, but rather to parrallelize several loops and tree traversal. Loops iteration are good candidate for multithreading.
Do you have any source about tbb incompatibility with ARM ? As far as I know it's used on Android for OpenCV for instance.
Vincent
Trained
Trained
 
Posts: 75
Joined: 06 Aug 2016, 17:24

Re: Intel TBB support ?

Postby pastdue » 26 Aug 2017, 21:36

Vincent wrote:The goal is not to split the whole code into several threads, but rather to parrallelize several loops and tree traversal. Loops iteration are good candidate for multithreading.


Constructs like tbb::parallel_for use threads under-the-hood. They do not magically solve concurrency issues. And, in fact, they can make it more difficult to solve OpenGL-related (and other) concurrency issues when you have no control over which threads are running the code. (For OpenGL, at least, this is critical.)

As I commented on your branch, you cannot simply (or safely) parallelize a lot of the existing code using merely these simple constructs. Your initial attempt does so with functions that touch OpenGL, and that's a bad idea without a lot of additional work. There are a lot of other issues with how the existing code works that makes this approach very troublesome throughout.

Just because something compiles, and even runs on your system, does not prove you are not introducing very difficult-to-track-down bugs because of concurrency issues. There be dragons here, in the codebase. A lot of them.

Moreover, no, not all loop iterations are good candidates for multithreading. You need to profile the code before going too much into this work, to identify the spots where it might make an impact. Or if other solutions, like caching, might be a better idea. (A lot of the current bottlenecks in the rendering engine, from a quick profile, look to be more easily improved by caching, not parallelization.) Parallelization has a non-negligible overhead - if you add it to arbitrary loops / places, you may in fact decrease performance. And that's ignoring the additional overhead and complexity required to do this properly with a lot of the existing code / API usage. And of things like context switches, cache coherence, synchronization, etc.

Do you have any source about tbb incompatibility with ARM ? As far as I know it's used on Android for OpenCV for instance.

A Google search turns up numerous examples of folks who have had difficulty getting it to compile on non-x86 systems and non-standard Win/Mac/Linux systems. But the concerns above surpass this one.
Last edited by pastdue on 27 Aug 2017, 07:23, edited 1 time in total.
pastdue
Rookie
Rookie
 
Posts: 16
Joined: 13 Aug 2017, 17:44

Re: Intel TBB support ?

Postby Per » 26 Aug 2017, 21:47

I have my doubts as to whether loop iteration and tree traversal in our code base will benefit much from multi-threading. The cost of the scatter-gather operations and doing synchronization are often higher than the benefit, in my experience. We are using worker threads in some (two IIRC) places in the code where we thought it would be beneficial, but they were also difficult to get right because of synchronization issues.

I think usually when we have multi-threading options, c++11 threads should be good enough, although I've never used Intel TBB.

I think for getting better performance, reorganizing the render code so that it batches and caches drawing operations will be best thing to spend time on.
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
 
Posts: 3604
Joined: 03 Aug 2006, 19:39

Re: Intel TBB support ?

Postby moltengear » 02 Sep 2017, 13:33

#include "SDL_thread.h"

SDL_Thread *thread;
thread = SDL_CreateThread(second_thread, NULL);

int second_thread(void* x)
{

return (0);
}
moltengear
Greenhorn
 
Posts: 8
Joined: 22 Jul 2017, 15:05


Return to Coding