BerryBots demo

Jump to navigation Jump to search
Revision as of 5 October 2012 at 14:39.
The highlighted comment was created in this revision.

BerryBots demo

Figured I'd take this to a separate thread. =) Posted another couple of vids with progress on the Raspberry Pi game I'm working on.

Still a lot to do but I think it's coming along pretty well.

    Voidious14:36, 21 September 2012

    Nice, looking neat :)

    Wonder how strategies will play out... hmm

      Rednaxela15:27, 21 September 2012
       

      Man, you are totally of the hook :). Looks indeed very neat. The race looks and sound as it could provide a lot of fun and maybe some nice pathfinding programming.

      Well done!

        Wompi17:02, 21 September 2012
         

        (Sorry, gotta take this back to LiquidThreads.. =))

        If anyone's curious, here's some TPS measurements (with graphics off) of Lua vs LuaJIT on the Raspberry Pi and my 2009 MacBook Pro 2.8 GHz. RandomBot is a trivial bot like sample.Crazy, BasicBattler is a slightly non-stupid bot with a simple Minimum Risk movement and random linear gun.

        • 2x BasicBattler
          • Rpi Lua: 343
          • Rpi LuaJIT: 632
          • MBP Lua: 5967
          • MBP LuaJIT: 19101
        • 8x BasicBattler
          • Rpi Lua: 44
          • Rpi LuaJIT: 88
          • MBP Lua: 766
          • MBP LuaJIT: 2377
        • 2x RandomBot
          • Rpi Lua: 782
          • Rpi LuaJIT: 1053
          • MBP Lua: 17781
          • MBP LuaJIT: 28154
        • 8x RandomBot
          • Rpi Lua: 119
          • Rpi LuaJIT: 182
          • MBP Lua: 2429
          • MBP LuaJIT: 4159
          Voidious04:17, 5 October 2012
           

          Obviously the LuaJIT is far superior in speed.

          LuaJIT vs Lua

          • 2xBB
            • RPI: x1.84
            • MBP: x3.2
          • 8xBB
            • RPI: x2
            • MBP: x3.1
          • 2xRB
            • RPI: x1.35
            • MBP: x1.58
          • 8xRB
            • RPI: x1.53
            • MBP: x1.71

          Even considering a margin of error, it seems the x86/amd64 version is either more mature or has a more leverage-able machine code (assuming your mac book is intel rather then PPC based).

          It seems to scale up on complexity. Be it more bots or more complex bots.

            Chase-san09:22, 5 October 2012
             

            I think there might be a fixed, constant overhead each time you call the Lua code, so the actual advantage within the Lua code is actually much higher. From the results with RB, it seems that LuaJIT also has a smaller overhead constant.

            About the difference between AMD64 vs ARMv6 instruction set, one is CISC other is RISC, so the CISC will benefit more from the pure assembly components that were part of LuaJIT because more suitable instructions can be used to do multiple steps in one instruction. At least, that's my guess.

              Skilgannon12:15, 5 October 2012
               

              Oh, definitely the advantage is much higher in the pure Lua code. The more time being spent in Lua code, the more you'll gain from LuaJIT. I wouldn't be surprised to see more like 10x-20x gains with really complex bots. Some of the benchmark comparisons on luajit.org go as high as 50x.

              I'm a little surprised 8x RB has a higher gain than 2x RB. The game engine is pretty fast, but some of it is <math>O({n^2})</math> (the line of sight and ship-ship collision detection), so for something like 8x a trivial bot, the engine is using a lot more CPU, which obviously gains nothing from LuaJIT. But I guess it's also sending more event data to the bots each tick, too (even if it's going unused here), which is sped up by LuaJIT.

              Good point on RISC vs CISC, I hadn't thought of that. It could also indeed just be more mature on x86.

                Voidious15:06, 5 October 2012
                 

                Interesting results.

                Regarding some of the O(n^2) time things, I wonder if it would be worth trying to improve those via methods that subdivide the area (either tree or grid), to avoid having to do a check for each bot, for each bot. Of course, the question is how many bots does it take for the cost of maintaining the data structure to be made up for. I suspect more than 8 unfortunately.

                  Rednaxela16:39, 5 October 2012