C vs Java programming for IB

Quote from speculatus:

Java based TWS can easily spend 50-100ms processing your order before submitting it into IB OMS. FIX is the best (and the most complex though) approach.
More...

While FIX is undoubtedly a better approach, I'd like to see some evidence that TWS can take 100 msec to transmit an order. Quite frankly I think that is untrue.

I have have developed a real time charting and screening app in Java. Running on Linux on Intel C2D with 20 charts open and complex screens (such as recalculating market profile and VWAP on every tick for 100 or more stocks), CPU ulilization just about never goes over 25% and is more typically 5%. Coming from a C development background, I have been amazed at Java performance.
 
In applications that require high performance (high throughput, et cetera), the algorithm will always trump the language choice.

C will be slower than Java if you implement the solution inefficiently. Knowing the paradigms available in a certain language will help you write the most efficient solution.

Also, for you guys who love Java, check out Java SE Real-Time (http://java.sun.com/javase/technologies/realtime/) -- it will help you meet your stringent real time requirements.
 
Quote from Corey:

In applications that require high performance (high throughput, et cetera), the algorithm will always trump the language choice.
More...

Absolutely correct.
 
Quote from dcraig:

While FIX is undoubtedly a better approach, I'd like to see some evidence that TWS can take 100 msec to transmit an order. Quite frankly I think that is untrue.

I have have developed a real time charting and screening app in Java. Running on Linux on Intel C2D with 20 charts open and complex screens (such as recalculating market profile and VWAP on every tick for 100 or more stocks), CPU ulilization just about never goes over 25% and is more typically 5%. Coming from a C development background, I have been amazed at Java performance.
More...

My statement about TWS API timing was based on the real order execution. My ATS does extensive logging, and I had observed all order ACKs and fills coming from TWS.

BTW, don't forget that JVM can kick in garbage collector at the most inappropriate time. Believe me, when complexity of your Java based TS reaches a critical point, you'll damn that day when you decided to use Java.

Java is a great language, but when it comes to near real-time trading systems, C++ is the only way to go.
 
Quote from speculatus:

My statement about TWS API timing was based on the real order execution. My ATS does extensive logging, and I had observed all order ACKs and fills coming from TWS.

BTW, don't forget that JVM can kick in garbage collector at the most inappropriate time. Believe me, when complexity of your Java based TS reaches a critical point, you'll damn that day when you decided to use Java.

Java is a great language, but when it comes to near real-time trading systems, C++ is the only way to go.
More...

Well, there is no reason for transit delays of 100 msec though TWS. Java is naturally multithreaded and orders should routed very quickly. If there are delays and the thing is coded properly, it is application dependant - for example checking margin limits via server or something else. It is not because Java is too slow. This is so easily seen by looking at CPU utilization while TWS is running.

Garbage collection is a vastly overblown issue. One can look at garbage collection using the JConcole management utily that comes with the JDK. It is mostly not an issue, and there are a lot of JVM garbage collection tuning options that can reduce the effect markedly.

You have to be realistic in locating source of delays. Unless your ATS is located in a data centre with leased or some private networking service with guaranteed QOS, your number one source of delays and dropouts will be the public internet. In all probabily, your internet issues are likley to swamp any garbage collection issues.

I can process hundreds, and probably thousands of time series on every tick, creating new tick object for each tick. Garbage collection is not an issue.

In any case, obsession with the last millisecond for most people here is an utter waste of time. Good luck to those who have truely high frequency systems, but most here are not capable of doing it. You are up against some very well resourced opposition and devoting one's effort to other areas may in the end be effort well spent. Those who have done it have my respect.
 
Quote from speculatus:

My statement about TWS API timing was based on the real order execution. My ATS does extensive logging, and I had observed all order ACKs and fills coming from TWS.

BTW, don't forget that JVM can kick in garbage collector at the most inappropriate time. Believe me, when complexity of your Java based TS reaches a critical point, you'll damn that day when you decided to use Java.

Java is a great language, but when it comes to near real-time trading systems, C++ is the only way to go.
More...

Agree 100%, but for you die hard java programmers I came across this open source real-time java package that might interest some. I've never used it but it looks promising.

<url>http://javolution.org/</url>
 
An amusing tale about one of the pitfalls of "managed code" such as C# or Java

"We kept noticing that the computer would begin to bog down after extended periods of driving. This problem was pernicious because it only showed up after 40 minutes to an hour of driving around and collecting obstacles. The computer performance would just gradually slow down until the car just simply stopped responding, usually with the gas pedal down, and would just drive off into the bush"

http://www.codeproject.com/showcase/IfOnlyWedUsedANTSProfiler.asp

To be brutally honest, the problem is with some sloppy coding, but it a error that is very easy to make.
 
Quote from maxpi:
What about Powerbasic?
http://www.powerbasic.com/
It seems like it would be the way to go for a windows app because a project could get done quickly...
More...
I agree....and it generates very fast compiled code...and no runtime is required. Only issue is : will the company be in business in 5 years ? It is interesting to see that several of their large clients are the big NYC firms...Goldman included. Strange however that Microsoft is listed as a client !!
 
You must log in or register to reply here.
Back
Top