Darwinbots Forum

Code center => Darwinbots Program Source Code => Topic started by: Botsareus on November 06, 2013, 04:19:10 PM

Title: No fix for ghost collisions with planet eaters necissary
Post by: Botsareus on November 06, 2013, 04:19:10 PM
Due to the fact that vegys are massive, I no longer see the need to restrict robot collisions where they spring past each other, in most cases the robot settle on the vegys and no weird erratic behavior is observed.

I did however notice a 50% decrease in speed vs running the same simulation on 2.45.01. Probebly due to the whole new chloroplast system. Nothing I can really do about that except maybe get an AMD Bulldozer for my laptop, not happening though, I even dk if my laptop supports it.
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Peter on December 30, 2013, 06:01:06 PM
You got a (new) amd laptop?
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Numsgil on December 30, 2013, 10:18:38 PM
It's probably worth running the program in a profiler and make certain what's actually causing it to run slowly.  Often you'd be surprised by what's taking longer or what's not taking any time at all.  Even with years of experience writing performance critical code I still get my ass handed to me by weird functions that I didn't think would ever bubble up to the top of a performance capture.
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Botsareus on January 01, 2014, 10:15:53 AM
 :blink: I am a little scared actually putting this thing in to sleepy profiler, Due to the sh*t load of code in this program I am afraid it will take me like a month to go trough it all.

Maybe if I have some time later on my tower once I get everything else going on my laptop

That being said,

What am I supposed to look for Numsgil? All I will get back is % of how much each section of code executed. Will I have to compare it vs how 2.45 runs, and start drilling down deeper into the code in places where it looks like it is taking longer then it should?
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Numsgil on January 01, 2014, 02:10:49 PM
It's not % each section is called, it's % each section is taking up in the overall execution time.

See if you can find a tree view for the performance details.  That tells you callstacks, which is useful if all the time is in a vector add method and you need to know what's calling it.

Usually there's like 90% of the program running time in like 10% of the code.  Identifying what's running slow is the first step in fixing it.  Maybe it's something that's easy to fix.  Maybe it's something that's hard.  Either way, you won't know if you don't look.

Yes, profilers are a bit scary to figure out, but if I could figure out how to use a version of VTune from 8 years ago to profile Darwinbots you can use a profiler too.
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Botsareus on January 02, 2014, 10:12:05 AM
Ok man, I will try it.
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Botsareus on January 24, 2014, 02:19:38 PM
Did not find anything that jumped out at me. There was small variation but that is probably due to cpu hits being different. I was very surprised how little the new vegy code had on the system as long as video was off.
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Numsgil on January 25, 2014, 01:45:07 AM
Where is most of the time going then?
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Botsareus on January 25, 2014, 11:50:57 AM
There was a large change with video on...
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Botsareus on January 25, 2014, 12:22:09 PM
Here Numsgil, maybe you can dig up something in this data that I missed.  :)
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Numsgil on January 25, 2014, 02:23:58 PM
The timings look weird to me.

Make sure you're starting the simulation up and then starting the capture.  There's a lot of time in the capture from what looks like the application starting up and you starting a new simulation.  You probably don't want to be capturing that.

I'll play with it more later tonight if I have time.
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Botsareus on January 25, 2014, 02:49:34 PM
Actually I started both runs after starting a sim and disabling video. However, I only captured for one hour and my cpu is not top notch.
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Numsgil on January 25, 2014, 05:38:14 PM
You usually don't need more than 10-20 seconds of capture.  You're just looking for trends.

Anyway, I was able to take a capture of it with good data.  Looks like Robots::UpdateRobots takes about 80% of the time.  Which makes sense since pretty much everything goes through that.

37% is taken up by Buckets_Module::CompareRobots3.  Half of that is in Common::VectorMagnitude.  The symbols don't point to the source code I have on disk (they point to your J:/... drive path), so I can't find where in that all the time is going.

I'm attaching the capture.  Play around with it inside Sleepy until you feel comfortable figuring out how I got those numbers.  Profiling is a skill worth having if you're starting a career as a programmer.

In terms of making it faster, you could probably cache a lot of the calculations going on in CompareRobots3.  It's basically calculating how far a robot can see from scratch for every robot-robot vision check.  It would also be worthwhile to double check that the bucket system is still working.  If that was broken it would be difficult to detect other than that the program would be slower.
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Botsareus on January 25, 2014, 07:00:18 PM
Quote
In terms of making it faster, you could probably cache a lot of the calculations going on in CompareRobots3.  It's basically calculating how far a robot can see from scratch for every robot-robot vision check.  It would also be worthwhile to double check that the bucket system is still working.  If that was broken it would be difficult to detect other than that the program would be slower.

