You could not possibly be more wrong about those statements. Aside the fact that it is totally ludicrous that the term hft even appears on this website and is thrown around by all the hobby gamblers as if they knew the slightest about hft, language of implementation is absolutely crucial in hft. A few microseconds and in some components even nanoseconds of additional latency decides whether a hft operation is absolutely guaranteed to fail or not. You may be offered colocation directly at the matching engine and yet miserably fail because you implemented a market making algorithm and feed handlers and oms in Java or C#. So, your order of importance is utterly wrong and speaks of lack of knowledge or pure ignorance
New to HFT and Looking for support/help . We all started here, so hope some people can help me
- Thread starter BabaYaga
- Start date
its a pretty over the top reaction to what i wrote. so ill write a bit more to help you not misunderstand it.
firstly the total transit time from tick to trade is made up of many sequential components. its a long journey to reduce the time for all of these components. the programming language absolutely is not important until you have worked through 100 other large challenges (or you buy your way in to it).
secondly if you are running on a cpu, you can write single digit microsecond handlers in any language. its a myth that c will be faster. you have to understand that the sockets are going to be driver level, nothing to do with your code. javscript for example, can benefit from Open Onload, which is a common os-stack bypass library for Solarflare, same as any c application.
thirdly by the time the language 'might' come in to play, you will be considering running code on fpga where there is no choice. you are forced to use not only a specific language but a specific sdk provided with the fpga.
Last edited:
Even that is vastly incorrect. A socket in C or C++ will always perform faster han a C# implementation using the Net socket class. Same with many other components. There is a reason nobody in hft land uses c# or Java for Mission critical components. Most latency critical components are anyway implemented in hardware stacks via very specific (assembler like) hardware friendly languages or in C.
and fortran for fpga cards, which is great for hft.
Well, about that - since in most cases you know that any latency-sensitive strategy will sooner or later start bumping into your w2w latency, you might as well right away write the actual execution engine in C++ from the start, right? I mean yes, moving execution from your desktop and finding a PB that will not require a risk check is an easy win, but if you are trading anything intraday, it would make sense to plan it in advance.
True that. Plus, you can buy reasonable feed handlers for pretty much every exchange feed from a variety of vendors - unless, of course, you are a true UHF player. I am not, for example, so it was an easy choice
In fairness, if you are doing any real calculations, the choice of language would matter even if you stay in the x86 paradigm.
I think the crucial difference is that you are talking about true HFT, who are playing order book games etc. There are plenty of people like myself out there. I do not consider myself an HFT trader but I do have some latency-sensitive alpha and, more importantly, improving latency is a way to reduce negative selection and thus overall slippage (even for non-algo guys, btw).
no thats a myth.
not really. on x86 its all about the same.
the whole thread is ridiculous anyway. i dont see the purpose as this guy is a complete beginner.
And that is the crux of the story, how many here on this forum confuse intra day trading strategies with hft/uhft. But mostly vendors and money grabbing broker sales people here are to blame for this, which is that they suggest hft can be implemented by mere mortals with a home pc or some VPS. Anything that is latency sensitive in the millisecond realm even is not realizable by 99.5% of retail traders and language of implementation greatly matters.
Well, about that - since in most cases you know that any latency-sensitive strategy will sooner or later start bumping into your w2w latency, you might as well right away write the actual execution engine in C++ from the start, right? I mean yes, moving execution from your desktop and finding a PB that will not require a risk check is an easy win, but if you are trading anything intraday, it would make sense to plan it in advance.
True that. Plus, you can buy reasonable feed handlers for pretty much every exchange feed from a variety of vendors - unless, of course, you are a true UHF player. I am not, for example, so it was an easy choice
In fairness, if you are doing any real calculations, the choice of language would matter even if you stay in the x86 paradigm.
I think the crucial difference is that you are talking about true HFT, who are playing order book games etc. There are plenty of people like myself out there. I do not consider myself an HFT trader but I do have some latency-sensitive alpha and, more importantly, improving latency is a way to reduce negative selection and thus overall slippage (even for non-algo guys, btw).
Re sockets, the safety that the .NET runtime provides will add some overhead. Eg. buffer lengths will be checked, delegates validated etc. If the limit on the application is CPU then this is likely to make a difference, and at the extreme a small difference can easily add up.
Also the .NET version will occasionally pause for GC (.NET 4.5 does asynchronous collection, so this will get better in the future). There are techniques to minimise garbage accumulating (eg. reuse objects rather than creating them, make use of structures while avoiding boxing).
I still suggest you don't know what you are talking about. I leave it at that.
Also the .NET version will occasionally pause for GC (.NET 4.5 does asynchronous collection, so this will get better in the future). There are techniques to minimise garbage accumulating (eg. reuse objects rather than creating them, make use of structures while avoiding boxing).
I still suggest you don't know what you are talking about. I leave it at that.