Idea to make multithreading easier

[Sizzle]

Interesting discussion.  Chris, would you care to hop in the DeLorian you have parked out back, set the clock forward a decade or so and predict for us how we're going handle these types of things in the future?  I've seen some articles around from some of the "greats" in the industry like John Carmack, and Gabe Newell  on how we're going to crack the Moore's Law problem -- namely that we're getting close to reaching a physical speed barrier so far as processing cycles go.

Lately the trend has been to more and more parallelization of hardware.  Rather than faster cores, we just get more of them.   The problem of course for gaming is that it doesn't always take being multithreaded too well as we're discussing.

What needs to happen for the next breakthrough?

(Might make a good blog post! But don't take this as any sort of demand on your time, answer as you see fit lol)

[x4000]

Well, RCIX, a lot of times the read locks are also advised in an managed code environment because of the underlying memory management needing to be able to shift things around for allocations, etc.  You might could do without them, but it wouldn't be the safest thing.

Your model would also really require that all the chunks take the same amount of processing time.  If you have the following threads:

1: 5ms
2: 1ms:
3: 4.5ms
4: 8ms
5: 2ms

Then none of them would be able to give their results to the main thread until the last thread was done, which would waste an enormous number of cycles as you go.  And I can tell you categorically that trying to divide up work evenly amongst unlike operations like ship calculations in AI War is no mean feat, you could waste a lot of CPU time on just that, with approximations based on all the various things a ship might need to calculate at any given time.

Not trying to beat this into the ground, and it's fast turning into one of "those" threads thanks to me, so I'll shut up now.  But I'm just saying that the entire approach is fraught with perils that you could spend months solving, and still not have better performance because of all the calculations required to divide up the work, copy the data, recopy the data back, and so on.  Somewhere in all this you have to actually trigger sound effects and render some graphics frames, which adds even more complexity because it would need to be on the main thread and would be also something that was blocking the main readonly dataset from receiving any updates until it was finished.  So if your graphics loop was not precisely timed with the results of your worker threads, you could wind up with even more CPU cycles wasted, on top of what I noted above.

Okay, that's really it.

[x4000]

Interesting discussion.  Chris, would you care to hop in the DeLorian you have parked out back, set the clock forward a decade or so and predict for us how we're going handle these types of things in the future?

Heh, I love the reference, and I wish I had one of those DeLorians.

I've seen some articles around from some of the "greats" in the industry like John Carmack, and Gabe Newell  on how we're going to crack the Moore's Law problem -- namely that we're getting close to reaching a physical speed barrier so far as processing cycles go.

Lately the trend has been to more and more parallelization of hardware.  Rather than faster cores, we just get more of them.   The problem of course for gaming is that it doesn't always take being multithreaded too well as we're discussing.

Well, John Carmack and Gabe Newell both make action games.  I'm fairly certain that neither one of them have ever contemplated the synchronous model of a strategy game in depth -- why would they?  It's a fiddly, desync-prone way to do things, and outside the strategy genre most developers won't touch it with a ten foot pole.  In strategy companies, you often have a programmer just dedicated to finding and preventing desyncs.

For action games, it's clear that parallelization is the future.  There is comparably little data (next to a strategy game, anyway), and a lot of the data never changes: why do you think more games don't have destructible environments, especially in multiplayer?  So there are still many challenges there, but they are different challenges and very much more oriented in a direction where parallelization is an awesome solution when you're bumping up against Moore's Law.  Even with strategy games, parts of them lift right out really easily: sound and graphics, for example.  Parallelize away with those, it's been done for years and doesn't affect the must-be-desync-free-simulation in any way.  Even networking is multithreaded for most of us.

What needs to happen for the next breakthrough

We need a faster Internet, and it's coming.  In 20-30 years, when the speed of the Internet is the speed that our CPU bus currently is, there will NEVER be a need for a synchronous multiplayer game like all current strategy games.  The only reason we do things synchronously is because we can't transmit 30mb+ of data across the Internet 20-30 times per second.  When and if that is no longer a barrier, then parallelization for strategy games becomes identical to that of action games.

Short of that, we need some math genius to bend the laws of reality and come up with a way to divide up the processing of a single-threaded application amongst multiple cores without affecting the result or requiring coding changes.  I believe Intel or IBM currently has a $1 million prize for the individual or team who figures that out.  I think they, like most people, don't believe it is even possible (but certainly it would be worth more than $1 million if someone figures it out).  Personally I think they likelihood of more-than-lightspeed Internet is greater than that particular problem being solved (they've already figured out how to teleport electrons, just under really specific circumstances -- there's a lot of potential as quantum physics progresses).

Also, if AI War were purely a single player game, then it could be just as multi-threaded as Half Life or whatever.  Only multiplayer strategy games have the constraints I mentioned.

[RCIX]

I really don't want to keep it being a "those" thread , but:

Your model would also really require that all the chunks take the same amount of processing time.  If you have the following threads:

1: 5ms
2: 1ms:
3: 4.5ms
4: 8ms
5: 2ms

Then none of them would be able to give their results to the main thread until the last thread was done, which would waste an enormous number of cycles as you go.  And I can tell you categorically that trying to divide up work evenly amongst unlike operations like ship calculations in AI War is no mean feat, you could waste a lot of CPU time on just that, with approximations based on all the various things a ship might need to calculate at any given time.

Okay, that's really it.

But then instead of spending 21.5ms on calculations, you're spending 8 (assuming you can give each one a separate core). You're wasting a lot less cycles that way then having one thread sequentially process each one, and having 4 cores (assuming a theoretical 5 core processor) idling for 21.5ms each.

This is of course assuming that you can overcome the half-dozen other problems that's been posed, but it's certainly interesting to me anyway. You're right though that you basically need a guy doing this fulltime to be effective

[x4000]

And sure, in my example you've saved some significant time assuming you can overcome all the other challenges and that my example numbers have any basis in reality. But only on multiple cores, and only I you have a certain volume of processing which can be divided up.

At two or three points in the past I actually tried movin collisions and autotargeting to the ai thread, but it was disastrous each time. With someone on it fulltime it might work, but I realized that the addition to the network load in that model was just unbearable.

[keith.lamothe]

Yea, it's not that there aren't gains to be had with multithreading (I have a fairly solid idea of how to get around the real showstoppers, it would just involve, oh, overhauling the whole codebase and changing the actual gameplay logic a fair bit), it's just a tradeoff like everything, and there are much better tradeoffs to be had along the lines of just making the game less work on the machines

I think there will be more point to this kind of thing when it's normal to have like 32 cores in a consumer machine, though that would involve some breakthroughs in heat management among other things and would still require the programs to be designed (or re-designed) with multithreading in mind.  The terabit-ethernet (or whatever) thing is a much more likely "deliverer", so to speak.  Faster than light latencies, though?  Pshaw   I'll eat those words when it happens, but not til then.

[x4000]

Well, you never know, but quantum mechanics is a real thing.  I could just as easily eat my words.  But at the very least, it says how unlikely I think the splitting-single-threaded-code-into-multiple-cores thing is. Faster than light ethernet seems much more likely by comparison.

[RCIX]

(I have a fairly solid idea of how to get around the real showstoppers, it would just involve, oh, overhauling the whole codebase and changing the actual gameplay logic a fair bit)

And i suppose you can only do that once a year?

[keith.lamothe]

And i suppose you can only do that once a year?

The port from .NET/SlimDX to Unity3D pales in comparison to the changes I'd have to make to get this running smoothly on n-cores