Multi core processor support in CoD

[Heliocon]

Originally Posted by mazex

You have an attitude that's really starting get boring. Yes I maybe lied a bit - the last 5 years I've been manager of a development department at a company that has done high preformance multi threaded code since 1994. Thereby I have not been programming 12 hour a day like before. You lack of knowledge about c/c++ really shows as it is the language that most multi threaded applications are written in (like Windows 7 ). It's obviuos that you don't understand what a thread is and how they are created so discussing this feels like talking programming with an 18 year old that has done some "web programming"...

I will not continue this discussion so please don't paste more text you don't understand from wikikpedia/tomshardware.

Why did I really feed this troll? I usually manage to restrain myself from that.

PS. Send me you linked in profile in a PM and I will send you mine if you promise to not post it further. I really like to be able to participate in forums like this without using my real name as I don't want to mix my private interests with my business profile....

Wait, I am the troll? You just admited to lying and I called you out on it. Therefore I am the troll? You then result to personal insults based on no substance (all you are saying is, you dont understand the programming, you must be 18 and a kiddy, therefore I my argument is correct because I can demean you, inflate myself and try to be intimidating). Again Ad Hominem attacks... Does calling me 18 and saying I am wrong without providing one shred of evidence/proof/info really prove your point? I never said C++ cannot programme multi threaded apps, I quoted the wiki there about its native abilities but more to outline the point about the 20 yrs. I called BS on your claim of experience due to the length of time and other things you have said. You have still not addressed any of my points though, dont bother replying because it is obvious you dont want a discussion/debate here because you got caught like a deer in the headlights. Also I am not a professional programmer, never claimed to be, I do know a good deal about hardware and its interactions with software though.
Btw never done any web programming, but its sad you cant hold up a argument vs a 18 year old...

[mazex]

Originally Posted by Heliocon

Wait, I am the troll? You just admited to lying and I called you out on it. Therefore I am the troll? You then result to personal insults based on no substance (all you are saying is, you dont understand the programming, you must be 18 and a kiddy, therefore I my argument is correct because I can demean you, inflate myself and try to be intimidating). Again Ad Hominem attacks... Does calling me 18 and saying I am wrong without providing one shred of evidence/proof/info really prove your point? I never said C++ cannot programme multi threaded apps, I quoted the wiki there about its native abilities but more to outline the point about the 20 yrs. I called BS on your claim of experience due to the length of time and other things you have said. You have still not addressed any of my points though, dont bother replying because it is obvious you dont want a discussion/debate here because you got caught like a deer in the headlights. Also I am not a professional programmer, never claimed to be, I do know a good deal about hardware and its interactions with software though.
Btw never done any web programming, but its sad you cant hold up a argument vs a 18 year old...

Like I said - please PM your LinkedIn profile and I will give you mine if you doubt my claims of experience. Now let's quit this argument that will lead nowhere.

[Heliocon]

Originally Posted by mazex

Like I said - please PM your LinkedIn profile and I will give you mine if you doubt my claims of experience. Now let's quit this argument that will lead nowhere.

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.

[Skinny]

I havent coded in like 20 years, but mazex is spot on. People who think creating a game engine that can make proper use of 2/4/8 or more threads is easy need to do some reading. There is a reason most software today barely scales beyond 2 threads. Heliocon, maybe you should just try it.

What I am curious about is the physx claim, that it would be useless for flightsims. I dont know about the API, maybe that is useless, but calculating the physics (rather than PhysX) does seem something that could benefit greatly from GPGPU (CUDA or OpenCL).

[Heliocon]

Originally Posted by Skinny

I havent coded in like 20 years, but mazex is spot on. People who think creating a game engine that can make proper use of 2/4/8 or more threads is easy need to do some reading. There is a reason most software today barely scales beyond 2 threads. Heliocon, maybe you should just try it.

What I am curious about is the physx claim, that it would be useless for flightsims. I dont know about the API, maybe that is useless, but calculating the physics (rather than PhysX) does seem something that could benefit greatly from GPGPU (CUDA or OpenCL).

Hey, why dont you read my bloody posts before you comment? I never said it was easy, I infact said it was hard to do. Dont put words in my mouth. I took issue with his definitions of memory which are factually incorrect.

Also physx (which I never mentioned btw as someone implied I did) is mainly geared to particles and cloth/hair etc. It would certainly work for stuff like clouds and smoke that interact with planes passing through, but I dont know of its effects on flight models. CUDA is meh.

[Skinny]

Originally Posted by Heliocon

Also physx (which I never mentioned btw as someone implied I did) is mainly geared to particles and cloth/hair etc. It would certainly work for stuff like clouds and smoke that interact with planes passing through, but I dont know of its effects on flight models. CUDA is meh.

Particles is what its mostly used for, for obvious reasons: many (/most) gamers dont have physx enabled hardware, therefore its used for eye candy that can easily be turned off without affecting actual gameplay.

That doesnt mean its not usable for physics simulation like aerodynamics. Surely you've seen all the hydrodynamics simulations. If it works for water, I dont see why it couldnt work for air:

http://www.youtube.com/watch?v=ok8ThRR-59Q

[Heliocon]

Originally Posted by Skinny

Particles is what its mostly used for, for obvious reasons: many (/most) gamers dont have physx enabled hardware, therefore its used for eye candy that can easily be turned off without affecting actual gameplay.

That doesnt mean its not usable for physics simulation like aerodynamics. Surely you've seen all the hydrodynamics simulations. If it works for water, I dont see why it couldnt work for air:

No reason that I know off, I just dont know how they manage the flightmodel/air interaction. If there "zones"/boxes of air with different property? So If I enter one area I get turbulence or something? Or is it managed dynamically or prodcedually? I have no idea tbh

The main difference is Physx is not really a mechanic focused on physics as much as it is focused on solving and then "presenting" the effects. Its also GPU tied which needs to be rendering. Physx is great, but unless you have a dedicated card its better to buy a second card then have a non physx gpu. Atleast thats what people seem to think on the EVGA forums.

[The Kraken]

Originally Posted by Skinny

Particles is what its mostly used for, for obvious reasons: many (/most) gamers dont have physx enabled hardware, therefore its used for eye candy that can easily be turned off without affecting actual gameplay.

That doesnt mean its not usable for physics simulation like aerodynamics. Surely you've seen all the hydrodynamics simulations. If it works for water, I dont see why it couldnt work for air

Well air is compressible, water is not PhysX is primarily designed for rigid body physics (the water animation also belongs to that area) and not too useful for more complex problems, although I have to admit I'm not sure what the most current state of the API is.

The bigger problem though is this: the flight dynamics engine is the core of any flight sim. You cannot rely on proprietary solutions like PhysX because you have to make sure it works for everyone, and also the same for everyone. It is much harder to debug, it is additional work even if only parts of the calculations are moved to the GPU and you run the risk of ending up with a dead solution should nVidia decide to drop it one day or maybe go out of business.

[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