C vs Java programming for IB

[segv]

Quote from speculatus:

Are you kidding me? 100ms is eternity in today's market.

An eternity for whom? I will accept the argument that 100ms would be an awfully long time for an exchange to transmit a quote or acknowledge an order, but what do you think that this means to a customer of IB using TWS?

Trading floors are ghost towns, 80-90% of all flow is electronic, and you compete against co-located algos & OMS. Go and figure about who's gonna win.

I must have missed that trend in the last 15 years when I was building all of those data centers, but thank you for finally filling me in. Would you please explain to me how does a colocated "algo" in New York get the edge on an institutional trader at Barclays in San Francisco?

C++ is just better suited for high-frequency equities/options ATS or marked data feed handlers.

Where is the data to support your claim? Why is C++ "just better" for high-frequency trading? My argument is that language latency is insignificant for an automated or high-frequency trader developing a system for the IB TWS platform. Go ahead and write it in assembly if you want to, but it is still going to get routed through TWS.

BTW, no offense, but software engineers from India are worst engineers in todays' marketplace. Again, no offense, just the voice of extensive experience.

BTW, no offense, but you are totally ignorant.

 

[segv]

Quote from thesharpone:

why am I not impressed?

Because you are feebly attempting to refute the existence of two Java-based operating systems you did not know about.

 

[segv]

Quote from Corey:

But this isn't a language war, which you don't seem to understand. This is a programmer efficiency war. Programmers are always more efficient in comfortable territory. If the OP is more comfortable in C, I see no reason why he shouldn't use the C++ API, compile with a C++ compiler, and just write C style code.

IB TWS is written in Java and has a thoroughly tested Java API. As I told the other poster, you can write it in assembler and backport it to the VAX if you want to, but the data is going to get routed through TWS anyway. It does not seem to be worth the effort to do something else when you can have the application up and running in a couple of hours with the API.

 

[Gustaf]

Quote from segv:

IB TWS is written in Java and has a thoroughly tested Java API. As I told the other poster, you can write it in assembler and backport it to the VAX if you want to, but the data is going to get routed through TWS anyway. It does not seem to be worth the effort to do something else when you can have the application up and running in a couple of hours with the API.

I agree to most of the things you have written above but as a side note I can just add that getting started and having a little scalper that automatically placed orders was not complicated nor took a long time for me to do in C++.

Id say use the language which is most comfortable. As segv pointed out, TWS is still written in Java and we are not talking a fighter jet system control system here.

(I use both Java and C++ at work and have done so for the past 8 years).

Br

 

[Corey]

Quote from segv:

IB TWS is written in Java and has a thoroughly tested Java API. As I told the other poster, you can write it in assembler and backport it to the VAX if you want to, but the data is going to get routed through TWS anyway. It does not seem to be worth the effort to do something else when you can have the application up and running in a couple of hours with the API.

You just really are not understanding what I am saying. TWS has a C++ API. The original poster is more comfortable in C. Why, oh why, would he want to write it in Java then?

Now, if this application were tens, or hundreds, of thousands of lines long, then programmer efficiency and capability is of the utmost importance. I would still argue that writing a socket implementation in the language you are most comfortable in would be worth it. But, considering most languages can interface with shared libraries, you could probably just take the TWS C++ API, write an interface, and compile it into a shared library -- then write the whole thing in whatever language you want.

You seem to think I am having some argument about the efficiency of Java. I am not. At all. I am having an argument about the efficiency of the programmer.

I don't really care that the actual application you will be interfacing with ultimately uses Java. That is a fixed cost. The rest of the process is all variable costs. A programmer should do everything they can to decrease their variable costs.

 

[trada101]

Quote from thesharpone:

I guess so. I tried the sample Java code provided by IB, it seemed ok, at least better than what I was expecting it to be. And I was able to easily run it with Web Start. But still haven't studied it in detail. I would still like to hear more opinions regarding choice of language.

I was thinking why IB doesn't have direct connect instead of passing orders by submitting them to TWS then to IB?, but then I remembered this http://www.interactivebrokers.com/en/p.php?f=connAltern&p=i&ib_entity=llc , IB CTCI, it sounds pretty cool, it states that one can even submit hidden orders.



C is close to perfect, it's also very close to assembly (& so machine code).

[rant]
If TWS was written in C by good programmers it would initialize and run much faster than it's current speed, but I can see why they did it in Java; they wouldn't have to debug and recompile it for each OS, laziness.

