View source for Talk:SlowBot
- [View source↑]
- [History↑]
Contents
Thread title | Replies | Last modified |
---|---|---|
Decision Speed Optimisation | 3 | 18:06, 5 May 2013 |
Speed and energy consumption | 2 | 15:07, 13 March 2013 |
Vandalism? | 2 | 20:45, 23 November 2012 |
I was playing around with a speed comparison with manual point-in-field checks to the Rectangle2D.Double.contains(x,y) method, and discovered that if I used && between the booleans I got pretty much exactly the same speed, but if I use & I get double the speed and exactly the same result. I'm guessing this is due to my CPU being able to evaluate multiple boolean expressions simultaneously, but if && is used only one is allowed to be executed at a time, or perhaps & just allows the pipelines to stay more full because there is less branching.
Of course, there are some reasons you might want && instead, like null checking before examining an object property, and && is smaller codesize for those bots that are codesize restricted, but particularly for high-load situations like the inside of precise prediction or play-it-forward loops, using & for your decisions might gain you some speed =)
That's interesting and is something I didn't know. I don't think there would normally be parallel evaluation going on, so I do think it's the lack of branching and that bit-wise operations are just very simple/fast. I found a couple StackOverflow questions about it too, where people mostly mention branching. [1] [2]
I'm probably in the "not worth the cost to readability" camp, but I know you're a little closer to the "anything for speed" end of the spectrum. :-)
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page.
Return to Thread:Talk:SlowBot/Decision Speed Optimisation/reply (3).
Slow bots doing the same thing as fast bots should consume more energy (hardware power, not robot life) per battle IMHO because of longer CPU usage.
Usually, CPU is in one of two states, active or sleeping. Only sleeping state consumes less energy, and all bots, fast and slow, stay in active state all the time.
I don't really care if a robot uses a lot of time. The time allowed is already limited by the Robocode engine, and if Robocode provides the time, I don't see anything wrong with using as much of that time as you want. Of course, it is nicer when a robot runs quickly. Regardless, it is tempting to work on a way to measure the CPU usage of all the robots in the Rumble, as it would be very interesting to see.
I don´t care if a bot is slow either. The way the article was updated, saying the slower the better, is what bothered me.
The last edit (before Voidious) looked like vandalism to me.