Probably there where implementation errors. Like, for instance, wrong formulation of limit price, or inconsisten handling of partial fill events, etc. There can be many reasons, but the least probable of all is the programming language. [ This said by one who hates java, and loves .NET ] Tom
ICE runs almost completely on Java; I think they're doing a bit more than your spread execution engine.
There are lots of platforms out there. Just check http://www.elitetrader.com/so/ From there you need to formulate some requirements: 1) Do you want the platform to work with multiple brokers? (tradestation isn't there) 2) Do you want the platform to have order API so that (with some programming effort) you can connect it to the broker of your choice? (discard ninjatrader, sierracharts and many others) 3) Do you want the platform to have guaranteed latency? (discard anything that is Java or .NET)
lol: I don't use the WebICE or the ICEMaker applications because it doesn't support the level of automation and speed myself and some of my clients require. I have no use for the ICE front end's stock order matching implied pricing strategies. That's just me - take it or leave it. If you are trading those supported products without highly capitalized higher frequency external arbitrage considerations, then fine. My bad. Myself and many of my clients trading ICE are using Orc and TT dedicated ECN lines using Advantage servers which are co-located at the ICE server farm on LaSalle Street in Chicago. One of my clients located in Australia is using the new CQG spread driver platform with direct dedicated lines to MF's co-located servers. FWIW, I have never had much luck injecting complex, contingent orders across multiple exchanges where speed and latency is life or death if Java is involved. Typically, we pay up for dedicated ECN lines, a high-speed API like TT, Orc, CQG, Portware, Apama, and the FCM's co-located servers at the exchange. et: phone home. not a clue for you.
Let me repeat this for your benefit. Whatever the problem is or was with whatever piece of software you are/were using it is NOT the Java programming language or the the Java virtual machine. Java is mature, robust and has good performance. It is in the top two or three (if not the top) programming languages in the world by usage. It has not achieved that position by chance. Your assertion is just not credible.
There are two camps out here: Java and C++ i am an old-school C++ hard wired, close to the metal trader
I wasn't referring to ICE front end software; I'm talking about the entire ICE infrastructure. Everything they run is Java except for the order matching engine. You can make Java go extremely fast, but it's arguable if at that point there's any benefit over choosing C/C++. Additionally, I know of two firms that are very active in the HFT space using Java. I wasn't attacking you by the way, just offering my opinion/insight. The place I work is all C++ based and we embed Lua for quick scripting.
Intel and AMD (and others) want software to run as fast as possible on their chips so they have labs where they test different languages. They work to make sure their chips support what is needed for various languages to run fast and also suggest improvements to the language compilers. Now hypothetically, say you knew someone at one of these labs, and asked them which was faster; Java or C++. Well, yes it does depend. But the answer (hypothetically of course) will be Java (and I assume C#). In fact Java has been faster than C++ for several years. Yes Java is slower to start up (the JVM has to start). Yes Java will take up more memory and run slower at first but ultimately, Java is faster. Memory allocation and destruction is an order of magnitude faster. The JIT (just in time compiler) optimizes the code as the program is running (hence running slower at start up), optimizing the code to run as fast as possible on the particular chip (they are different). Now even if this was not true, there is a fundamental reason why C++ will never be as fast a Java again⦠pointers. I use to love pointers, but a C++ compiler can NOT KNOW what a pointer points to. The Java JIT knows what everything is so it can do optimizations that a C++ compiler canât. As a simple example if the program multiplies an array of numbers by another array of numbers, and does this often. The Java JIT, knowing what the type of the numbers are and that that they are used over and over again can store them in a register as needed, the C++ compiler canât, it canât guarantee that the numbers are floats or ints, or a string for that matter. Then there is garbage collection. There are now garbage collectors that run in their own thread and on their core if you have a multi-core machine. Java is now used very heavily on Wall Street.