Multi core processor support in CoD

[mazex]

Originally Posted by Heliocon

I dont give a damn about your experience whether it is true or false (well we already know something about that I guess). I do give a damn about you bsing me and saying I dont know what I am talking about, but you are not able to give a coherent or even articulate an argument / point to contest my observation with. I will not be contacting you so that you can save face, sorry.

OK - please calm down. Let me try to explain what I mean then...

Well, I did write a long example with pseudo code and all in my second post in this thread but deleted it as it was to long winded. I realize that you actually think you are right and then naturally think that I'm just talking bull so let's try to sort this out then.

I think that the problem is that you have maybe confused threads and cores in some way. When you write a Windows program it will run in a process and if you do no not create more threads yourself in the code it will just run on a single thread. That thread in it's turn can only run on one CPU or Core (and the OS assigns that if you don't mess with that yourself which really should not be done) . So a game that does not create additional threads will run on one core... It will do calls to the OS that will use other threads for that but generally it will just load one core itself. Then to use the other cores you have to create new threads from your code and start them yourself in the code. The OS can then let them run on one of the other cores or CPU:s if available or chop the time on the CPU between the threads if you have only one CPU/Core. OK - so the threads run in the same process but one of the problems is that if they are going to access shared memory (variables like the state of the me 109 in front of you) they may try to update the same shared memory (like an array of detected enemies that is a private variable in the CFighterPlane object) and that's a no no. Therfore you have to make sure that the thread that is going to update that shared variable get's exclusive access to the variable while updating it - which is essential if you are going to write thread safe code (handled by identifying these critical sections and make sure to exclusive access that memory while updating it so no other thread does that at the same time). The problem is also that both the AI thread (if you create a thread for that in your code and the OS then assigns that thread to run on a core.) and the code for the Collision detection might want to update the number of enemies detected by that specific enemy plane object as the collision detection code has just "killed" that same enemy plane that crashed into a mountain in classic IL2 way The AI code is then on the same time trying to update the object that got "killed" to try to avoid the mountain. What happens then? Those problems are really hard to debug in multi threaded code as opposed to traditional single threaded code that can be debugged line for line but the in the multi threaded code your breakpoint at the part of the code that detected the collision will stop but what is the state of the other thread? Those problems are hard to solve and if your AI thread is milling along updating the "inputs" for the AI planes the render loop has to know that as it updates the actual meshes loaded to the GPU each loop in the main game loop. Not trying to push you down but trying to explain - OK?

/Mazex

[Heliocon]

Originally Posted by mazex

OK - please calm down. Let me try to explain what I mean then...

Well, I did write a long example with pseudo code and all in my second post in this thread but deleted it as it was to long winded. I realize that you actually think you are right and then naturally think that I'm just talking bull so let's try to sort this out then.

I think that the problem is that you have maybe confused threads and cores in some way. When you write a Windows program it will run in a process and if you do no not create more threads yourself in the code it will just run on a single thread. That thread in it's turn can only run on one CPU or Core (and the OS assigns that if you don't mess with that yourself which really should not be done) . So a game that does not create additional threads will run on one core... It will do calls to the OS that will use other threads for that but generally it will just load one core itself. Then to use the other cores you have to create new threads from your code and start them yourself in the code. The OS can then let them run on one of the other cores or CPU:s if available or chop the time on the CPU between the threads if you have only one CPU/Core. OK - so the threads run in the same process but one of the problems is that if they are going to access shared memory (variables like the state of the me 109 in front of you) they may try to update the same shared memory (like an array of detected enemies that is a private variable in the CFighterPlane object) and that's a no no. Therfore you have to make sure that the thread that is going to update that shared variable get's exclusive access to the variable while updating it - which is essential if you are going to write thread safe code (handled by identifying these critical sections and make sure to exclusive access that memory while updating it so no other thread does that at the same time). The problem is also that both the AI thread (if you create a thread for that in your code and the OS then assigns that thread to run on a core.) and the code for the Collision detection might want to update the number of enemies detected by that specific enemy plane object as the collision detection code has just "killed" that same enemy plane that crashed into a mountain in classic IL2 way The AI code is then on the same time trying to update the object that got "killed" to try to avoid the mountain. What happens then? Those problems are really hard to debug in multi threaded code as opposed to traditional single threaded code that can be debugged line for line but the in the multi threaded code your breakpoint at the part of the code that detected the collision will stop but what is the state of the other thread? Those problems are hard to solve and if your AI thread is milling along updating the "inputs" for the AI planes the render loop has to know that as it updates the actual meshes loaded to the GPU each loop in the main game loop. Not trying to push you down but trying to explain - OK?

