Yeah. If you know where your bottlenecks are, the catch-all solution is not to just start spawning threads willy nilly, but to attack the bottleneck. In your case, if you're just calculating moving averages, just update one quote at a time. You should be worried about numerical instability -- so just recalculate the whole damn thing once every 100 ticks or something. Bam. If you were spending 95% in that area of the code, now your code is like 20 (amortized) times faster. If you really start trading hundreds of instruments, and you really need shared memory for something (the best case I can think of for multithreading is in using shared memory for reads and writes), then I can see the case for multithreading. Premature optimization is the root of all evil!
My trading is a one-man show, it's easier for me to start a new thread than to spend hours on optimizing an algo that might turn to be a flop. If I think I might be using multithreading in the future I might as well start developing for it now to catch all the bugs while I am trading paper/small. Non-multithreading is a viable option that I might try. I've actually asked questions on this forum and elsewhere how people design ATS. Thx for input.
I am unaware of anyone who does a thread per instrument. So you have a connection to some datafeed and all the messages are going down that feed so why would you then thread out a consumer per instrument? As I mentioned before the reactor pattern is what you need and some (not many) threads. As a side note, I just installed cuda and it is sweet. Noticeably faster from just playing around
So to process quotes from each instrument in parallel not sequentially. I have yet to look at the reactor pattern - I did not get to it. I remember your post from before. But if it is not multithreaded then it's a single threaded. Let's say not one thread per instrument but one thread per few instruments. I can still change that part though to non-multithreading. Frankly I just do not know how long my algos are going to take to run. I am waiting for the Xeon Phi to be available to the general public, it should to be easier to program.
Right now nothing. But I would like to use it for pricing on the fly. Currently, my firm does a lot of precalculating and caching.
+1 for this, boost::asio::io_service is the modern version of this, jeepers, it's been a while since I've seen someone mention ACE.
Just to make sure what ya all touting is to implement a reactor pattern instead of using multithreading which processes quotes for each instrument in a synchronous, sequential way? So if I trade twenty instruments (that's my near plan) then the algorithm will be processing the instruments sequentially. I still think this is much depends on algo, if algo takes for example more than a half a second (all optimized and dilly) then I do not think it's possible to get away w/o multithreading. I am going to branch my code to implement reactor pattern version of my strategies execution system and see what happens. Thanks for input, guys.
Change your data sampling to a different scheme. What you suggest is discouraging for readers to continue to read your posts.