Trading Technology

11:34 AM
Connect Directly
Twitter
RSS
E-Mail
50%
50%

Is HFT Leveling the Playing Field?

As lawmakers look at high-frequency trading, firms continue to shave the time off of their trades. WST spoke with Azul Systems CEO Scott Sellers for his take on high frequency trading going forward. Is it still full steam ahead or are firms looking to back off?

Wall Street & Technology: Are we reaching the point of a level playing field when it comes to HFT? There are several IT solutions that claim to offer the same speeds. How can hedge funds and fast trading firms know they are getting the fastest speeds when trading?

Scott Sellers, Azul Systems: The playing field is ‘nearly’ level for HFT. As in any arms race, it’s a constant battle to stay ahead with diminishing marginal returns given how market structure has changed and will continue to evolve.

Cutting-edge solutions are a combination of proprietary software and some off-the-shelf hardware combined with software components. There are few absolute secrets in the financial sector – everybody knows everybody’s capabilities – and behavior in the market can be monitored. Markets must ask themselves how much they are able and willing to invest in technology and for what return.

WST: How are hedge funds reaching their fastest speeds possible these ways. We all hear about super fast networks but how do JVM fit into the big picture?

Sellers: The only way to reach the highest possible speed is to optimize every latency-inducing step. Fast networks are essential, as are high-performance NICs.

Many software components are built in Java, since it is the best language for developer productivity, and in most cases capable of meeting (or beating) the performance of a similar system written in C or C++. A predictable/deterministic JVM eliminates the variability and random jitter that challenges the performance of traditional JVMs.

WST: Are firms still pursuing top speeds as regulators and lawmakers consider a trading speed limit?

Sellers: Of course.

WST: What will a speed limit do to fast trading firms?

Sellers: There are many ways to compete. Raw speed is only one particular edge case; sustainability and predictability are equally important. The next logical step is higher-speed algo. A level playing field in terms of order entry and trade execution implies that a firm’s competitive advantage will be based on upstream pre-trade and real-time analytics (algo) – which is the basis for generating alpha over the long haul as technology arbitrage by definition cannot go on indefinitely. What is interesting is that though it is based in technology, limiting the speed will ultimately affect the business facet of a trading firm.

WST: Are firms using HFT for different asset classes besides equities and FX? Do you need this for commodities and bonds, for example?

Sellers: Today equities and FX are the primary users of HFT technologies. Other instruments will be added as and when it makes sense to do so. The pressures to innovate are endless in our industry.

WST: How does your solution help traders who want to take advantage of opportunities in emerging markets?

Sellers: Our software operates at a level just above the operating system, and as such is market structure agnostic, ie not application-specific. We team with a variety of trading systems vendors who adapt their platforms to multiple sectors, including emerging markets. By integrating their platform and components with our Java runtime, they can deploy a solution that can get to market quickly, without the need for time-consuming and expensive JVM tuning whenever the application (or market) changes.

WST: You mention getting to the ideal of a no risk race. Does such a thing exist? What would it entail?

Sellers: The ideal of a no risk race is based upon certainty of execution. This is is a goal that is achievable and in almost all cases. Of course, there are always edge cases where profits can be made -- and optimizations that can effectively target those scenarios. Our customers combine the best technologies available with the best people they can find -- and this combination is applied to areas where new opportunities reveal themselves.

Phil Albinus is the former editor-in-chief of Advanced Trading. He has nearly two decades of journalism experience and has been covering financial technology and regulation for nine years. Before joining Advanced Trading, he served as editor of Waters, a monthly trade journal ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
WillB093
50%
50%
WillB093,
User Rank: Apprentice
7/27/2013 | 8:55:48 PM
re: Is HFT Leveling the Playing Field?
Correction to my comment above, it is in regards to traditional JVM from Oracle/Sun. I can't say about their JVM, if that is what they are referring to. Maybe I will get a demo and try it out :-) it sounds interesting.

I would be really interested to see the performance gains on a product like StreamBase or another Java based CEP would get from their product.
WillB093
50%
50%
WillB093,
User Rank: Apprentice
7/27/2013 | 5:43:12 PM
re: Is HFT Leveling the Playing Field?
As of now, no. Java is usually off by about 30-40% in tight for loops, and is slow on method calls when compared. When handling FIX messages, market data etc it is best to keep a thread spinning on a producer/consumer like queue constantly checking for new messages than to wake threads up on events due to the time to wake up the threads and the uncertainty on the wake up time in the kernel's scheduler. Java's GC slowness can be overcome by having a object pool pre-allocated in a ring, but then you are managing your own memory, but it will really help. That was something I noticed everyone trading HFT with java found as a must do.

But really the bottleneck tends to be in two places, in my opinion. First, it is the TCP/IP stack in the OS. For example, maybe you will see 9 microseconds to parse a FIX message in C++, 11-13 in C#, about 15-19 microseconds in Java, but it is 20+ microseconds at least for any message to go through the TCP/IP stack one way. This is where things like RDMA over converged ethernet or RDMA over infiniband can really help. I have not yet tested cards with hardware accelerated TCP/IP stacks. RDMA allows you to write data directly from the wire to the memory, avoiding all of that. That reminds me to check if exchanges support direct RoCE / Infiniband connectivity, I will have to check.

This is also where FPGAs play in. FPGAs are extremely hard to program, but if you code the TCP/IP stack and FIX engine in an FPGA it really helps. But this will multiply your development time by 40x at least, not to mention trying to find people crazy enough to want to code VHDL etc.

The second bottle neck is FIX. It is a really slow protocol, representing every message by strings. Strings are bloated, and slow to process. A simple way to create a very fast protocol, that can be well defined for everyone, language independent, and is easy to maintain for multiple versions, is Google's protocol buffers. It baffles me why exchanges don't offer native connectivity in something much faster than FIX for oder flow. They have other solutions for market data. If they all offered connectivity with protocol buffers, they just have to send a spec file, using the same tag names, and people can auto generate bindings for all major languages.
Greg MacSweeney
50%
50%
Greg MacSweeney,
User Rank: Apprentice
7/27/2013 | 1:26:34 PM
re: Is HFT Leveling the Playing Field?
Great insight. Is is possible to get equal or better performance with Java? Or, if written correctly, will C++ or C# always win when it comes to performance?
WillB093
50%
50%
WillB093,
User Rank: Apprentice
7/27/2013 | 3:03:01 AM
re: Is HFT Leveling the Playing Field?
I have developed trading algorithms in many different languages in the HFT space. C/C++, Java, C#, etc. I can promise you, the statement above is completely false. I have spoken with some of the largest banks, claiming that even though Java is a slow language compared to C++ and C#, they are seeing just as good performance. This is not true, unless your C++ code is terrible. Most likely, due to complexity of proper multithreading techniques in C++ such as a good thread pool, producer/consumer, async operations, concurrent data structures, the C++/C code was poorly written. Also, there are many languages that offer much higher developer productivity depending on the problem. In general, I prefer C#. It is just the right mix between productivity and performance.
Register for Wall Street & Technology Newsletters
White Papers
Current Issue
Wall Street & Technology - Elite 8
The in-depth profiles of this year's Elite 8 honorees focus on leadership, talent recruitment, big data, analytics, mobile, and more.
Video
Exclusive: Inside the GETCO Execution Services Trading Floor
Exclusive: Inside the GETCO Execution Services Trading Floor
Advanced Trading takes you on an exclusive tour of the New York trading floor of GETCO Execution Services, the solutions arm of GETCO.