/Mazex

Good explanation. I understand what you are saying and it does indeed seem like a plausible problem. The one question though is when you say memory, what are you refering to in the system? Is this cpu cache? It may be harder to program but parallel processing is still faster then serial, even if it may be more difficult to work with (I would argue that its more of an issue with people adjusting to the new "format" and that over time it will become much easier.)
I understand the differance between threads, cores, processes etc

Also the reason I hate programming is debugging because I accidently put a comma or a mistype somewhere and the whole damn thing goes nuts and spams me with errors and I cry into my keyboard as I spend the next day going through 1 hour of code to find the mistake

[mazex]

Originally Posted by Heliocon

Good explanation. I understand what you are saying and it does indeed seem like a plausible problem. The one question though is when you say memory, what are you refering to in the system? Is this cpu cache? It may be harder to program but parallel processing is still faster then serial, even if it may be more difficult to work with (I would argue that its more of an issue with people adjusting to the new "format" and that over time it will become much easier.)
I understand the differance between threads, cores, processes etc

Also the reason I hate programming is debugging because I accidently put a comma or a mistype somewhere and the whole damn thing goes nuts and spams me with errors and I cry into my keyboard as I spend the next day going through 1 hour of code to find the mistake

Good that we have normalized the situation then

No - that memory I'm talking about is just the RAM memory that the threads share and that is allocated to the process and it's subthreads by the OS. That memory is then divided into the stack (variables, structs etc - normally with short lifespan that is "cheap" and fast) and the heap (where objects etc are dynamically stored for a longer time and you allocate and deallocate that memory yourself (and it is slower than the stack)). This is all stored in RAM unless the OS decides to swap it to disk if it runs out of memory (but you are fine with your 12 GB ). The fact that the CPU then uses registers (memory) etc is something a "normal" programmer never mess with in normal cases with modern programming languages....

If you did not like debugging straight single thread code you can imagine doing that in multi threaded code with eight threads messing with each other and you don't really know the state of that 109... Is it dead or alive? The CollisionAndResponse thread thinks it is not but the AIThread does not know that so can we call it the opposite of brain dead?

[Jones]

Bravo, mazex! I applaud your patience and the clarity of your explanation!

[mazex]

Originally Posted by Jones

Bravo, mazex! I applaud your patience and the clarity of your explanation!

Thanks!

[Heliocon]

Originally Posted by mazex

Good that we have normalized the situation then

No - that memory I'm talking about is just the RAM memory that the threads share and that is allocated to the process and it's subthreads by the OS. That memory is then divided into the stack (variables, structs etc - normally with short lifespan that is "cheap" and fast) and the heap (where objects etc are dynamically stored for a longer time and you allocate and deallocate that memory yourself (and it is slower than the stack)). This is all stored in RAM unless the OS decides to swap it to disk if it runs out of memory (but you are fine with your 12 GB ). The fact that the CPU then uses registers (memory) etc is something a "normal" programmer never mess with in normal cases with modern programming languages....

If you did not like debugging straight single thread code you can imagine doing that in multi threaded code with eight threads messing with each other and you don't really know the state of that 109... Is it dead or alive? The CollisionAndResponse thread thinks it is not but the AIThread does not know that so can we call it the opposite of brain dead?

