How important is microprocessor speed in the HFT ecosystem?
—
Its not the speed of the individual systems but the aggregate data models speed in coming together. This is a simplistic view of a very complex set of problems with latency factors for each layer as well as each delivery channel and application.

Simultaneity and the ability to react in advance of the market-workflows by fast-telemetry and its operations opens a number of potentials and new infrastructure control issues to prevent infrastructure-based frauds. So yes to some extent the speed of the HFT system is key as is the latency of the channels it talks to the exchanges it deals with.

Our solution by the way is to provide NIST UTC Services everywhere the trading platforms are operating. This makes compliance with the OATS and basic risk processing in secured computing much easier to document from a forensic standpoint
—
HFT will go to GPU and/or FPGA based computers/applications soon. CPU’s cannot keep up.
4
—-
Agreed – that’s why I already have NTP running as a stand alone process in the GPU. The CUDA GPU Direct rocks!

It all depends. If your network connection is not very fast, it makes no sense to invest in sophisticated solutions such as FPGA. Definitely it is better to invest your time and money in the optimization algorithms in C/C++ and possibly fast CPU.

GPU is not a particularly good option in the HFT. With GPU you gain high throughput and the possibility of parallel computing, but if you want to have ultra-low latency definitely a better choice will be a FPGA
—
do you have any links/papers that compare the benefits/drawbacks of using FPGAs vs GPUs?
—-
No and don’t have time to look for them… or to argue that I’m right. You just can compare the speed single CPU core vs single core on the GPU. Next consider that the communication from the GPU (and threads) consumes a lot of time and even if the GPU is integrated with the CPU it must be manage by the chip (like C204 or C206 for the new Intel CPU’s). Be aware that your software will run on OS, which means that the access to CPU/GPU will be based on the syscalls. Also remember that the OS allocates CPU time based on the scheduler, so you can speed up your code if you isolate the code from the os scheduler. The FPGA does not have the OS and all your code is directly in hardware.. so this is the fastest solution… but as I wrote at the beginning, I don’t have the time to explain everything…

GPU is good for the HPC.. and HPC != HFT 🙂
—
http://www.infoq.com/presentations/LMAX

Pay your attention what they say about the cpu’s threads.

FPGA’s are the fastest right now but multi-threading is ever improving in GPU’s. I think the eventual winner will still be a GPU. If the logic changes, the FPGA still has to reconfigured. People are already selling FPGA SDK’s fairly cheaply.