Name an OS written in Java, Java runs on a virtual machine that runs on an OS, same with all of microsoft's fucking programming languages, at least you can respect Sun for sticking to one language. Let's see; Basic, C#, J#, C Omega, F#, X#, Sing#, Spec#, wow, what a fucking zoo of languages, is this africa or something?, Bill: "oh let's see where the next 40 billion $ is, try anything and everything that comes into your fucking indian minds", the bitch and his under-bitch won the lottery (with the support of the gov) once, how many times are they supposed to win it in a life time to fucking get their gay ass out of where it doesn't belong?! People have to fucking die in order to realize that they are not some immortal moran, God and good thing they do, but too bad it's late when they do rot to death, and take their shitty dreams with them to their fucking toilet graves.
[/rant]

Anyhow one can argue that C is more for system and core development versus Java and Basic for building application.



thanks for pointing it out, many on their path to a computer science PHD or masters program, thought of hiring an indian to develop a new programming language for them, and name it after their oak tree, you know being street smart and getting some gay attention from other higher university bitches.

Am I glad you don't run a company and thank god for Microsoft. WTF, so you want everyone in the world to program in one language? Kudos to Microsoft for the ability for people to choose how they want to express their code (VB, C#, C++, etc.).

But I agree, TWS should be written in C/C++.

For all you Java lovers out there, you do realize where Java came from, it's not an original idea that Sun invented, nope. It's basically SMALLTALK, think of it as version 2.0.

 

[GTG]

For all you Java lovers out there, you do realize where Java came from, it's not an original idea that Sun invented, nope. It's basically SMALLTALK, think of it as version 2.0.

And C# is basically 3.0

 

[tradestrong]

Quote from Corey:

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.

Well...just to be a stickler..
...The Java programming language is actually written in C and includes another layer of compilation that happens converting the intermediate byte code to assembly language at runtime.

The JVM is also another subsystem which sits between the process and the OS, so technically, it would be impossible for Java to be faster than C++...

....but having said that, the real latency in a network process is the TCP/IP communications that happen over networks. Those latencies are hundreds of times longer than the differences in a process running C++ vs. Java.

Secondly, it's false that C++ will be faster at this layer, because Java obviously uses the OS network stack just the same as C++ does, so once the process has made the network request, they are both at the mercy of the OS drivers just the same.

Java and C++ are two different animals altogether. Java is best to write code that is easy to reuse and extend. It's a great language for ease of design.

It's true that C++ is the better "real-time" language, but that more applies to running processes that have critical time constraints within the same process space.

C++ is good if you need performance in the milliseconds, but since trading by its very nature is highly network sensitive, the gains that you'll make within the same process space are so tiny as compared to the network latencies, that IMO, I wouldn't factor that into making a decision.

Now, if you're running a "hub" of ECN's, well that's a different story. In this case, most of your processing is probably happening on the server to handle so many requests in parallel. So in that environment, you'd be nuts to use Java. But for your average trader who is making basically only a few requests at a time, I don't see how you'd even be able to measure the difference with any validity.

My 2cents.

 

[Corey]

Quote from tradestrong:

Well...just to be a stickler..
...The Java programming language is actually written in C and includes another layer of compilation that happens converting the intermediate byte code to assembly language at runtime.

The JVM is also another subsystem which sits between the process and the OS, so technically, it would be impossible for Java to be faster than C++...

I think you misunderstood what I meant. Most of the time it isn't the language that is slower -- it is the programmer.

If you test silly things like 10000000 iteration for loops, then C will win in speed, hands down. But those are contrived examples.

What people fail to realize, and what you say well, is that no general purpose language exists. If it did, we wouldn't have all the languages we do. Each language is a tool in the toolbox -- the more you know, the more likely you are to choose the right tool (and therefore have the most efficient solution) for the job.

But you are wrong in saying that Java cannot be faster than C, or C++. Very wrong. Java can be much faster -- even if the programs are a solution to the same problem. "How can this happen?" you ask. As I said: the algorithm. Whoever wrote the C code wrote it inefficiently. Where the C programmer might have written map[x][y], the Java programmer wrote map[y*MAX_Y + x]. Its all about the most efficient solution -- and most programmers aren't good enough to even take 'language speed' into account.

I know I am not.

 

[dcraig]

Quote from tradestrong:

The JVM is also another subsystem which sits between the process and the OS, so technically, it would be impossible for Java to be faster than C++...

Well, technically that is not quite 100% correct. While I doubt that anybody will dispute that C++ is in gereral faster than Java or C#, there could well be instances of certain operations where C++ is slower. C++ code is statically optimized at compile time. The JVM via Hotspot can do dynamic optimizations on how the code is executed. There is some discussion of this stuff in the articles and blogs on java.net.

Another example where Java is claimed to be quicker is in object creation and destruction, the automatic inlining of getters and setters etc.

I'm not trying to start an argument on which is best or better or fastest, but to underline the fact that system performance is a very complex issue, and really does take some expert knowlegde to come up with useful analysis (as opposed to just running it and see how long it takes).

And yes, I completely agree that the data comms side of things is the dominant factor in latency.