Announcement

Collapse
No announcement yet.

Ouya Game Console Performance Is Disappointing

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    I guess it would be interesting to see the fps min/max range to check variability. That's where GC stalls will hit you. But anyone claiming that java is up to the task of real time hard requirements is deluding themselves. When you want to push the envelope that's where this stuff will bite you.

    About lua: that's a different animal. Lua is typically embedded inside c/c++ applications and not the other way around, and it's also tailored more towards game logic only, not managing memory. Very different animals entirely.

    One advantage the ouya has is that they have their own android distro. They can make sure there's nothing like gmail or other misbehaving applications waiting around to trash out the GC, and I would hope OUYA doesn't put useless uninstallable crapware like you see on many vendor built firmwares.

    Perhaps next gen ouya would ship with a c/c++ pure control and performance oriented system with an android compatibility layer on top to get the best of both worlds (well we can hope, right?).
    Last edited by bnolsen; 18 April 2013, 03:03 PM.

    Comment


    • #42
      Originally posted by bnolsen View Post
      anyone claiming that java is up to the task of real time hard requirements is deluding themselves.
      Why does desktop Java -- which of course uses a completely different runtime than Android -- benchmark so well on something like this:


      look at Java 7 compared to Lua:


      Why does the Java port of Quake 2 (Jake 2) benchmark at the same level as the official C version of the game on the same hardware?

      Why do super high volume sites like Twitter run primarily on a Java centric back end. They usually have extremely fast response times with extremely large volumes of data. Their code is actually Scala from what they say, but that runs on a Java VM.

      If you mean real time in the sense that you can have more formal proofs of low response times there is even http://www.rtsj.org/

      Also, Android does support C/C++ development. They also have Renderscript which is a C-family language.

      Also, if you want PS3 level graphics or better you need to upgrade from a Tegra 3 chipset. There is no way a programming language is going to get around that.

      Comment


      • #43
        Was anyone really expecting anything special from this?
        It's just a phone without the phone part. It doesn't even get the bonus points of consoles where they have a small OS designed specifically for graphics calls.

        Also, any GC language is in the end, pretty bad for game programming. I've dealt with it before and I always end up going back to C++, having random garbage collections absolutely ruins your performance. I can't speak for Dalvik/Android, however.
        Last edited by peppercats; 18 April 2013, 05:35 PM.

        Comment


        • #44
          Originally posted by DanLamb View Post
          Why does desktop Java -- which of course uses a completely different runtime than Android -- benchmark so well on something like this:


          look at Java 7 compared to Lua:


          Why does the Java port of Quake 2 (Jake 2) benchmark at the same level as the official C version of the game on the same hardware?

          Why do super high volume sites like Twitter run primarily on a Java centric back end. They usually have extremely fast response times with extremely large volumes of data. Their code is actually Scala from what they say, but that runs on a Java VM.

          If you mean real time in the sense that you can have more formal proofs of low response times there is even http://www.rtsj.org/

          Also, Android does support C/C++ development. They also have Renderscript which is a C-family language.

          Also, if you want PS3 level graphics or better you need to upgrade from a Tegra 3 chipset. There is no way a programming language is going to get around that.
          Hehe, you just painted a big target onto yourself. It makes zero sense to benchmark java and lua against each other, how they are used is dramatically different. That's just plain foolish.

          If you were right then java should not have been rejected outright on the linux desktop. It most certainly has and for VERY GOOD reason.

          I've also worked enough with java to know that a few hand picked benchmarks does NOT necessarily indicate reality. And there's the elephant in the room: Java applications hog memory like there's no tomorrow. And I'll toss in multithreaded scaling for extra measure (my current specialty).

          Comment


          • #45
            Originally posted by bnolsen View Post
            If you were right then java should not have been rejected outright on the linux desktop. It most certainly has and for VERY GOOD reason.
            License reasons.

            Comment


            • #46
              Originally posted by DanLamb View Post
              Why does desktop Java -- which of course uses a completely different runtime than Android -- benchmark so well on something like this:


              look at Java 7 compared to Lua:


              Why does the Java port of Quake 2 (Jake 2) benchmark at the same level as the official C version of the game on the same hardware?

              Why do super high volume sites like Twitter run primarily on a Java centric back end. They usually have extremely fast response times with extremely large volumes of data. Their code is actually Scala from what they say, but that runs on a Java VM.

              If you mean real time in the sense that you can have more formal proofs of low response times there is even http://www.rtsj.org/

              Also, Android does support C/C++ development. They also have Renderscript which is a C-family language.

              Also, if you want PS3 level graphics or better you need to upgrade from a Tegra 3 chipset. There is no way a programming language is going to get around that.
              JVM and Dalvik are completely different beasts.

              Also, in some of those Lua benchmarks I think Lua used almost up to 1/100th(!) the memory of Java.

              Comment


              • #47
                Originally posted by bnolsen View Post
                If you were right then java should not have been rejected outright on the linux desktop. It most certainly has and for VERY GOOD reason.
                It was rejected? Any link or details? I use Java every day on my Linux system. Many Java devs prefer Linux.

                Originally posted by bnolsen View Post
                I've also worked enough with java to know that a few hand picked benchmarks does NOT necessarily indicate reality.
                I don't see any reason to suspect that web site of "hand picking" benchmarks or having some Java bias/agenda.

                Originally posted by bnolsen View Post
                And there's the elephant in the room: Java applications hog memory like there's no tomorrow.
                I believe there is a big difference between the desktop HotSpot JVM and Android's Dalvik runtime on this. The HotSpot JVM is designed for servers where there is often lots of RAM.

                I suspect that there may be large differences in fixed overhead, but if you load the same volume of data into a common data structure in Java vs another language, I don't see any reason why the Java language or runtime would impose a significantly higher memory cost.

                Originally posted by bnolsen View Post
                And I'll toss in multithreaded scaling for extra measure (my current specialty).
                Care to elaborate? Java does very well with multithreaded code and asynchronous code. Scala is much more elegant for async work but has similar performance characteristics AFAIK.

                Originally posted by peppercats View Post
                JVM and Dalvik are completely different beasts.
                Yes, of course. The runtime VM is probably more directly related to performance than the programming language is. However, two people were citing "Java", not Dalvik, as being the primary problem with Ouya performance, so I felt it appropriate to cite more readily available desktop Java performance info.

                Comment


                • #48
                  programming languages speed

                  Please, stop comparing nonsensical stuff.

                  - The speed of C/C++ programs is incredibly tied to the quality of the compiler (the thing that transforms words into machine instructions). For a big program, you can have 10x (probably even 100x) performance increase between a 15 year old compiler and a modern one (just look at the llvm and gcc phoronix comparison tests to see how it improves between versions).
                  - The speed of Java programs is incredibly tied to the quality of the virtual machine (the thing that transforms words into machine instructions). For a big program, you can have 10x (probably even 100x) performance increase between a 15 year old VM and a modern one.

                  Modern Java VM have very efficient (on some platforms) for some years. Dalvik java has not been so for most of android's life. It is getting better.
                  Performances of languages (aside assembly) are not set in stone, and not even always relevant.

                  Comment


                  • #49
                    @DanLamb

                    You posted throughput benchmarks, when the topic was latency.

                    To use a game analogy, it does not matter if the average fps is 200 when it dips to 10 once per second.

                    Comment


                    • #50
                      Originally posted by curaga View Post
                      You posted throughput benchmarks, when the topic was latency.
                      The official thread topic is actually disappointing Ouya sales, but it's branched out in many directions. I know the difference between throughput and latency, and wrote a ton of stuff on latency. I believe several people were arguing that Java was terrible in general and not just for variable latency reasons.

                      @erendorn, I generally agree with what you said.

                      I'd also note that many or even most of Android + Ouya games have their core game loop stuff in C/C++/Renderscript

                      Comment

                      Working...
                      X