Ryzen and WoW

[Gray_Matter]

I wonder which part is incorrect. And as I said, in cases of non-dependent tasks, multi-threading is easy, the problems rise when you are dealing with highly intermingled execution paths.

That's my point. Threading can also be easy in the highly intermingled execution parts. It's not full task threading but rather a calculated decision to use multiple threads on specific "slow" portions of the code. It's very seldom that you find any calculation code that works on single values. That's slow and inefficient. If there is that type of code in the application then those should be optimized first using something like Intel IPP. Once you are performing calculations on blocks of numbers then multiple threads can be used with minimal effort provided certain rules are followed.

For example, the flow of code might look like this (warning: dumb high level example to follow):

if (CollisionDetected)
{
DoStuffOnObject;
}

That flow wouldn't change at all. You can't change DoStuffOnObject to run in a different thread to CollisionDetected because it depends on it. What would would change is the code inside the DoStuffOnObject to do something like this:

Parallel.For(1, 12, ctr =>
{
work on block ctr
})

In other words, you are targeting specific blocks of code and only threading those. So you might take a specific block that is taking 24ms and by threading the code you can drop it down to 2ms. Assuming 6c/12t threads. For that split second, you will get a spike on all of the cores for the processing. You can pick these "critical paths", to steal a word from the project managers, and optimize those for multiple threads and quickly end up with much faster response time. You won't see all of the threads maxed out all of the time but the difference in 22ms will be very noticible in FPS.

[Kuntantee]

That's my point. Threading can also be easy in the highly intermingled execution parts. It's not full task threading but rather a calculated decision to use multiple threads on specific "slow" portions of the code. It's very seldom that you find any calculation code that works on single values. That's slow and inefficient. If there is that type of code in the application then those should be optimized first using something like Intel IPP. Once you are performing calculations on blocks of numbers then multiple threads can be used with minimal effort provided certain rules are followed.

For example, the flow of code might look like this (warning: dumb high level example to follow):

if (CollisionDetected)
{
DoStuffOnObject;
}

That flow wouldn't change at all. You can't change DoStuffOnObject to run in a different thread to CollisionDetected because it depends on it. What would would change is the code inside the DoStuffOnObject to do something like this:

Parallel.For(1, 12, ctr =>
{
work on block ctr
})

In other words, you are targeting specific blocks of code and only threading those. So you might take a specific block that is taking 24ms and by threading the code you can drop it down to 2ms. Assuming 6c/12t threads. For that split second, you will get a spike on all of the cores for the processing. You can pick these "critical paths", to steal a word from the project managers, and optimize those for multiple threads and quickly end up with much faster response time. You won't see all of the threads maxed out all of the time but the difference in 22ms will be very noticible in FPS.

Except your toy example is not "highly intermingled". In fact, it shows no sign of dependency whatsoever. Those who claim multi-threading can be easy on complex software are the ones who never utilized threads on datas/states that are accessed and mutated by a gazillion (exaggerating obviously, this is an anti-pattern) of different points on a module or modules. Thread safety mechanics in C++ is itself a giant topic.

[ComputerNerd]

Also How would we benchmark wow? Highest graphics settings or minimum? Area? Raid? Would be nice to sort of test out.

WoW is lacking proper tools for benchmarking in any sufficiently demanding environment.
There is only one that I am aware of.

No other sufficiently consistent environment that I am aware of to test in.
Nor would I really consider that one particularly useful.

Enables or disables flight path benchmark mode. When benchmark mode is enabled, the next taxi flight the player takes will behave differently: camera movement is disabled and players/creatures/objects below the flight path will not be shown (allowing for consistent test conditions). After the flight, framerate statistics will be printed in the chat window and benchmark mode will be automatically disabled.

See also Taxi/Flight functions, Debugging and Profiling functions.
Signature:

SetTaxiBenchmarkMode("arg")
Arguments:

arg - nil, "on", or 1 to enable benchmark mode; "off" or 0 to disable (string)

http://wowprogramming.com/docs/api/SetTaxiBenchmarkMode

Would require taking the same path in the same direction, and ideally in as unchanging an environment as possible.

[Gray_Matter]

Except your toy example is not "highly intermingled". In fact, it shows no sign of dependency whatsoever. Those who claim multi-threading can be easy on complex software are the ones who never utilized threads on datas/states that are accessed and mutated by a gazillion (exaggerating obviously, this is an anti-pattern) of different points on a module or modules. Thread safety mechanics in C++ is itself a giant topic.

