I think there is a Java GC that runs as a background thread and there is work in progress on real time Java. In any case, for logging tick data, you can still quite successfully use pure Java. If your receive buffers are big enough (a socket option) , there should be enough elasticity to get though a GC pause (maybe 100 - 200 mSecs) without flow controlling the TCP stream. Even if the TCP stream is flow controlled, you are not going to lose data. The only issue is whether a 100 or 200 mSec delay every now and then matters, and in most cases it doesn't - especially since the rest of the pipeline to the exchange is not "real time" in the true sense of the word. If an occasional pause is not tolerable use C. Having just written that, I just ran JConsole on my Java charting app running on Linux (Java 1.5.0_11 and Ubuntu 6.10). It shows an average time for a "Copy" GC of just 14 mSecs. A "Copy" GC is the normal GC algorithm run in desktop JVM. The other GC algorithm "MarkSweepCompact" is much more expensive and averages at about 250 mSecs. It is my understanding and observation though, that the latter is only run if the heap size approaches -Xmx limit or if System.gc() is explicitly called. I reckon that 14 mSecs is not an issue for most applications. Edit: These times are on a Sempron, with 2Gbyte memory and a heap size of around 220 Mbyte.
I would have thought that GC and other internal VM mechanisms actually make not just code but the whole system run quicker over all so any execution losses for individual processes is made up for by long term systemic gains (I mean my machine stays on from 07GMT until around 23GMT).
I concur with most that has already been said on the thread. Java is fast enough for my purposes so far. In addition, if you are exclusively going to be using IB, then Java makes a lot of sense. However, there are some interesting books coming up that are C++ based: http://www.amazon.com/Financial-Tra...1904637?ie=UTF8&s=books&qid=1174484037&sr=8-1 http://www.amazon.com/Building-Auto...2660938?ie=UTF8&s=books&qid=1174484120&sr=1-1 The latter is based on C++.Net and a large part of the book is devoted to learning the language and .NET rather than ATS development itself. Suggest you review the Contents and Sample Chapter on the Elsevier website. In fact, I see it has already got a disastrous review on Amazon after just coming out. Then there are a whole host of other decent Financial texts that are also C++ based: http://www.amazon.com/Modeling-Deri...7601605?ie=UTF8&s=books&qid=1174484426&sr=1-4 http://www.amazon.com/Patterns-Deri...3921555?ie=UTF8&s=books&qid=1174484460&sr=1-1 etc. The first book mainly covers stuff found in quantlib.org. If you're a Java developer, it's tricky to take advantage of the C++-based quantlib.org - I haven't managed to get it working yet after several attempts! And I don't want to pay for CapeTools QuantTools etc. If anyone has Quantlib working from Java, let me know! Gaining financial engineering experience in C++ will stand you in good stead if you later decide to leverage that experience in order to go and work for a hedge fund or something. If this is not something that is remotely on your radar, then perhaps better to save yourself the hassle and stick to Java. As for C# etc. well there are some possible advantages that would make an ATS simpler to build. However, if C# is your weapon of choice, you might as well take advantage of the infrastructure provided by products such as: www.rightedge.com www.smartquant.com Interestingly, there is one book that for some inexplicable reason decided to focus on VB.NET: http://www.amazon.com/Modeling-Fina...9632053?ie=UTF8&s=books&qid=1174485128&sr=8-1 If someone has never done any programming before save for a few bits of VBA in Excel etc. then this is actually a pretty good book for a complete novice programmer. Naturally, the code can easily be translated from VB.NET to C#.NET. If you decide to pursue the Java route, please feel free to get some ideas and/or contribute to my semi-hibernated thread here: http://www.elitetrader.com/vb/showthread.php?s=&threadid=81666 It has some links to useful Java libraries and tools as well as some architectural documentation. Lastly, there are a few Python aficionados floating around the forums that swear by it for ATS development. There are also some ready-made applications for use with IB e.g. http://code.google.com/p/profitpy/ I'm also aware of some ATS development being undertaken in Erlang and OCaml: http://wagerlabs.com/2007/2/21/algokit Authored by an ET member sometimes posting here. Food for thought.
This is kind of crazy, but what about VB6 as a rapid dev environment ? The final version of the run-time lib is fast and DLL's and ActiveX components can be built with it. Also, many programmers have cringed at VB.NET and that horribly verbose code. Big caveat: no more support from MSFT for VB6.
good post tradermojo. i started learning c++ about 2 years ago. took me 6 mos to understand most of the syntax, and another 6 to really get the flow of programming in it. as of now, I'm pretty comfortable in it and can code very quickly. any other language i look at now is pretty easy to pick up. that's not why i recommend c++ or c#, though. learning java and building apps in it may be easier and may require less time and expertise to get going, but that time and expertise required will greatly increase as you try and write to the numerous api's in the financial world which in my experience are primarily c based. aside from ib, it's pretty rare to find brokers/data providers that have direct java interfaces that don't use some sort of wrapper. lime is the only other one i know of who are java based, but they are definitely not the norm. it's interesting, most of the programmers i know who code in java have extensive c/c++ experience. to them, portability to various apis isn't really an issue, because they have the expertise to implement any wrappers or bridges needed to the various other languages. so, i really like the concept of java, but i think if you want to remain flexible in data/brokerage options, it may not be the best choice.
All modern operating systems support some sort of memory mapped I/O. Regardless of programming language, nothing will be faster than letting the operating system handle all file I/O in the kernel.
for most people on ET, a shell script with a few sleep timers thrown in is good enough. the closer you get to the metal the more you will understand what is actually happening. however, as a trader or analyst do you care what is happending under the hood? i think you should go as high level as possible and work on the trading logic; even there most people will give up within a week.