Threading
Threading
Ahhhhhh, I've been in thread hell for a couple of weeks. Since most have multi core processors, it's foolish to not try and get at least one thread in there to speed things up.
It requires a bunch of rewrites and it's scary because our MP is working great and this is just going to mess stuff up again.
The initial work is fairly easy. Keep the drawing code on the main thread and move all the logic/updating code to a new thread. Lots of easy bugs and it works. Picked up around 10 frames. But I noticed something odd, every once in a while, on 1 frame a guy would be drawn in the sky, then immediately back to the ground. I ignored it for now and went to try MP. Basic crashes, basic fixes. Go it running, though there are still kinks to work out. Then I hit a snag, out of sync. Repeatable, a few minutes in every time. It was the height again. The same drawing error was now being used in the logic and causing an out of sync. I narrowed it down to the height function. I went through all my code and could not find an error. So I had to go into the powerrender code. Could not find a problem there either.
Looked closer, there was a define in there that led me to some assembler code. I don't really know assembler, but I found a class variable being used as a temporary holder (BAD IDEA IN THREADS).
In case you are still following me
PR:height()
{
int a;
PR:temp = a;
// some calcs
return a;
}
not the real function, but you can see what's not threadsafe. Because if two different threads enter this function at the same exact time, they are both trying to set the same variable, PR:temp and use it. So this is not threadsafe. The local variable (a) is ok because it's different for each instance of the function. But to save a temporary variable in a common location is not good. Not threadsafe.
So what was happening is that they both ran this function at the same exact time, so which ever function was last, got PR:temp set, then they both used that value. So for 1 frame you had a bad value for terrain height.
I know, it's techy, but thought I would share and document before I forget what I did. In order to work so many different pieces of code I have to learn a lot about unfamiliar areas. I'm pretty good at that, but the downside is that I braindump information just as fast, so I'll forget what I did. So I document a lot and put in comments to remind myself where I've been and what I've touched.
It requires a bunch of rewrites and it's scary because our MP is working great and this is just going to mess stuff up again.
The initial work is fairly easy. Keep the drawing code on the main thread and move all the logic/updating code to a new thread. Lots of easy bugs and it works. Picked up around 10 frames. But I noticed something odd, every once in a while, on 1 frame a guy would be drawn in the sky, then immediately back to the ground. I ignored it for now and went to try MP. Basic crashes, basic fixes. Go it running, though there are still kinks to work out. Then I hit a snag, out of sync. Repeatable, a few minutes in every time. It was the height again. The same drawing error was now being used in the logic and causing an out of sync. I narrowed it down to the height function. I went through all my code and could not find an error. So I had to go into the powerrender code. Could not find a problem there either.
Looked closer, there was a define in there that led me to some assembler code. I don't really know assembler, but I found a class variable being used as a temporary holder (BAD IDEA IN THREADS).
In case you are still following me
PR:height()
{
int a;
PR:temp = a;
// some calcs
return a;
}
not the real function, but you can see what's not threadsafe. Because if two different threads enter this function at the same exact time, they are both trying to set the same variable, PR:temp and use it. So this is not threadsafe. The local variable (a) is ok because it's different for each instance of the function. But to save a temporary variable in a common location is not good. Not threadsafe.
So what was happening is that they both ran this function at the same exact time, so which ever function was last, got PR:temp set, then they both used that value. So for 1 frame you had a bad value for terrain height.
I know, it's techy, but thought I would share and document before I forget what I did. In order to work so many different pieces of code I have to learn a lot about unfamiliar areas. I'm pretty good at that, but the downside is that I braindump information just as fast, so I'll forget what I did. So I document a lot and put in comments to remind myself where I've been and what I've touched.
Re: Threading
Norb wrote:
B
Years ago I had a friend who worked for the Social Security Administration and he said all the code for their programs was written in Fortran and so many programmers had modified things, some with little or no documentation, that it was going to be easier and cheaper to start over from scratch than to try to migrate the system. Basically nobody could figure out what had been done or how it worked. It just did.I'm pretty good at that, but the downside is that I braindump information just as fast, so I'll forget what I did. So I document a lot and put in comments to remind myself where I've been and what I've touched.
B
"Those in whose judgment I rely, tell me that I fought the battle splendidly and that it was a masterpiece of art.” - George McClellan to his wife describing the battle of Antietam
Re: Threading
Well despite all of the ups and downs, and the long hours that this is taking you, I’m glad that you are doing it!
Ten more frames-per-second is great, even if that drops down a little bit, seven more frames-per-second will benefit almost everyone.
I thought that the PR Program was written in C+ or C++ , are there still some sections of the code that is only written in Assembly Language?
I haven’t even heard no-one mention that word (Assembly Language) in twenty plus years.
davinci
Ten more frames-per-second is great, even if that drops down a little bit, seven more frames-per-second will benefit almost everyone.
I thought that the PR Program was written in C+ or C++ , are there still some sections of the code that is only written in Assembly Language?
I haven’t even heard no-one mention that word (Assembly Language) in twenty plus years.
davinci
The only true logic is that, there is no true logic!
-
- Reactions:
- Posts: 114
- Joined: Sat Mar 27, 2010 4:50 pm
Re: Threading
I got introduced to threaded programming a couple of years back and I'm running the lab coursework on threaded Java programming at our university. It can be a real pain in the arse to try and make sure there are no variables or anything you access in an unsafe order. You have to employ locks but then the purpose of parallel computing kind of suffers.
http://mazikainen.blogspot.com My wargaming blog
-
- Reactions:
- Posts: 1769
- Joined: Mon Mar 29, 2010 9:56 pm
Re: Threading
Davinci wrote:
Norb wrote:
You are nekulturny. It's usually a good idea to write the parts of the code that run frequently in ASM. That way the coder can optimize it for the best possible speed.I haven’t even heard no-one mention that word (Assembly Language) in twenty plus years.
Norb wrote:
That should pop up as a warning in the visual c compiler. It always bashes me for doing that. On another note, the issue of synching the 3D view with the calcs has been a recurrent problem for HistWar too. Although JMM has gotten rid of most of the problems, there are still instances when the 3D view does not at all reflect what is actually happening. It occasionally results in some very bizarre views.Looked closer, there was a define in there that led me to some assembler code. I don't really know assembler, but I found a class variable being used as a temporary holder (BAD IDEA IN THREADS).
I can make this march and I will make Georgia howl.
Re: Threading
Whoa – I had to google that word, now that would be considered an idiotic assessment on your part!Davinci wrote:You are nekulturny. .I haven’t even heard no-one mention that word (Assembly Language) in twenty plus years.
davinci
The only true logic is that, there is no true logic!
Re: Threading
Yes, PR is written in C++, but there are a few parts in assembly for speed. Also the absolute fastest you can use is straight C. Some options available in C++ make things slower, but it results in cleaner code and good code design is easier to maintain.
Very thankful that I got the code to the engine, I've made a ton of modifications specific to our platform. It's fun to play with, but I still cannot do matrices (an absolute MUST for 3D graphic programmers)
Very thankful that I got the code to the engine, I've made a ton of modifications specific to our platform. It's fun to play with, but I still cannot do matrices (an absolute MUST for 3D graphic programmers)
Re: Threading
Norb – are you planning on releasing this multi-core-fix for this engine, or is this going into the newer game?
Also, if this is applied to this engine, will this be the only fix in the patch except for minor tweaks pertaining to if this breaks anything?
Will this be available this year (i.e.….only two months left) or will this process take a while longer?
Thanks,
davinci
Also, if this is applied to this engine, will this be the only fix in the patch except for minor tweaks pertaining to if this breaks anything?
Will this be available this year (i.e.….only two months left) or will this process take a while longer?
Thanks,
davinci
The only true logic is that, there is no true logic!
Re: Threading
At this point, the plan is that the threading would be part of a major new game release. This affects both SP and it presents significant issues in getting this in without breaking MP. It will take a lot of testing before we are comfortable in releasing a change this significant.
We do have some plans for something else coming out this year, announcement is very close, stay tuned.
-Jim
We do have some plans for something else coming out this year, announcement is very close, stay tuned.
-Jim
"My God, if we've not got a cool brain and a big one too, to manage this affair, the nation is ruined forever." Unknown private, 14th Vermont, 2 July 1863
Re: Threading
Well, that is not very good news at all for the current game, but I understand that this is a Command Decision that probably affects things that are beyond my understanding. So I can’t really complain about something that was never mentioned as part of this release.At this point, the plan is that the threading would be part of a major new game release.
Understandable!This affects both SP and it presents significant issues in getting this in without breaking MP. It will take a lot of testing before we are comfortable in releasing a change this significant.
I hope so; this forum really does need something new, there has not been too much of anything going on lately, as I’m sure everyone has noticed!We do have some plans for something else coming out this year, announcement is very close, stay tuned.
Thanks for the reply back Jim !
davinci
The only true logic is that, there is no true logic!