I am well aware of the complexities of threading code. I regularly work on low level libraries to make it possible for others the the office to do threading. When is it better to use a spin lock or a critical section? Can we get away with using an InterlockedExchange or InterlockedCompareExchange or even some assembler to do some locked bit operations instead of locking? Can we manipulate the situation so that no locking is necessary at all? Do we need to allocate any memory and how will that effect the situation? How will the branch prediction effect our code? Those are all questions that I often deal with. Threading is not easy. I have said this here before. It's probably the most difficult area of programming. But my point is that it can be easy in places. In carefull selected situations. The high level example above demonstrates exactly that. There is a dependency. DoStuffOnObject is dependent on CollisionDetected. We don't let the threading get involved there. We delve down deeping and put the threading on a specific task that is taking a long time.

I work on highly complex software that does millions of calculations per second and makes extensive use of threads, often under very difficult situations. I am not just pulling everything out of my thumb.

Let me try and explain a bit more. In my development VM on my dev PC (I7-6700), I just tested and created a small, single threaded, block of code with some simple calculations and a comparison that can't be optimized by the branch prediciton. In under a second I can get well over 10 million of these tasks executed. On a real Pc it would be different but for now it gives me enough for my example. If I have a piece of code that is getting 30 FPS then it's logical to say that each frame would take 333333 of my little tasks, assuming that's what was behind the scenes when we prepared the frame. When the compiler optimizes my code it ends up with about 35 assembler instructions. So the CPU, in this case, is executing over 10 million assembler instructions for a single frame. All of the memory being accessed is in the L1 cache so that has a massive impact on performance. But the point remains. Even with your "highly intermingled" code, the CPU is executing a huge number of assembler instructions per frame. These don't all have to be executed in a specific sequence. When you profile the code you will get certain areas that work on large blocks of numbers doing calculations. Threading these can be relativey easily. You don't need to dive in and do wholesale threading or refactoring.

With threading you can normally get a few very big wins for very little effort. You just have to carefully pick those spots.

[Kuntantee]

Well, I had to google your terminology because it didn't make sense (spin lock or a critical section WTH?*). Turns out, you are a Windows programmer . Anyway, in the core, multi-threading's problem is synchronization/serialization problem. Any piece of code that's hard to synch or serialize is hard to write in parallel and moderately complex code often is. That's all I am saying.

I mean I get what you are trying to say, but it all depends on the problem at hand.

*Spinlock is a waiting lock, critical section is section of code to be serialized. Apples and oranges for anyone, such as me, who's not informed on MS Threading API.

[dadev]

Well, I had to google your terminology because it didn't make sense (spin lock or a critical section WTH?*). Turns out, you are a Windows programmer . Anyway, in the core, multi-threading's problem is synchronization/serialization problem. Any piece of code that's hard to synch or serialize is hard to write in parallel and moderately complex code often is. That's all I am saying.

I mean I get what you are trying to say, but it all depends on the problem at hand.

*Spinlock is a waiting lock, critical section is section of code to be serialized. Apples and oranges for anyone, such as me, who's not informed on MS Threading API.

Spinlocks are not Windows thing, it's quite universal terminology. Critical section is associated with windows, but I think everyone and his sister knows that it's a lightweight non shareable mutex.

Although I do not share the view that unconstrained multi threaded programming is hard. If I can use locks then it's pretty much a walk in the park. Of course I won't get 100% utilization that way if there's significant contention, but it's still multithreading, and in many cases it's enough to get every ounce of utilization. Throw some constraints in there, like keeping the data structures unlocked at all times, then it becomes a lot more interesting. Still not the hardest thing I've stumbled upon, but definitely not easy anymore.

[Gray_Matter]

If I can use locks then it's pretty much a walk in the park.

The real trick is to not use any locks.

[dadev]

The real trick is to not use any locks.

Indeed. Although I don't think you need to avoid them every single time, only when contention is an issue. People mistakenly think that they should use lockless everywhere, while in reality locks are usually good enough and also simplify the code immensely which bears many benefits.

On the other hand writing and debugging lock free code requires significant effort (or time if you will). Porting it to multiple platforms is not straightforward because there are different atomics on different architectures, and even the similar ones can behave differently in logic and performance. Profiling lockless data structure is another nightmare because pitfalls appear on the lowest hardware level. And finally passing on that knowledge is just damn hard, explaining lockless data structures to the uninitiated is not simple at all.

