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 |
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page.
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. :-)
I'm actually implementing a rotated Rectangle2D.Double so that I can evaluate out-of-bounds PIF with a projected replay in Neuromancer. I was worried that it would be much slower than a standard .contains(x,y) function, so I was testing that. When I hit on the bitwise operations I thought I'd try a standard non-rotated function, and it was twice as fast as the awt.geom one. My rotated function is now slightly faster than the awt.geom as well.
I agree that sprinkling them around liberally isn't really going to make much of a difference, and will affect readability, but for something where you just have a bunch of numerical comparisons and the costs for all the branches will be more expensive than any saved time from the short-circuit provided in &&, this could be a decent speedup. The only real applications in RoboCode that would be intensive enough and have enough decisions to make this worthwhile, at least that I can think of, are in-field-bounds testing and range searches in Kd-Trees.
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.