Welcome, Guest. Please Login
Algorithmic Trading Forum
 
  HomeHelpSearchLogin  
 
Pages: 1 2 
Send Topic Print
Next generation architecture for algo. trading sys (Read 23034 times)
amit
Newbie
*
Offline

I like this forum!

Posts: 4

Next generation architecture for algo. trading sys
08/04/08 at 18:04:34
 
I know a lot of places where C/C++ is being used to create platforms for algorithmic trading systems and the quants use this platform to code their strategies. I am currently working for an investment bank and some of my friends at other investment banks seem's to be  following the same model.

Language: C/C++/JAVA
Hardware: Mulitcore CPU's (AMD/Intel)
OS: Linux/Solaris/Windows

I have not heard anyone using/developing algorithms from the s/w point of view to leverage all the cores. We go as far as creating multithreaded applications using boost/ACE in C++. Now, I agree they are challenging but they all can achieve so much only at the EOD.

So my question to all is -

1. What are some of the ways we can improve/create next generation platforms for algorithmic trading system's?
2. What hardware do you want to experiment with or you are using currently?
3. Anyone experimenting with cell processor?
4. Anyone writing parallel algorithms to utilize multicore?
5. Anyone using network as a CPU/Memory?

Any thoughts?
Back to top
 
 
  IP Logged
qroach
Full Member
***
Offline



Posts: 102
London
Gender: male
Re: Next generation architecture for algo. trading sys
Reply #1 - 08/04/08 at 18:11:21
 
And what about grid/cloud computing? Is it not used in IBs at all?
What about openMP, MPI?
Back to top
 
 
  IP Logged
qroach
Full Member
***
Offline



Posts: 102
London
Gender: male
Re: Next generation architecture for algo. trading sys
Reply #2 - 08/04/08 at 18:12:26
 
Using graphic card for numerical computations is also a very fasionable topic - have heard from several people, have seen articles in magazines.
Back to top
 
 
  IP Logged
amit
Newbie
*
Offline

I like this forum!

Posts: 4

Re: Next generation architecture for algo. trading sys
Reply #3 - 08/04/08 at 18:40:21
 
I have used grid computing in the area of risk management (greeks calcuation for OTC trades) and not trading system. We used distributed computing (CORBA) for real time pricing of options. However, CORBA sucks and I don't like the idea of passing around objects. I prefer message passing frameworks over object passing frameworks.

I don't think one can use grid/cloud computing for trading system. IMHO, I think they are more suitable for other applications.

Graphics card for calculations sounds interesting. I guess, the quants who do a lot of vector processing may find it useful. Any quants on this forum?
Back to top
 
 
  IP Logged
Co0olCat
Forum Moderator
*****
Offline



Posts: 128

Gender: male
Re: Next generation architecture for algo. trading sys
Reply #4 - 08/04/08 at 19:39:56
 
I do use CUDA to speed up matrix calculations. My estimates (Athlon 3Ghz, dual core) show that one could gain speed with matrices above 50x50.
Back to top
 
« Last Edit: 08/05/08 at 10:00:28 by Co0olCat »  

"Yesterday is history. Tomorrow is a mystery. But today is a gift, and that is why it's called the present."
WWW timuryusupov   IP Logged
qroach
Full Member
***
Offline



Posts: 102
London
Gender: male
Re: Next generation architecture for algo. trading sys
Reply #5 - 08/05/08 at 09:29:29
 
I have always been wondering why people would use CORBA & ACE for not very distributed projects, like parallel computations. Unless you have some trully heterogeneous and remote clusters with sophisticated load-balancing, you don't need CORBA - could do with just a few HTTP-like commands for sending some data in and out. Or is it floating numbers representation on different platforms that gives a headache?
Back to top
 
 
  IP Logged
amit
Newbie
*
Offline

I like this forum!

Posts: 4

Re: Next generation architecture for algo. trading sys
Reply #6 - 08/05/08 at 16:58:57
 
Consider the following problem. Let say that you want to price 1000 options. Now, let say those 1000 options are split across 4 machines (250 each). One would do this so that market data doesn't overwhelm the box. Now for this problem it is extremely efficient to use CORBA (ICE is better than CORBA).

Parallel computations on the other hand is about being able to split the the computation of those 250 options pricing on a given machine. How can you do that efficiently? Threading is one option to use many cores.

Using Http to do this will slow down the system like crazy. Think about the overhead that you will have for every message sent.

