Well I assume this is more theoretical question for those who familar with hft. I receive orders from FAST and process them. I receive about 2-3 thousands orders per second. The question is if I should try to process them synchronous or asynchronous.
Every time I receive next order I need to do following:
- update orderbook of corresponding instrument
- update indexes and indicators that depends on that order
- update strategies and schedule some actions if required (buy/sell something etc.)
To do that synchronous I have about 200-300 µs (to be able to process 3000 orders per second). That should be enough I think.
Just to schedule asynchronous task I spent I think ~30 µs
Pros and cons:
Synchronous:
- ++ don't need to synchronize things!
- ++ delay between "order is received" and "actions is taken" is less because don't need to schedule tasks or pass data/work to another process (very important in hft!).
- -- however "order is received" action may be delayed because we can wait in socket buffer waiting for previous order to process
Asynchronous:
- ++ ability to use the power of modern servers (my server has 24 cores for example)
- ++ in some scenarios faster, because don't wait while previous message is processed.
- ++ can process more messages or can do more "complex" things per message
- -- need to synchronize a lot of things what can slow-down program
Example of synchronization: We receive MSFT order updated and then INTC order update and process them in different threads. In both cases we trigger NASDAQ index recalculation. So NASDAQ index calculation should be synchronized. However this particular problem can be workarounded to avoid synchronization... It's just an example of possible synchronization.
So the question is should I process orders updates synchronous or asynchronous. So far I process them asynchronous and I have dedicated thread per instrument. Because I can process asynchronous two updated for different instruments (MSFT and INTC), but two updates for one instrument (MSFT) should be processed synchronous.
I receive orders from FAST and process them. I receive about 2-3 thousands orders per second
Really? You work at an exchange? Becuase seriously, I get data from 5 exchanges, but those aren ot orders ;) I suggest you get your term in line - you get 2-3 thousand EVENTS, but I really doubt you get ORDERS.
Have you ever thought of doing a multi stage processing setup? I.e. you get data in 2 thread, hand it over to another thread to find the instrument (id instead strings), hand it over to another thread to update order book, hand it over to another thread to do indicators, hand irt over to X threads to do strategies?
No need to schedule tasks al lthe time, just synced queues with one tas processing messages on each of them. Can be super fficient with a no-lock approach.
Brutally speaking: I am all for multi threaded, but all in core processing must maintain cardinality, so classical multi threading is out. Why? I need fully repeatable processing, so that unit tests get determined output.
So far I process them asynchronous and I have dedicated thread per instrument
You do not trade a LOT, right? I mean, I track about 200.000 instruments (5 complete exchanges). Allocating 200.000 threads would be - ah - prohibitive ;)
GO staged pipeline - that means that the core loops can be small and you can distribute them to enough cores that you are a lot more scalable. THen properly optimize - for example it is quite common for updates of one instrument to come followed by another update for the SAME instrument (for example multiple executions while a large order executes). Take advantage of that.
来源：https://stackoverflow.com/questions/11306205/in-hft-does-it-make-sense-to-try-to-parallel-orders-processing