Hi,What is the best source of information for one to start learning this (in C++?) ?Book, toolkit, framework, tutorial etc ?is it the same as (or including), concurrency, multi-threading, parallel programming, Network programming.and if Network programming is part of it, what is the best book for that? "Unix network programming"? both volumes?by HF I mean the programming side of the thing, not market microstructure etc.Thanks in advance

Anyone? Algo-trading, High-Frequency trading.I mean is this (technology-wise) an intersection of:Real time system, concurrency and multi-threading, Network programming, messaging system, ..??What sort of technology framework is practice is used in banks, hedge funds? I have heared of ACE in C++.Is that a good starting point, for the network programming part?How would I go about to learn more about low-latency?Thanks I do appreciate your input.

For the network programming side of it, I'd start with a through understanding of the networking stack and associated protocols. Frameworks are fine but a good understanding of what they are built on is also usefull. RFCs are a good place to start. also, if your a glutton for punishment, the source code of your OS network stack implementation. I use Linux and BSD so the source is redilly available, not sure about Windiows.As for low latency, I tend to concentrate on almost fanatical code tuning using profilers, benchmarks and lots of refactoring/testing etc, remove, or delegate, from the critical execution path, everything that can be (logging, heavy buffer minipulation etc) and tune the rest, an understanding of how the compiler optimizes code can be useful here. I am currently testing on a real time operating system, this seems to provide a pleasing spike in performance. xxil.

No, there is no escape from Stevens. Frameworks are of secondary importance. It is not even difficult to map your own socket API once you understood the concepts.Personally, I don't like reading RFCs, but who am I....

Usually the low level network/messageing stack is written in C/C++.Have a look at ZeroMQ, ActiveMQ, OpenMQ etc..On top of this the application layer where the trading logic takes place is often written in a high level language such as Java or C#(.net)in this level multithreading and concurrency are the basis for design-patterns that promotes low latency and scalabillity. Especially now that multi processor computers is the new black, this truly is technologies to master. Google "Amdahl's law" to get an idéa.However, low latency/ high frequency trading today is in alot of markets so sofisticated that you need a lot more than this to stand a chance.Hardware, networking protocols and co-location are other things to consider. I know a guy who is constantly rewriting his linux kernel to make the system go faster..If you want to be apart of this, I would suggest you pick an area.. network, java concurrency, messaging MQ, kernal design or other.. and turn youself into an expert in that area./P

QuoteOriginally posted by: xxilFor the network programming side of it, I'd start with a through understanding of the networking stack and associated protocols. Frameworks are fine but a good understanding of what they are built on is also usefull. RFCs are a good place to start. also, if your a glutton for punishment, the source code of your OS network stack implementation. I use Linux and BSD so the source is redilly available, not sure about Windiows.As for low latency, I tend to concentrate on almost fanatical code tuning using profilers, benchmarks and lots of refactoring/testing etc, remove, or delegate, from the critical execution path, everything that can be (logging, heavy buffer minipulation etc) and tune the rest, an understanding of how the compiler optimizes code can be useful here. I am currently testing on a real time operating system, this seems to provide a pleasing spike in performance. xxil.which realtime OS are you using?

I am currently working on Suse RT, Just the standard Suse distribution but with the RT patches applied to the kernel.RTWiki

I recently tried migrating a "high-throughput" -design in Java to "Java Realtime system" running on Ubuntu with RT kernel.A bit dissapointing result though. Very low variance on "time to compleation", but on average It was a bit slower..My conclusion so far is that RT systems are better for predicabillity then for speed, also the preemption abillities might work for a scalable design in a system where you'd have some very important process and a lot of not so importent processes..

QuoteOriginally posted by: xxilI am currently working on Suse RT, Just the standard Suse distribution but with the RT patches applied to the kernel.RTWikiWhy do you choose to work on SUSE, instead of other Linux distributions, there're many other real-time OS based on Linux. Is that due to support provided by Novell, I mean for enterprise SESU targeted at servers?Related to latency, I think networking, kernel and CPU cache misses are all important areas to be examined, not to mention the high performance C/C++ code, 20% code usually takes 80% of the time, so a lot of optimisation is usually needed.