I will windiff the source for CompareRobots3 and Bot bucket system, though I am pretty sure I have not even touched these.
I will also take a look at your capture.



Quote
The symbols don't point to the source code I have on disk

No wonder I could not figure out anything, I forgot that it uses the actual source code.
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Botsareus on January 25, 2014, 07:14:03 PM
Ok, the only difference is the eye strength mod for pondmode. But I think that is still faster then calculating shadow lines. If pondmode is off it is x1.
Anyway, thank you for your help. I think I am confident enough to move on.
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Botsareus on January 26, 2014, 11:04:10 AM
Just ran sleepy again with your method:

That eyestrength thing is indeed eating up a lot. Numsgil, here is the code for eyestrength, any idea how to make it faster? It is supposed to trow a Boolean and revert to 1.

Code: [Select]
0.25s Private Function eyestrength(n1 As Integer) As Single 'Botsareus 2/3/2013 eye strength mod
Const EyeEffectiveness As Byte = 3  'Botsareus 3/26/2013 For eye strength formula

If SimOpts.Pondmode And rob(n1).pos.y > 1 Then 'Botsareus 3/26/2013 Bug fix if robot Y pos is almost zero
  eyestrength = (EyeEffectiveness / (rob(n1).pos.y / 2000) ^ SimOpts.Gradient) ^ (6828 / SimOpts.FieldHeight)  'Botsareus 3/26/2013 Robots only effected by density, not light intensity
Else
0.02s   eyestrength = 1
End If


0.02s If Not SimOpts.Daytime Then eyestrength = eyestrength * 0.8

0.03s If eyestrength > 1 Then eyestrength = 1

End Function

This is called from all over the place in the buckets module such as:

Code: [Select]
'Returns the distance an eye of absolute width w can see.
'Eye sight distance S varies as a function of eye width according to:  S =  1 - ln(w)/4
'where w is the absolute eyewidth as a multiple of the standard Pi/18 eyewidths
Public Function EyeSightDistance(w As Integer, n1 As Integer) As Single 'Botsareus 2/3/2013 modified to except robot id
  If w = 35 Then
    EyeSightDistance = 1440 * eyestrength(n1)
  Else
    EyeSightDistance = 1440 * (1 - (Log(w / 35) / 4)) * eyestrength(n1)
  End If
End Function

Good find btw.
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Numsgil on January 26, 2014, 01:39:17 PM
It looks like most of the expense is the overhead of calling a function.  What does the callstack look like?

Basically, you should probably only ever need to call this once per bot per cycle.  If it's getting called more than that, that would be the issue.  You want to cache the values you get for each bot instead of recalculating them.

This is one of those cases where there's not much you can do to speed up the function itself, so you have to figure out ways to call it less frequently.
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Botsareus on January 26, 2014, 06:30:06 PM
Ok, I'll play with it, see what I can come up with. It does not look too promising though. If I get a reasonable speed improvement expect a revision drop soon.
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Botsareus on January 28, 2014, 10:44:58 AM
Nah, did not help a bit, My speed is exactly the same if I declare eyestrength in robot structure (and stuff) or I do not.
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Numsgil on January 28, 2014, 11:27:24 AM
That must not have been the bottleneck then :/
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Botsareus on January 28, 2014, 11:42:24 AM
It is not that bad Numsgil, I think we can live with 20% slower code... I am thinking it is the combination of all the new mods together, and there is no specific bottleneck... Thanks for your help, at least I learned proper bottleneck finding skills using a profiler from this experiment.
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Peter on January 28, 2014, 05:32:23 PM
No specific bottleneck is weird. Uniform slow code (http://c2.com/cgi/wiki?UniformlySlowCode) is rare.
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Botsareus on January 29, 2014, 02:04:59 PM
I can not find anything. Trust me, I looked. All the functions I looked at are taking as much % as I expect them to take. Also, I can not find any that I can optimize to be faster.
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Botsareus on February 11, 2014, 11:43:58 AM
Numsgil, I found something very interesting. Apparently "readtie" was excepting the counter from UpdateBots byref and then changing it. Causing the loop to repeat or even hang with half the loop never being executed. Very ugly. Fixed. I hope this one improves speed.
Title: Re: No fix for ghost collisions with planet eaters necissary
Post by: Botsareus on February 14, 2014, 03:31:55 PM
Wow, I put byvals everywhere it was safe to do and the program is flying now.