FuturesScalper: thank you for all the good information. I've found the that JVM performance on 64 bit dual core systems can be improved quite a bit by tweaking the garbage collection algorithms (there are now several). Good link: http://www.onjava.com/pub/a/onjava/2006/11/01/scaling-enterprise-java-on-64-bit-multi-core.html
Guys, come on, just admit it - for real-time equities/options trading systems noting can beat C++. Use Java or Python is great for pilot systems, then code working system in C++. You beloved Java garbage collector will kill you with garbage collector cycles lasting seconds when load is high... You have to pay for every luxury Java gives you. Java is a good language, but just not for this domain.
Guys, come on, just admit it - for real-time equities/options trading systems nothing can beat C++. Use Java or Python is great for pilot systems, then code working system in C++. You beloved Java garbage collector will kill you with garbage collector cycles lasting seconds when load is high... You have to pay for every luxury Java gives you. Java is a good language, but just not for this domain.
Guys, come on, just admit it - for real-time equities/options trading systems nothing can beat C++. Use Java or Python is great for pilot systems, then code working system in C++. You beloved Java garbage collector will kill you with garbage collector cycles lasting seconds when load is high... You have to pay for every luxury Java gives you. Java is a good language, but just not for this domain. [/QUOTE] We all know about "religious language wars". I'm not gonna fall for this one... Java GC does NOT take SECONDS. Maybe in the hundred millisecond range infrequently s is more like it, depending how you configure the runtime. The term "realtime" is a relative thing anyway... Oops, I promised not to say anything in our defense. 'Nuff said.
We all know about "religious language wars". I'm not gonna fall for this one... Java GC does NOT take SECONDS. Maybe in the hundred millisecond range infrequently s is more like it, depending how you configure the runtime. The term "realtime" is a relative thing anyway... Oops, I promised not to say anything in our defense. 'Nuff said. [/QUOTE] Full GC cycle takes seconds even with the fine-tuned GC parameters in an application with a good load (of course, we are talking about soft real-time trading systems here).
Well, yes, this is "soft" realtime trading. Using an operating like Windows XP Pro is a "soft" realtime OS anyway, and "internet" network delays are nothing like hard pipes to exchanges, and so on... The meaning of "real time" is often simply "plenty fast enough". Using IB's TWS on standard DSL, for example, I bump a live Globex-based order in 120 msecs round-trip. And I analyze somewhere up to around 10,000 messages per minute from TWS market depth, etc. For some, that's child's play; for others' it's ridiculous overkill... it depends. This is only "soft" real time trading, of course, but it's all on a continuum of what's "fast enough" to do the job. Systems are only as fast as the slowest link in the chain anyway. You're right, of course.
The suggestion to use server VM instead of client VM makes a huge difference to potential performance. I'm not sure why we use the -client VM for anything where performance matters. http://docs.sun.com/app/docs/doc/819-3681/abeib?a=view
If your machine has only one or two processors then you should use these two together: -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode ref: http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#icms FWIW my current line for Sun Java is: Code: j2se version="1.6+" java-vm-args=" -Dsun.java2d.noddraw=false -server -Xss128k -Xms256m -Xmx256m -XX:NewRatio=3 -XX:+ForceTimeHighResolution -XX:CompileThreshold=50 -XX:ThreadStackSize=192 -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -XX:+RelaxAccessControlCheck -XX:MaxInlineSize=8192 -XX:-DontCompileHugeMethods -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+DisableExplicitGC -Xnoclassgc" For jrockit-R27.3.1-jre1.6.0_01 the corresponding optimization is: Code: -Dsun.java2d.noddraw=false -server -Xms256m -Xmx256m -Xns64m -XXaggressive:opt -Xgcprio: pausetime -XpauseTarget=250ms -XXcallprofiling
I am not sure why Java is so slow as C# is also managed and seems to be on average, just as fast as C++ in all the benchmarking I have done. I have run tests on the C# garbage tester and found it does not get in the way of real-time performance at all. Process scheduling latency under Windows is the biggest source of problems for C# soft real-time systems.