HTH.
Back to top
 
 
  IP Logged
qroach
Full Member
***
Offline



Posts: 102
London
Gender: male
Re: Next generation architecture for algo. trading sys
Reply #7 - 08/05/08 at 17:34:49
 
HTTP or TCP/IP text messages can be sent in and out just like CORBA does - no difference here. Why would it be slow?

The difference here would be only if you have a complex workflow or complex network structure. But 4 computers - is not a complex network.

250 options on each machine - I hope you don't mean creating 250 threads. You just create a queue of requests and serve 2 at a time (on a dual core machine) - right?
Back to top
 
 
  IP Logged
amit
Newbie
*
Offline

I like this forum!

Posts: 4

Re: Next generation architecture for algo. trading sys
Reply #8 - 08/05/08 at 21:28:56
 
You may want to google "Real time notification in CORBA"

I am not saying one should use CORBA. I am just saying that it definitely addressed our problem domain. I personally would have preferred to use message passing frameworks like tibco/LBM. You may want to check it out. They are good message passing frameworks. NO one uses Http. Http has a lot of overhead (Http header). Also, with http how do you intend to send the payload of data? Xml payload or just params. If you use XML you are screwed. If you use params it is just ugly. In REAL TIME SYSTEMS we want minimal overhead.


I am not talking about 4 computers. I am talking about big systems. We had about 20+ blade servers.

When did I say 250 threads? You should be careful when you create threads.  Just having more threads doesn't mean more performance. You may screw up your system if you create a lot of threads. A lot of time would be spent in context switching than doing anything useful.

It is upto your env. If you have dual core you may want to start with 2 threads and then change that to four. At that point it is more about art then science.

I am trying to understand how TBB works (Intel threading framework) may be they have come up with something clever.
Back to top
 
 
  IP Logged
stargrazer
Newbie
*
Offline

I like this forum!

Posts: 7

Re: Next generation architecture for algo. trading sys
Reply #9 - 10/05/08 at 13:29:35
 
amit wrote on 08/05/08 at 21:28:56:
I am not saying one should use CORBA. I am just saying that it definitely addressed our problem domain. I personally would have preferred to use message passing frameworks like tibco/LBM. You may want to check it out. They are good message passing frameworks. NO one uses Http. Http has a lot of overhead (Http header). Also, with http how do you intend to send the payload of data? Xml payload or just params. If you use XML you are screwed. If you use params it is just ugly. In REAL TIME SYSTEMS we want minimal overhead.


Which is to say that if one can send structures across the network in a binary fashion, time is saved by not having to convert from text and back again (which may or may not maintain precision during the round-trip conversion).  Packets are also more compact.  And with messaging libraries, some of them provide redundancy, failover, and load balancing capabilities.  I have used ACE [1] for some work, but then moved to ICE[2] recently, with a minor stop over with RCF. [3]

Quote:
I am trying to understand how TBB works (Intel threading framework) may be they have come up with something clever.


I have not used it myself, but TBB looks good as it abstracts (ie higher level constructs) thread processing even more than does ASIO and Thread in the Boost [4] libraries.

[1]  http://www.cs.wustl.edu/~schmidt/ACE.html
[2]  http://www.zeroc.com/index.html
[3]  http://www.codeproject.com/KB/threads/Rcf_Ipc_For_Cpp.aspx
[4]  http://www.boost.org/doc/libs/1_36_0/libs/libraries.htm
Back to top
 
 
  IP Logged
qroach
Full Member
***
Offline



Posts: 102
London
Gender: male
Re: Next generation architecture for algo. trading sys
Reply #10 - 10/08/08 at 10:56:31
 
TBB and all other mutlithreading-comforting techniques and mutlithreading in general are all critisised now and it has been argued that instead of simplifying or abstracting threads one should have none at all.
Back to top
 
 
  IP Logged
stargrazer
Newbie
*
Offline

I like this forum!

Posts: 7

Re: Next generation architecture for algo. trading sys
Reply #11 - 10/12/08 at 12:54:12
 
qroach wrote on 10/08/08 at 10:56:31:
TBB and all other mutlithreading-comforting techniques and mutlithreading in general are all critisised now and it has been argued that instead of simplifying or abstracting threads one should have none at all.


It is nice to see that you substantiate your remarks and provide a good number of references to support your theories.  One might get the <mistaken> impression you know something others don't.
Back to top
 
 
  IP Logged
qroach
Full Member
***
Offline



