Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

If one were a quantitative developer, what factors are considered in language choice?

I am talking high frequency trading on the scale of investment banks.

I know latency is definitely a factor and maybe readability of code (not sure how much code is altered in which case this would be big). Anyone with more knowledge on this know the pros/cons sought in development?

share|improve this question
1  
May you give more details about what you are trying to achieve? –  kiamlaluno Nov 25 '11 at 14:55
    
Have you looked at the Job Postings for HFT? Often they require C++. –  JBRWilkinson Feb 14 '12 at 9:58
add comment

migrated from stackoverflow.com Nov 24 '11 at 21:16

This question came from our site for professional and enthusiast programmers.

8 Answers

up vote 7 down vote accepted

(I worked in financials/trading systems for many years, in several languages) Since you're already talking on such a scale, I'll assume that you have enough hardware horsepower to drive whatever you need to be competitive, so I'll eliminate the question of execution speed from the discussion.

Readability you already mentioned - and that is indeed important. BUT, not because you're going to write a great work of literature. The reason readibility is important is because it's part of maintainability and agility, which are what you really need to consider more than anything else.

The key is that in such an environment, you can't take a lot of downtime to fix things - you must be able to fix any bug quickly and correctly with minimal downtime and inconvenience to your users. (A trader whose system is down can be very dangerous, especially around developers... LOL [but not too loud] )

And this has more to do with coding style, developer mindset and development infrastructure - version control, carefully versioned and documented releases that you can get back to and patch, etc - than it does with any particular language.

So I think your question is slightly off point. It's not a question of language so much as of developer/management culture and dedication.

But if you want to talk language, I'd say Python/PyQt is the way to go, with the hardware available today.

I make my living writing Delphi code - but if I had a choice, I'd be writing everything in Python. When I code in Delphi (or even more so C++) or even C#, I feel like I'm spending at least half of my time on things that Python would take care of automatically - things that are irrelevant to the program itself - grunt work or even things that require great expertise but that I should not have to deal with.

How much code do you need to write in C++ to manage memory and keep things type safe? How many bugs are introduced because of the difficulty in managing these and similar issues. It's amazing when you think about it - don't use a 20th century tool in the 21st century. That will decrease your maintainability and agility and could be lethal.

share|improve this answer
add comment

I think the two primary concerns are performance and correctness. The best performance is usually obtained with a language like C or C++. But on the other hand, functional languages are the best in terms of verification -- languages like OCaml and Haskell.

But high-frequency trading isn't limited to software; the lowest latencies are achieved by implementing critical parts of the system in hardware, where languages like VHDL, Verilog or even variants of Java that compile to hardware are used.

In particular, hardware enables clocks to be synchronized to within +/- 15 nanoseconds of UTC -- this means you can have machines distributed in major centers such as NY, Tokyo & London, and they can synchronously execute complex trades at precisely the same time, with nanosecond precision. Implementing logic in hardware means you can react to a packet and have a response back on the wire in nanoseconds, rather than microseconds or milliseconds (as would be the case with a software system).

A specific example of hardware acceleration being used in finance is monte carlo option pricing -- these hardware systems are orders of magnitude faster than micro-processor based systems, resulting in much better prediction per unit of data center area, power, and per unit of time.

See this paper about hardware acceleration in monte-carlo pricing: http://onlinelibrary.wiley.com/doi/10.1002/cpe.1778/full

share|improve this answer
1  
This. The whole point of high frequency trading is that your code runs faster, and with lower latency than everybody else's. –  Dean Harding Nov 26 '11 at 9:16
6  
@DeanHarding Yes I agree that throughput and latency are the primary concerns, but I think there is still something to be said for correctness -- being the fastest with the lowest latency could be pointless if there is a critical behavioral fault. –  Anthony Blake Nov 26 '11 at 9:26
1  
btw, a while back there was a lot of hype about a language called Bluespec -- it is a hardware description language drawing on the semantics of haskell and the syntax of Verilog. It seemed promising in that it offered almost the full performance of VHDL or Verilog, while enabling much faster development and design space exploration. Being a functional language, it seemed as though it might also offer advantages in terms of verification -- but formal semantics for the language didn't exist when we asked a few years back. –  Anthony Blake Nov 26 '11 at 9:31
    
I totally agree with this answer, let me just add that by the description of the problem, I'd take care to watch out for your Transactions implementation. Either all works, or every thing as to go back to the original state –  IvoC Nov 28 '11 at 11:28
    
@AnthonyBlake Thank you for providing a link to that paper about improving Monte-carlo simulation performance, as fulltext. Very thoughtful. I'm not disagreeing with your answer, but note that a custom build i.e. implementing logic in hardware, is rather non-portable. But for algo HFT, I guess the usual objections to such aren't relevant? The cost and one-off development is acceptable in this context, right? –  Feral Oink Feb 14 '12 at 9:08
add comment

Working in the algorithmic trading environment for over 6 years now, I can tell you what we/ I use:

  • For the front end, we use C#.
  • For the back end, we use C# and C++

As computer systems become more powerful, the real bottleneck is the network, not the hardware. You have to handle so much data in a second, it sometimes seems ridiculous. And this data will increase, since more and more automated systems will enter the market, producing more and more data.

You can profit from the features of C# as a developer by just adding more hardware when you need it (hardware becomes cheaper every year). I did not have any misgivings that I chose the wrong programming language by going with C#.

Also, I know that a lot of companies use Java for front- and back-end systems.

Clarification:

  • front-end: the user interface for the trading system, where all the parameters can be changed
  • back-end: the system that manages all the orders and has all the logic
