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

migration rejected from stackoverflow.com May 4 at 10:18

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as too broad by gnat, MichaelT, GlenH7, Bart van Ingen Schenau, amon May 4 at 10:18

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the 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
comments disabled on deleted / locked posts

6 Answers 6

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
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
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
    
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
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
    
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

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
add comment

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