Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Bottleneck in my program..... HELP!

Author
Message
Hawkblood
14
Years of Service
User Offline
Joined: 5th Dec 2009
Location:
Posted: 13th Nov 2012 05:02
Link
I have run into a huge issue. This section of code is causing a bottleneck when run. It's a very small section of a much larger program.

tp2 is a global variable I use for troubleshooting code. I normally use it like I have it here, as a counter. In this instance it never meets the condition, so tp2 never increments.
I run my program, and initially, I get 60fps. I press a key to activate the code and it slows to 20fps! If I take out the line "tp2++;" and run the code, it runs at 60fps all day long..... This is a strange occurence to say the least. Since that line is not even reached (because the previous condition is never met), how can it affect my program?

The fastest code is the code never written.
Back to top
Profile PM Email Website
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 13th Nov 2012 08:53
Link
Maybe there is some compiler-magic happening in the optimization process...

I could think of the compiler automatically stripping out all instructions relating to the object "AS" because its only purpose is to be evaluated in the "if" condition. Now if the curly brackets of this "if" statement are completly empty (by commenting out "tp2++") the compiler may be smart enough to avoid anything relating to "AS", especially the more computationally intense divide "AS/=1000"!

Also I would advise to get rid of the divisions by replacing them with multiplications, which are faster to compute, e.g. "Sector /= 1000" -> "Sector *= 0.001f".

Back to top
Profile PM Email Website
Hawkblood
14
Years of Service
User Offline
Joined: 5th Dec 2009
Location:
Posted: 13th Nov 2012 09:58
Link
Quote: "Now if the curly brackets of this "if" statement are completly empty "
Sadly this is not the case. I had other code inside the {} that *didn't* cause the slowdown. Some did and some didn't. I isolated the code that was causing it and // it out. After I saw this, I put in the counter to see how many times the condition is being met. It was NEVER being met. And the addition of the counter INSIDE the {} (that was never being executed) caused it to slow down!

I think you may be right about the compiler, but I can't seem to figure out what setting could cause this. I have it set to "optimize for speed".

I have another thought. At every condition, the processor makes a "guess" as to what the answer will be (for the look ahead cache). When it gets to the condition, if it "guessed" wrong, it has to dump the cache and go from there. Perhapse it's "guessing" wrong every time.....?

The code you see is not the original code I was using, but it is exhibits exactly the same problem (with less code). And this code is exactly what I have in my game so I can figure out why it's happening.

Are the laws of logic breaking down here?

The fastest code is the code never written.
Back to top
Profile PM Email Website
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 13th Nov 2012 10:17
Link
Have you tried to comment out the inner-most "if" statement completly, to see if the evaluation of the conditions may be the issue?

Have you tried to replace the divisions with multiplications? Did it have any effect on performance?

Back to top
Profile PM Email Website
Hawkblood
14
Years of Service
User Offline
Joined: 5th Dec 2009
Location:
Posted: 13th Nov 2012 10:25
Link
I have taken it out and the slowdown doesn't happen. The only time the problem occurs is when I have certain variables inside the {}. Some variables don't cause it, but some do. It's VERY weird! I'm not home right now, but I will try replacing the / with *.

It just seems like regardless of what is inside the {}, if it NEVER executes the code, it should have no effect on the fps.....

The fastest code is the code never written.
Back to top
Profile PM Email Website
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 13th Nov 2012 10:59
Link
Well, you have to consider that even evaluating an "if"-condition takes some time to compute!

You should also investigate you're classes/structs carefully, too.

Back to top
Profile PM Email Website
Hawkblood
14
Years of Service
User Offline
Joined: 5th Dec 2009
Location:
Posted: 13th Nov 2012 11:00
Link
Quote: "You should also investigate you're classes/structs carefully, too."

What do you mean?

The fastest code is the code never written.
Back to top
Profile PM Email Website
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 13th Nov 2012 12:43
Link
I just meant you should take care of your custom operators in your classes. But since your classes here are integer-based I guess that there is no issue involved that could cause a bottleneck. Sometimes people mess around with type conversions and stuff that could cause problems...

Back to top
Profile PM Email Website
Hawkblood
14
Years of Service
User Offline
Joined: 5th Dec 2009
Location:
Posted: 13th Nov 2012 13:10
Link
Yea. I have my compiler set up to tell me if there is a missmatch of types (don't know how, but it's set up that way).

I think I may be able to work around it some by taking the collision detection part out of its own function and placing it in the main function for moving the ships. This is messy, but so far it seems to work as long as I use local variables instead of globals or std::vector types. There may be an issue with calling far pointers 100,000 times per frame for every ship.
All the asteroids and ships are in std:vector structures. I don't change any values within the asteroid structure, but I do need to change values within the ship's structure when it encounters an obstacle like an asteroid. So far I am using only local variables to store these states, and it seems to be working. (I hate making a work-around)...... Stuff should just work!