[Gray_Matter]

Indeed. Although I don't think you need to avoid them every single time, only when contention is an issue. People mistakenly think that they should use lockless everywhere, while in reality locks are usually good enough and also simplify the code immensely which bears many benefits.

On the other hand writing and debugging lock free code requires significant effort (or time if you will). Porting it to multiple platforms is not straightforward because there are different atomics on different architectures, and even the similar ones can behave differently in logic and performance. Profiling lockless data structure is another nightmare because pitfalls appear on the lowest hardware level. And finally passing on that knowledge is just damn hard, explaining lockless data structures to the uninitiated is not simple at all.

I agree. Ultimately what sort of expected contentions will determine how lock-free the code will be. In our case, most of the time we don't expect contentions so we have a few spin locks limiting access to shared data. For the most part, though, we split up our data into smaller blocks and process those blocks in multiple threads. There is no need for locking.

I think this is the approach that games should take rather than trying to go the full multi-thread design route that a game like Ashes has used. WOW's code is really old so it may not be a simple thing to do, depending on how it's designed. They might get more benefit from first changing the design to use IPP in places.

[moremana]

Its amazing how far off topic this thread has become.

Anyone looking for questions regarding wow and a ryzen cpu's performance will find this thread useless unless he is a programmer.

[Remilia]

Its amazing how far off topic this thread has become.

Anyone looking for questions regarding wow and a ryzen cpu's performance will find this thread useless unless he is a programmer.

A lot more amusing imo.

[moremana]

A lot more amusing imo.

I will refer you mods to rule #8 of the posting guidelines of the forums you moderate.

8. Do not steer threads off-topic. Posting for the sake of posting is heavily frowned upon. If you have nothing to contribute to the topic that is being discussed in a thread, do not post a reply in it.

Ok Im done being a ass... Just find it amusing that the rules are negotiable.

[Remilia]

I will refer you mods to rule #8 of the posting guidelines of the forums you moderate.

8. Do not steer threads off-topic. Posting for the sake of posting is heavily frowned upon. If you have nothing to contribute to the topic that is being discussed in a thread, do not post a reply in it.

Ok Im done being a ass... Just find it amusing that the rules are negotiable.

I don't mod this forum just btw.

[moremana]

I don't mod this forum just btw.

So the rules dont pertain to you outside the forums you moderate?

I see, I get it now.

continue

[Remilia]

So the rules dont pertain to you outside the forums you moderate?

I see, I get it now.

continue

No, it means I have no power in this forum to do anything. But it seems you rather go about false interpretation and persecution. I've not posted in this thread till recently so trying to pin it on me is pointless.

[moremana]

No, it means I have no power in this forum to do anything. But it seems you rather go about false interpretation and persecution. I've not posted in this thread till recently so trying to pin it on me is pointless.

I wasn't trying to pin it on you, merely pointing out how you defended it.

its all good. If we need to continue we can do it in PMs, after all...it is the rules

[Remilia]

I wasn't trying to pin it on you, merely pointing out how you defended it.

its all good. If we need to continue we can do it in PMs, after all...it is the rules

Oh, nah I wasn't really trying to defend it, I just find the topic a lot more interesting than the typical bickering. Sorry for any confusion.

[moremana]

Oh, nah I wasn't really trying to defend it, I just find the topic a lot more interesting than the typical bickering. Sorry for any confusion.

No apologies necessary!

Its all good, you mods have some good input in these forums, so I'm sure all, like me value your participation.

On a side note....this whole conversation for me was not serious. I hope it wasn't taken the wrong way.

[vsb]

Do you think that ThreadRipper is exactly the same for WoW as Ryzen or it'll be faster? May be someone had some experience with it?

[Wries]

It's the hard struggle for a WoWer. You can recommend Ryzen for most people but there is that pesky asterisk about it and WoW.

Other titles where Intel outperform we're talking about 100s of frames per second already so it's not really an issue. But WoW can still dip below 60 easily.

That said, it can't be that bad either. Just on paper it isn't the defacto choice for this game but I do know guildies who have bought ryzen and claim they see a positive gain over non-overclocked sandy/ivy.

Do you think that ThreadRipper is exactly the same for WoW as Ryzen or it'll be faster? May be someone had some experience with it?

I don't see why it would be faster given what we know about it, more ryzen cores, and WoW, where performance doesn't scale with cores. Though, maaaybe some gain due to doubled memory bandwidth. Maybe.