Posts: 102
London
Gender: male
Re: Next generation architecture for algo. trading sys
Reply #12 - 10/15/08 at 13:30:34
 
You put more meaning into my words than I do .. and you definitely got a mistaken impression that I am arguing against TBB or promote some theories.

I just pointed out that there is some critisism in the world out there, critisism of mutli-threading as opposed to true parallel computing. And there is nothing special one needs to know about it that.

See for examples:
http://www.concertant.com/Presentations/accu2008_themThreads.pdf

It isn't meant to say that TBBs are bad or not practical or not a proper way to go. Critisism comes mainly from academia sort of people and they cannot convince practitioners that Haskell is the only way to program properly. C++ is a horrible language but very practical. Comparing to usual multi-threading/synchronisation any additional absatraction in the form of TBB or OpenMP is definitely good.

On the other hand, it makes sense to be aware of the critisism and its main points, think about it and be prepared to adopt other programming paradigms when the need arises (perhaps, never???)
Back to top
 
 
  IP Logged
stargrazer
Newbie
*
Offline

I like this forum!

Posts: 7

Re: Next generation architecture for algo. trading sys
Reply #13 - 10/18/08 at 19:45:44
 
qroach wrote on 10/15/08 at 13:30:34:
I just pointed out that there is some critisism in the world out there, critisism of mutli-threading as opposed to true parallel computing. And there is nothing special one needs to know about it that.

See for examples:
http://www.concertant.com/Presentations/accu2008_themThreads.pdf

On the other hand, it makes sense to be aware of the critisism and its main points, think about it and be prepared to adopt other programming paradigms when the need arises (perhaps, never???)


Once one tosses away all the levels of abstraction, it is hard to not deal with threads.  On the other hand, adding in levels of abstraction helps to remove the difficulty of multi-threaded programming.  

The last slide of the pdf referenced in the link above makes the bold statement of "Always use message passing".  But to where does one pass the message?  To another process, of course, which happens to be running in a different thread, perhaps on the same machine, or a different machine.

So if one is dealing with a smaller number of messages per interval, abstractions like this work well.  But when one is working with high frequency messages, say high frequency quotes and trades, one needs to work at a lower level abstraction in order to remain within certain compute and latency bounds.  Working with a number of threads over a number of processors with some form of inter-thread message passing, seems to be the norm for improving performance.

Message passing is good, but how does one eliminate the threading element?

Having beat that dead horse, I have another one I'd like to beat.  Regarding multi-paradigm programming, it follows that one should use the best tool for the job.  Sometimes a multi-wrench works, sometimes a specialized one does better.  Here is a link supporting the multi-wrench concept:

http://bridgewater.wordpress.com/2006/10/03/c-is-a-multi-paradigm-language-item-...
Back to top
 
 
  IP Logged
qroach
Full Member
***
Offline



Posts: 102
London
Gender: male
Re: Next generation architecture for algo. trading sys
Reply #14 - 10/20/08 at 14:59:06
 
The idea is not about having no threads at all but about complete isolation of parallel paths or to say in plain English pretending to have no threads.
The problem with pretending is, however, that there should be some supporting mechanism. One can ignore existence of threads and use some non-thread safe containers, for example. Compiler says nothing, program run says nothing but one day the program crashes. On the other hand, there are many places in program execution that could be parallelised, but programmer doesn't give any hint about what is independent of what, i.e. pretends there is no parallelism. And so on.
One way is to use language that can guarantee isolation (like SQL or Haskell). You write SQL queries pretending that noone reads the DB at the same time and have no way to define a global variable that would otherwise compromise isolation. Haskell, on the other hand, provides clear demarcation between functions that have any side effect and those that don't. So, when you write a function that performs some potentially parallelisable calculations you don't need to define where the thread boundaries should be - it is all parallel for you automatically. And there isn't any thread synchronization as such neither in SQL nor in Haskell. Of course, in practice SQL fails to deliver good performance on the highest transaction isolation level.
Another way is to use message streams as the only way to connect different threads/machines. Again, clear boundary between parallel chunks and no synchronization.

On the practical side, nobody uses Haskell/MPI/SQL for high-frequency finance. Surely, C++/threads/sockets/IO completion ports rule in reality. But who knows...

Conceptually, it seems plausible that multi-threading can hardly cope with ever-increasing complexity. It has always been hard to work with, hard to debug, hard to guarantee anything.
Back to top
 
 
  IP Logged
Pages: 1 2 
Send Topic Print