It's a lack of knowlege on my part.

The fastest code is the code never written.
Back to top
Profile PM Email Website
WLGfx
16
Years of Service
User Offline
Joined: 1st Nov 2007
Location: NW United Kingdom
Posted: 13th Nov 2012 14:01 Edited at: 13th Nov 2012 14:03
Link
The first thing I'd do is change "for (UINT a=0;a<GE->AC[i].Asteroid.size();a++)"
to:

as you're not then calling a function for every compare in the loop.

Without know the rest of the structure of the class, I'd probably go for breaking down the variables within the loops instead of constantly offsetting them with first.second.third[i].fourth as each time it produces a lot of code to be run within the loop. Pull these values out if possible before the loop starts.

Mental arithmetic? Me? (That's for computers) I can't subtract a fart from a plate of beans!
Warning! May contain Nuts!
Back to top
Profile PM Email Website
Hawkblood
14
Years of Service
User Offline
Joined: 5th Dec 2009
Location:
Posted: 13th Nov 2012 15:21
Link
Thanks. I didn't think of that loop issue.....

The fastest code is the code never written.
Back to top
Profile PM Email Website
Dar13
15
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 14th Nov 2012 03:42
Link
Other than that, it might be the fact that it's a nested for-loop. That's usually pretty bad for realtime performance.

It's not optimization magic unless you're running in Release mode, in which case you need to go into the project settings and turn off the optimization as that is horrible for debugging purposes.

Also, try profiling your code using either Visual Studio's utility(not sure if it's available outside of VS2010 Pro) or with AMD's profiler. Also, check out a static code analysis tool(CppCheck is a pretty good free one).

Figuring out a bottleneck can be quite frustrating.

Follow WTLD's progress on Twitter
Git repository for WasTeLanD
Back to top
Profile PM Email
Hawkblood
14
Years of Service
User Offline
Joined: 5th Dec 2009
Location:
Posted: 14th Nov 2012 18:13
Link
Quote: "Figuring out a bottleneck can be quite frustrating.
"

Yes, it is. I know where it is occuring. I just don't know why. The loop runs at 60fps unless I put certain variables inside the condition. It drops to 20fps when I put in a simple counter with nothing else!

Anyway, I figured a work-around. I am only checking the asteroids that are only a little further than visual range. I had a section of code that made a list of those asteroids anyway, so I just utilized that list instead of checking each asteroid. The fields are so sparsely populated anyway that I only have to deal with about 100-200 at a time.

I would still like to know why adding just a single counter would cause this much speed loss......

The fastest code is the code never written.
Back to top
Profile PM Email Website
WLGfx
16
Years of Service
User Offline
Joined: 1st Nov 2007
Location: NW United Kingdom
Posted: 14th Nov 2012 22:02
Link
I had another look at the code and came up with this:



By assigning a ptr to the most used object 'myGEACIptr' reduces generated code each time it is used. And moving other declarations outside of the inner scopes, to reduce to amount of stack alterations during scope changes to generated output code. It's probably likely that the compiler may do this with some settings anyway but hey, I spotted it. This is mostly true when assigning some classes inside a scope when it requires itself to allocate memory and de-allocate it when it goes out of scope again. That's why I moved them outside, just in case. It might work...

Mental arithmetic? Me? (That's for computers) I can't subtract a fart from a plate of beans!
Warning! May contain Nuts!
Back to top
Profile PM Email Website
Hawkblood
14
Years of Service
User Offline
Joined: 5th Dec 2009
Location:
Posted: 15th Nov 2012 11:43 Edited at: 18th Nov 2012 12:45
Link
tp2 is just a global variable I use as a counter for troubleshooting. Its value is registered on the screen so I can see it in real time.

I don't understand why a pointer would help it be faster.....

I tried it. No difference (that I could see).

The fastest code is the code never written.

Attachments

Login to view attachments
Back to top
Profile PM Email Website
WLGfx
16
Years of Service
User Offline
Joined: 1st Nov 2007
Location: NW United Kingdom
Posted: 15th Nov 2012 20:09
Link
What I did was really only shave a little time off the routine.

The ptr also shaves off a little time used to assign the data to the register when its compiled. It was used often so I added that in.

Hope you get something sorted with it man... Good luck...

Mental arithmetic? Me? (That's for computers) I can't subtract a fart from a plate of beans!
Warning! May contain Nuts!
Back to top
Profile PM Email Website
Back to top

Login to post a reply

Server time is: 2024-04-20 11:31:56
Your offset time is: 2024-04-20 11:31:56