most exchanges offer FAST connectivity. A lot of fx ECNs and brokers provide APIs that are faster than Fix.
You obviously don't know that Nasdaq's own protocol does only support the most basic order types and not even routing. Oh well. Good luck with your C# FIX engine, you'll be a multi millionaire soon
lol, dont change topic. We never talked about different order types. We talked about alternatives to FIX, there are and by the way, Rapid's Fix engine in C# is still faster than most other commercial fix engines based on C++. Stick to C++ or C, I never said I have a problem with that, but so far you still failed to show me a single example where C++ significantly outperforms and why I should consider it for my own platform. I run high frequency FX strategies and believe me, I spent a lot of time considering different approaches to implementation. In the end C++ did not give sufficient performance boost to justify the incredibly longer development times. (don't judge my C++ skills based on that, the development time boost using C# is a well accepted fact in the industry). Edit: By the way, there are some excellent .Net libraries popping up that give full access to CUDA, if necessary. I am not trading ultra high frequency, which would necessitate Linux, specialized network hardware. If I did I would most likely code in C++. For profiling strategies, and trading high frequency fx algos, however, no distributed Matlab, no R, no C++ platform so far beat the throughput and latencies of my own .Net platform.
Anyway I'm getting a bit bored with this discussion. If you really believe C# can match C++ speedwise, then good for you. I wish all competition believed that and was coding in C#
No, but its a widely used product among a number hft shops and believe it or not, I, like you speak to people in this related field. So, any example where you see C/C++ running circles around a profiling platform written entirely in C#? Any example where you as retail/low-tech hedge fund get orders to market significantly faster with C++ libraries than C# ones? I love to hear it? I find it hard to imagine how you want to beat hardware through puts and latencies that I already reach on my C# platform, but please enlighten me. All you have done so far was using buzzwords but no concrete examples. Typical case of C++/academic arrogance in my book.
LOL and just a moment ago you said you didn't know a single hft firm that used FIX ? You're full of it. Anyway good luck to you and your C# algo's
Not to my knowledge at the moment, most use FAST now but they did use FIX before. Alright, there might be some that use FIX, I only speak to people who work at a few of the hft shops but it does not negate the fact that there are faster solutions out there than FIX. You are playing with semantics, you STILL did not make your case whatsoever. I am not trying to challenge you personally, I challenge your statement "C# is garbage". I seriously am curious how you observe a speedup you YOURSELF using C++ routines over C#.
Like said, the average C++ fix engine is way faster than the fastest commercial C# engine. I pride myself that the C++ fix engine that I've developed myself is faster than the fastest commercial C++ engine out there (although it's become kind of obsolete due to FPGA's). What else do you need to know ?
great, I am happy for you. My C# profiling platform is also faster than anything I have seen out there on the commercial side. So? It only proves that more targeted solutions without the unnecessary baggage is more efficient. So you are claiming that you as a retailer benefit by using your own C++ FIX engine over any commercial one out there? LOL, you are most likely more constrained by network latency than the few microseconds you gain with your FIX adapter. If you tell me you co-locate and pay thousands in rack space fees, colo-connectivity fees, and are in the ultra-low latency game then I buy your argument otherwise it really does not make much of a difference.