share|improve this answer
1  
Say, I was just wondering what "front end" and "back end" mean in relation to algorithmic trading? Still trying to grasp what they even mean in a general sense lol thanks –  Dark Templar Dec 17 '11 at 8:18
add comment

I work for a trading company (www.betonmarkets.com). We have exactly the same set of problems. We use Perl all through. Even big banks and investment bankers use Perl(I have friends who work for Goldman Sacs). The big advantage with Perl is that quants are often quite aware of the language and find it easier to experiment with it. The disadvantage is that language is quite a sucker for bad coding practices. We have also started trying functional languages like Erlang. But getting people to code those languages are still difficult.

For just distributing tick information across the systems you need a simple broadcast mechanism. You normally receive ticks only once a second at the best. So you need a centralized or a cluster of servers that can get all the ticks and filter them. This server then broadcasts all the ticks for the second every second. Typically this is limited by the number of things that you want to trade. You can use a pull and cache system where after generating a tick the servers will push the changes to a cache for each server which has to get the tick. After this you can use daemons that come alive every second to pull the changes from the cache. Again this cache can be in or more servers.

In my experience low latency is not a factor at all. Stuffs like video chat or VOIP has to have a latency in ms but tick data has latency in seconds which almost any network can handle. It takes less than 200ms for ping information to travel across the world hopping on over 30 gateways.

For coding stuffs like Monte-Carlo pricing engine you need C as it requires high number of computations. For starters I would recommend C running on an Amazon GPU machines, alternatively you could buy a high end gaming PC for smaller scale operations. They are really good at munching numbers, just the thing you need for Monte-Carlo pricing.

share|improve this answer
    
Check out this paper on using hardware for monte-carlo pricing (270 times faster than an Intel Core machine): onlinelibrary.wiley.com/doi/10.1002/cpe.1778/full –  Anthony Blake Nov 26 '11 at 9:40
    
I'll check out the paper. On a second thought, the Cell processors that come with PS3 are said to be more powerful(per $) than standard version GPUs. I haven't found any one trying to use a bunch PS3's running over network to do these sort of calculations. –  arunmur Nov 27 '11 at 1:08
    
Yes, the Cell is a very fast multi-core SIMD processor. They aren't just found in PS3's though: I believe IBM sells several blade servers that are packed with a few Cell processors for serious applications (not gaming). I think Sony makes a loss on the PS3 hardware, so they have made moves to restrict its use outside gaming. –  Anthony Blake Nov 27 '11 at 2:07
add comment

There's not going to be a "one size fits all" solution. Different priorities in your HFT strategy will guide you towards different languages. Algorithmic / high frequency trading is a very broad field of endeavour.....

I think the most important elements to consider are:

  • Raw performance - likely to be the biggest factor if you are doing complex calculations or modelling and need answers as quickly as possible. Would favour heavily optimised languages like C/C++ or possibly Java. Alternatively you might look at GPU languages. If your strategy depends on complex numerical calculations or monte-carlo simulation, this will probably be your most important factor.
  • Provability - important of you want to prove the correctness of your algorithms. Mistakes will be very expensive. Would favour statically typed functional languages like Haskell or OCaml.
  • Latency - Some languages have fun stuff like garbage collection pauses which can catch you out in a truly low-latency situation. This would favour languages without GC (e.g. C/C++) over garbage-collected languages like Java (although note that Java does have HFT-friendly libraries like http://javolution.org/ designed specifically to solve this problem). If your strategy is very latency-dependent, then this could be the biggest factor.
  • Prototyping / development speed - clearly in some situations it is critical to develop and test your algorithm as quickly as possible to exploit the window of opportunity. Would generally favour dynamic langauges and concise functional languages - Ruby, Python, Clojure perhaps. If time-to-market is most important, this could be the key factor.
  • Integration - you'll potentially need to interface to many different information sources / back end systems. Would favour the language with the best coverage of libraries and integration options - Java is probably best here, but C/C++ might be a close second.
  • Concurrency - you'll want to take maximum advantage of your expensive multi-core machines whether for latency or raw throughput. Would favour languages with a strong concurrency approach - Scala, Erlang, Clojure. Likely to be important if you are handling / need to react to very high volumes of events.
share|improve this answer
add comment

If this question was asked few years ago the natural answer would have been C/C++ due to speed.

With the advancement of could computing and functional programming, I would advocate Scala and Akka, Groovy and GPars. If you are still interested in C/C++ have look at Trad4, X20, FastFlow, Theron Library also would be a good choice.

Also Clojur and Erlang are good choices if you are comfortable with the syntax. For Erlang VM labguages if the syntax is a issue please see: - Efene - Elixir

GS uses Erlang internally.

share|improve this answer
    
Erlang has the advantage that it is fault tolerant be design and you can upgrade it without taking it offline. Also it will probably work in a concurrent setting quite well. Haskell might be useful in terms of the correctness features –  Zachary K Feb 14 '12 at 10:33
add comment

The question is a little broad ;-)

If latency is the number one criterion, you want a language that compiles fast code (C, C++, etc).

If speed of development is important, choose something like Python or Ruby.

If an analytical toolset is the most important, choose something like K.

I have seen all of these used in quantitative finance and HFT.

share|improve this answer
    
The question is more about which factors to look at rather than which specific languages to choose. –  Anna Lear Nov 24 '11 at 21:16
add comment

An additional factor would be the knowledge or skill set of the programmers.

C/C++ can be surely used for the purpose but may require more effort depending on the skills of the programmer(s)

Python becomes an interesting option in the sense that it can have the ease and compactness of scripting language and high efficiency as well

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.