Parallelism vs Threading - Performance

Question

I have been reading on the subject, but I haven't been able to find a concrete answer to my question. I am interested in using parallelism/multithreading to improve the performance of my game, but I have heard some contradicting facts. For example, that multithreading may not produce any improvement on the execution speed for a game. I

I have thought of two ways to do this:

putting the rendering component into a thread. There are some things I would need to change, but I have a good idea of what needs to be done.
using openMP to parallelize the rendering function. I have already code to do so, thus this might be easier option.

This being an Uni assessment, the target hardware are my Uni's computers, which are multi-core (4 cores), and therefore I am hoping to achieve some additional efficiency using either one of those techniques.

My question, is therefore, the following: Which one should I prefer? Which normally produces the best results?

EDIT: The main function I mean to parallelize/multithread away:

void Visualization::ClipTransBlit ( int id, Vector2i spritePosition, FrameData frame, View *view )
{
    const Rectangle viewRect = view->GetRect ();
    BYTE *bufferPtr = view->GetBuffer ();

    Texture *txt = txtMan_.GetTexture ( id );
    Rectangle clippingRect = Rectangle ( 0, frame.frameSize.x, 0, frame.frameSize.y );

    clippingRect.Translate ( spritePosition );
    clippingRect.ClipTo ( viewRect );
    Vector2i negPos ( -spritePosition.x, -spritePosition.y );
    clippingRect.Translate ( negPos );

    if ( spritePosition.x < viewRect.left_ ) { spritePosition.x = viewRect.left_; }
    if ( spritePosition.y < viewRect.top_ ) { spritePosition.y = viewRect.top_; }

    if (clippingRect.GetArea() == 0) { return; }

    //clippingRect.Translate ( frameData );

    BYTE *destPtr = bufferPtr + ((abs(spritePosition.x) - abs(viewRect.left_)) + (abs(spritePosition.y) - abs(viewRect.top_)) * viewRect.Width()) * 4; // corner position of the sprite (top left corner)
    BYTE *tempSPtr = txt->GetData() + (clippingRect.left_ + clippingRect.top_ * txt->GetSize().x) * 4;

    int w = clippingRect.Width();
    int h = clippingRect.Height();
    int endOfLine = (viewRect.Width() - w) * 4;
    int endOfSourceLine = (txt->GetSize().x - w) * 4;

    for (int i = 0; i < h; i++)
    {
        for (int j = 0; j < w; j++)
        {
            if (tempSPtr[3] != 0)
            {
                memcpy(destPtr, tempSPtr, 4);
            }

            destPtr += 4;
            tempSPtr += 4;
        }

        destPtr += endOfLine;
        tempSPtr += endOfSourceLine;
    }

}

Can you post the code that you are considering multithreading? — Michael B., Jan 20 '15 at 23:23
Best results depends on how parallelizable the parts are, and your ability to tease out that parallelism so it can be harnessed. You can't answer the question without investigating the code. — Ira Baxter, Jan 20 '15 at 23:29
@MichaelB. It is a bit long, since it encompasses multiple functions, but if it is necessary I will make a pastebin link. — MKII, Jan 20 '15 at 23:30
@inetknght I was afraid that could be the case. If so, please feel free to vote to close it. — MKII, Jan 20 '15 at 23:36

score 2 · Accepted Answer · edited May 23 '17 at 11:56

2

instead of calling memcpy for each pixel consider just setting the value there. the overhead in calling a function that many times could be dominating the overall execution time for this loop. E.g:

for (int i = 0; i < h; i++)
{
    for (int j = 0; j < w; j++)
    {
        if (tempSPtr[3] != 0)
        {
            *((DWORD*)destPtr) = *((DWORD*)tempSPtr);
        }

        destPtr += 4;
        tempSPtr += 4;
    }

    destPtr += endOfLine;
    tempSPtr += endOfSourceLine;
}

you could also avoid the conditional by employing one of the tricks mentioned here avoiding conditionals - in such a tight loop conditionals can be very expensive.

edit - as to whether it's better to run several instances of ClipTransBlit concurrently or to parallelize ClipTransBlit internally, I would say generally speaking it's better to implement parallelization at as high a level as possible to reduce the overhead you incur by setting it up (creating threads, synchronizing them, etc.)

In your case though because it looks like you're drawing sprites, if they were to overlap then without additional synchronization your high level threading might lead to nasty visual artifacts and even a race condition on checking the alpha bit. In that case the low level parallelism might be a better choice.

edited May 23 '17 at 11:56

Community

1
1

answered Jan 23 '15 at 01:58

gordy

9,360
1
31
43

I don't see any way to call it once per line without doing something else that would decrease performance anyway. Also, this is the rendering, the only other time I deal with graphics is when writing the view buffer into the screen. – MKII Jan 23 '15 at 02:32
@MKII I didn't notice that you were only writing to dest when the alpha byte is not zero - you might still benefit from removing the call to memcpy, example in the edit – gordy Jan 23 '15 at 03:44
I'd time it but I'd bet the cost of the branch is more expensive than just doing a write that won't be seen. If you have large sections of your source is known to contain alpha that you can implement an algorithm that will allow you skip blitting large sections of the frame. – rparolin Jan 23 '15 at 05:26
[RLE Sprites](http://www.nondot.org/sabre/graphpro/sprite3.html) it's an old school strategy for speeding up this kind of sprite engine – gordy Jan 23 '15 at 18:10
@gordy Thanks for the link and the answer. I have had a look at the link, and it seems interesting, but writing a way to encode my sprites could be time consuming. I tried substituting the memcpy for the DWORD copy, and it achieved a nice speed up, about 20%. – MKII Jan 25 '15 at 19:50

score 0 · Answer 2 · answered Jan 23 '15 at 06:41

Theoretically, they should produce the same effect. In practice, it might be quite different.

If you print out assembly code of an OpenMP program, OpenMP simply calls some function in the scope like #pragma omp parallel .... It is similar to folk.

OpenMP is parallel computing oriented, on the other hand, multi-thread is more general. For example, if you want to write a GUI program, multithreading is necessary(Some frameworks may hide it. It still needs multiple threads). However you never want to implement it with OpenMP.

Parallelism vs Threading - Performance

2 Answers2