This content has been marked as final. Show 6 replies
Gabi wrote:What version of JRE 5 did you use and on what kind of machine?
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.
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.
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.
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)
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:
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.