Client java version

Jump to navigation Jump to search
Revision as of 4 September 2017 at 18:16.
The highlighted comment was created in this revision.

Client java version

Can we have a quick survey about java version with which you run your litumble clients?

I see that performance of my bots dropped since I switched to java-8-openjdk for bot compilations. Plus I see ridiculosly low scores for my bot against some very simple bots at the literumble. On my machine I beat them with much bigger margin. So I suspect that there is something strange with one of the clients.

For the record, I compile everything with java-8-openjdk and run my literumble clients with java provided within this jdk.

    Beaming (talk)03:03, 4 September 2017

    I'm using Java 8 for my rumbles. However, it seems that some bot stopped working on Java 8? etc. MoxieBot.

    I'm also using Java 8 and its features for bot development. However, I compile my bot with Java 8, then transpile the bytecode to Java 6 compatible using retrolambda, as Java 8 compiled code will generally refuse to run on lower platform.

      Xor (talk)04:45, 4 September 2017

      Cross porting from Java 8 seems to be excessive, if the rest of us are running Java 8. But let's see what others are running.

        Beaming (talk)05:20, 4 September 2017

        But why risk getting low scores when there are someone using Java6? I think anyone who participant in rumble should make the bot compatible with Java 6 until it is not officially supported by the literumble.

        Maybe what we really need is a vote for moving the minimum requirement of running rumble from Java 6 to Java 8?

          Xor (talk)10:18, 4 September 2017

          > what we really need is a vote

          The problem with the Robocode community is that everyone talks making changes, but no one actually does anything.

            MultiplyByZer0 (talk)10:58, 4 September 2017

            Please don't be so harsh.

            Our problem that we don't have large enough community. We can count active users in two hands. You cannot expect everyone to jump on the issues right away.

            At least we can make reasonably complete bug reports and see if they can be addressed.

              Beaming (talk)15:25, 4 September 2017
               
               
               

              By the way, ncj.MoxieBot 1.0 is running OK on my machine. It sometimes freezes but it seems to be the fault of the internal logic.

                Beaming (talk)05:24, 4 September 2017

                But all my bots are getting 100% against MoxieBot on my computer, whereas there seems to be some 50% on the rumble, which makes me think that it doesn't work as expected on Java 8.

                  Xor (talk)05:57, 4 September 2017
                   
                   

                  openjdk8 here, on Linux.

                    Skilgannon (talk)07:26, 4 September 2017
                     

                    java version "1.8.0_102" Java(TM) SE Runtime Environment (build 1.8.0_102-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)

                      Cb (talk)09:14, 4 September 2017
                       

                      JDK 9 on Mac. Having the same problems with you.

                        Dsekercioglu (talk)09:33, 4 September 2017
                         
                        java version "1.8.0_144"
                        Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
                        Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
                        

                        on Windows 10.

                          MultiplyByZer0 (talk)10:36, 4 September 2017
                           

                          Java 1.7, as I just use an older unused computer for it. Some bots don't run in the rumble, but those battles are not even fought, so no pollution of the stats. I plan to update to Java 1.8 later this week.

                            GrubbmGait (talk)11:11, 4 September 2017
                             

                            openjdk8

                              Rsalesc (talk)11:47, 4 September 2017
                               

                              Ok. Among recent literumble clients uploads we mostly have java8. The only exceptions are Dsekercioglu and GrubbmGait, we also have uncertainty on Anonymous uploads. GrubbmGait did not make uploads more recent than 4 days old, while I have score glitches on more recent releases. It could be abnormality in Java9.

                              One more thing. If I run GUI client at full speed with debug graphics toggle off, from time to time I see a error message in console from robocode 1.9.2.5 about java Threads dying. In such battles my score drops a lot, strange thing that it is not directly related to skipped turns counts. It could be a bug in robocode itself.

                              Does anyone see such phenomenon?

                                Beaming (talk)15:20, 4 September 2017

                                @ Dsekercioglu, would you mind switching off you liteclient for a while? Let's see if we can pinpoint the issue to java9 glitches.

                                @ all, if you are not running java8, please do not run liteclient for a week, starting from 2017/09/04.

                                  Beaming (talk)15:27, 4 September 2017

                                  Okay I'm closing it.

                                    Dsekercioglu (talk)15:28, 4 September 2017

                                    Or you can just use two versions in parallel ;) For me I develop my bot and run the rumble on Java 8, but I always test it on Java 6 before every release to make sure it works.

                                    Just install them in different directories, and call java executable with the correct directories when starting robocode/roborumble.

                                      Xor (talk)15:42, 4 September 2017
                                       
                                       

                                      Yeah, I have exactly the same issue, but since I never saw anyone complain about this, I just ignored it. I can reproduce the issue with 1.9.2.6 as well.

                                      I spent a lot of time reading Robocode's source trying to find a connection between that and skipped turns with no real success. Perhaps Skilgannon, which seems to be strongly related to how Robocode evaluate skipped turns as it is today, could share his thoughts about this.

                                      When testing it with Roborio, there were a few times I fixed the running speed at 1000 TPS and could see skipped turn messages instead of these Thread errors, but this only happened when using my old GoTo code, which was really slow. I can't see skipped turn messages with Roborio 1.2.4, for example.

                                      Then I tried to run Neuromancer with the same setup and could see a lot of these Thread dying errors as well, despite seeing no skipped turn messages when locking at 1000 TPS.

                                      What is weird is not that the crashes are occurring at all. Maybe they really make sense. But the thrown exception instead of a helpful message is somewhat weird.

                                        Rsalesc (talk)15:34, 4 September 2017

                                        I sometimes see the ThreadDeath things as well, it seems completely sporadic. I can't reproduce it at all with the current dev version.

                                        A possible issue is the platform it is run on. Windows has a system timer with a very coarse tick (30ms IIRC). We had to use the nanosecond timer in chunks of 0.999999ms to emulate the larger timer. Maybe this nanosecond timer is broken in later releases of Oracle JDK.

                                        So I'm curious: the people who are seeing Moxiebot broken, are you running Windows? Are you using Oracle JDK or OpenJDK?

                                          Skilgannon (talk)19:01, 4 September 2017
                                           
                                           

                                          Perhaps we should all give more details about how we run the rumble client.

                                          I run RoboRumble intermittently, not continuously (only when I see interesting new bots added to the participants list). So far, I've only run roborumble (not meleerumble or others), but that may change soon. It's running on my everyday-use computer, and not a dedicated machine. Sometimes I run Robocode battles or browse to CPU-intensive webpages, and that may cut into the amount of CPU the client gets. My CPU constant is 6500859 ns (6.5 ms) per turn. I have a 4-core machine, and RoboRumble tends to take up 30-60% CPU constantly. It takes about 15 minutes to execute 50 battles.

                                          Seriously though, if your robot is incompatible with certain setups, the fault lies in your robot. Perhaps you should respond to SkippedTurnEvents by reducing the amount of computation your robot performs.

                                            MultiplyByZer0 (talk)16:33, 4 September 2017

                                            Running the rumble client on an ultrabook when I'm not using it and it is plugged into power. Often it uses 2 cores even with a single client. CPU constant is about 5.3ms in openjdk8 using Linux.

                                            About the skipped turn thing, I agree. A big part of Robocode is how long you have to do your processing in. It is a massive tradeoff and I know some of my bots occasionally step over the edge. However, I also don't want to change the rules of the competition. If there is something in Oracle JDK8 that is killing certain bots we need to figure out what that is.

                                              Skilgannon (talk)18:43, 4 September 2017

                                              I am not arguing that heavy on skipping bots should not be punished, my complain that it is erratic and seemingly coming from Java itself. Looks like it shows when a heavy bot is matched against a low CPU demanding one.

                                              By the way, sometimes it to my advantage. I see strange unexplainable APS gain in melee against 'sgp.JollyNinja 3.53' [1]

                                              Note that my v7.4 is very mediocre when compared against v6.1, except one case JollyNinja.

                                                Beaming (talk)19:09, 4 September 2017
                                                 

                                                Here is my setup,

                                                I run literumble clients on two machines almost non stop. Each runs one rumble and one melee client at the same time. Since one has 4 cores and the other 6, this should not be a problem with CPU calculations under normal circumstances. Also, there is plenty of RAM so no swapping. If I expect high CPU demanding tasks, I stop clients so they not affected by CPU fight with other programs.

                                                But I think at some point robocode became multi-threaded, so CPU constant (6.5 ms in my case) is not so relevant anymore. In top, I can see that rumble client often eats more than 100%, i.e. it spans between cores. Also, load on a machine seems to be high, i.e. it is often in the range of 3 for the 6 cores machine.

                                                Plus there is CPU throttling which kicks in when ever it wants, thanks to modern hardware design.

                                                  Beaming (talk)19:16, 4 September 2017