Darwinbots Forum
Code center => Darwinbots Program Source Code => Topic started 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.
-
You got a (new) amd laptop?
-
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.
-
: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?
-
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.
-
Ok man, I will try it.
-
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.
-
Where is most of the time going then?
-
There was a large change with video on...
-
Here Numsgil, maybe you can dig up something in this data that I missed. :)
-
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.
-
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.
-
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.
-
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.
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.
-
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.
-
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.
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:
'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.
-
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.
-
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.
-
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.
-
That must not have been the bottleneck then :/
-
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.
-
No specific bottleneck is weird. Uniform slow code (http://c2.com/cgi/wiki?UniformlySlowCode) is rare.
-
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.
-
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.
-
Wow, I put byvals everywhere it was safe to do and the program is flying now.