6 Replies Latest reply: Mar 18, 2008 6:59 AM by 807557 RSS

    JRT performance

    800408
      Hi All,

      we are testing now the JRT on solaris 10.

      our tests includes a few tests:

      1)we built some small program that made some calculation.

      we compile it in jre5 when we run this program we measure the time that take this calculation.

      we measure the time with System.nanotime() at the begginning of that calc procedure.

      and also when the calculation completed and make a delta between those times.

      we got ~13ms.

      we also compile it with Real Time jvm.

      and when we run it we got ~85 ms.

      maybe someone can give me some hint what going on???

      2)we also did it with threads

      and we always get a pure results with JRT.



      is someone deal with this kind of problem??



      TIA
        • 1. Re: JRT performance
          807557
          Gabi wrote:
          1)we built some small program that made some calculation.
          we compile it in jre5 when we run this program we measure the time that take this calculation.

          we got ~13ms.

          we also compile it with Real Time jvm.

          and when we run it we got ~85 ms.
          What version of JRE 5 did you use and on what kind of machine?

          The JRE will adapt itself to the kind of machine and choose either the client compiler or the server compiler. Java RTS only supports the client compiler. So to compare apples with apples you need to use -client when invoking Java.

          Secondly, even when using -client, the version is important. Java RTS is based on Java 5 update 4 and various improvements in the client compiler went into later Java 5 updates.

          Thirdly, in general when you are using a real-time VM you are sacrificing some throughput to get the determinism/latency guarantees. Exactly how much depends on the platform, the way the VM is tuned, and the application.

          Finally, depending on the application you may need to tune the real-time GC for optimum performance. But without knowing what your application code does it is hard to suggest anything specific.
          2)we also did it with threads and we always get a pure results with JRT.
          Sorry I don't understand what you mean by this.

          David Holmes
          • 2. Re: JRT performance
            800408
            Hi David ,
            Let Me Answer your question:
            Question:"What version of JRE 5 did you use and on what kind of machine?"
            answer:JRE5 update 12. macine solaris 10 x86.

            i will send our small application during the next days.

            Thanks for your answers.
            • 3. Re: JRT performance
              807557
              Okay 5u12 does have additional performance enhancements compared to 5u4.

              By machine I meant number of cpus etc. I just want to know whether you were running the server or client compiler. If you didn't specify -client or -server directly then "java -version" will show whether it defaulted to client or server on your machine.

              David Holmes
              • 4. Re: JRT performance
                800408
                David,
                thanks for your answers.
                we are testing it at my work.
                since today is Friday we are in vacation here.
                ill send you all those details in Sunday.

                Thanks again
                • 5. Re: JRT performance
                  807557
                  People confuse "real-time" with "real fast" because to them, real-time is equivalent to real fast. Scientifically speaking, real-time means 'the ability to reliably and predictably reason about and control the temporal behavior of program logic'. The computer will respond all of the time before some particular deadline that you've given it. It's predictable. Depending on how you set your deadlines, numerous systems could be called real-time. For instance, say, you program a computer to display a character on the screen when you type a character on the keyboard, and your deadline is six days from now. But, as you abbreviate that deadline more and more and get into the millisecond range, then things start to get interesting. (By Greg Bogella)
                  • 6. Re: JRT performance
                    807557
                    The main problem that was being observed in this case was the different compilation strategies in Java RTS. A NoHeapRealtimeThread never uses JIT but must always have its code pre-compiled using Initialization Time Compilation (JIT). A RealtimeThread will use JIT compilation and/or ITC, but in the current release it doesn't do On-Stack-Replacement (OSR)** - so tight loops in a method that's only called once won't get compiled - unless ITC is used. So in effect in a real-time thread what was being observed was the execution of interpreted code, not compiled code - which is about a 8x slowdown . Proper use of ITC will alleviate this:

                    http://java.sun.com/javase/technologies/realtime/reference/doc_2.1/release/JavaRTSCompilation.html

                    Of course there are still performance differences between the real-time VM and a J2SE VM

                    ** This isn't documented and we're seeing if this restriction can be lifted for the forthcoming 2.1 release.

                    David Holmes