Thank you for the responses Maze, I know my tone can be abrasive but I am not looking around to pick a fight here. The issue with the ram was I thought you were talking about the CPU cache (for example i7 uses two 4mb cache's, 4mb for 2 cores/4 threads). This is what I was trying to get at originaly, the conversation then nosedived, so from my view I was arguing about hardware allocation. But yes again I never said multi threaded programming was easy, just that it was necessary since clock speeds are not increasing like they used to.

Anyway thanks for the polite and well thought out responses, but be wary my eye in the sky is watching for you to make a minor grammatical error so I can wtf divebomb you and call you an old fart who programmed typewriters for 20 years

[mazex]

P

Originally Posted by Heliocon

Anyway thanks for the polite and well thought out responses, but be wary my eye in the sky is watching for you to make a minor grammatical error so I can wtf divebomb you and call you an old fart who programmed typewriters for 20 years

Thanks, and I'm sorry I had a tough attitude too when replying first. As seen here that just escalates an argument which is in most cases built upon a misunderstanding of what the other person is saying and that we then think we understand what they really think

And regarding typewriters I don't have that (yet ) in my cv after many years as a software consultant. The most "boring" project I've been on must be climate control systems (not the small ones for cars), but then again - programming is never boring once you get over the first frustration while learning to write thread safe code for example...

[mazex]

Originally Posted by Heliocon

Thank you for the responses Maze, I know my tone can be abrasive but I am not looking around to pick a fight here. The issue with the ram was I thought you were talking about the CPU cache (for example i7 uses two 4mb cache's, 4mb for 2 cores/4 threads). This is what I was trying to get at originaly, the conversation then nosedived, so from my view I was arguing about hardware allocation. But yes again I never said multi threaded programming was easy, just that it was necessary since clock speeds are not increasing like they used to.
o

OK - I understand. If you now get the concept I described that the programmer has to create threads himself or everything runs in one thread etc, then read the wikipedia article about Hyper-threading which I think is what confused you (and many else!):

http://en.wikipedia.org/wiki/Hyper-threading

So in a hyperthreaded CPU the OS thinks it has two CPU:s (or cores - whatever). It can then run the main game loop thread on the first one and the AI thread on the other (from the previous example). The problem (or finesse) is then that the CPU uses it's registers and fat cache to internally switch between the threads without the OS having to care or do that as the CPU has better and faster knowledge about when there is a "slot" of idle time in the game loop so the AI thread can get access to the actual CPU (which is only one). This does not fix the problem of knowing if that 109 is dead or alive though as the two threads running on what both the OS and your code thinks is two really CPU:s don't get any help from this - and they have to be written just like a normal multithreaded application... And if one of the threads constantly uses the single CPU that other thread will not get any cycles to the CPU has to force it into wait and give some CPU time to the AI thread... Therefore HT can be good in some cases but as it's really a smart way to fill available slots of excecution time - but there is really only one "brain"...

[addman]

Let this thread be a sticky on how you can resolve arguments without flinging crap at each other. Very well done gentlemen! I also applaud you

[Heliocon]

Originally Posted by mazex

OK - I understand. If you now get the concept I described that the programmer has to create threads himself or everything runs in one thread etc, then read the wikipedia article about Hyper-threading which I think is what confused you (and many else!):

http://en.wikipedia.org/wiki/Hyper-threading

So in a hyperthreaded CPU the OS thinks it has two CPU:s (or cores - whatever). It can then run the main game loop thread on the first one and the AI thread on the other (from the previous example). The problem (or finesse) is then that the CPU uses it's registers and fat cache to internally switch between the threads without the OS having to care or do that as the CPU has better and faster knowledge about when there is a "slot" of idle time in the game loop so the AI thread can get access to the actual CPU (which is only one). This does not fix the problem of knowing if that 109 is dead or alive though as the two threads running on what both the OS and your code thinks is two really CPU:s don't get any help from this - and they have to be written just like a normal multithreaded application... And if one of the threads constantly uses the single CPU that other thread will not get any cycles to the CPU has to force it into wait and give some CPU time to the AI thread... Therefore HT can be good in some cases but as it's really a smart way to fill available slots of excecution time - but there is really only one "brain"...

I know about hyperthreading (cores vs threads etc).
I wonder how different bulldozer will be interms of programming for it. Havent heard a huge amount on it tbh.