After several embarrassing outages, LSE dumped their Windows/.NET infrastructure for a Linux/C++ based one and CTO Robin Paine 'resigned' back in 2010. Would be very interested to hear Robin's take on this. Arguing that a microsoft OS and .NET can handle high transaction volumes at real time better than Linux/C++ is absurd.
Of course. It's just asking for problems to write stock exchange code for Windows. Not only because its TCP/IP layer is at least 3x slower, but also because you never know when your latency critical code is being executed and it can easily take 3000x more latency than a realtime OS like Redhat MRG
we use both c++ and .net in tradelink. for many components of the librarys near identical code/algos are used across languages. in bechmarks of applications constructed side by side in both languages, we've been surprised to see c# code outperform c++, significantly in some instances. other times c++ would win significantly, or they would be near approximate. it's highly dependent on the task being performed and specifics of the implementation. thankfully we have more than one choice so we can choose the tools best suited to a given task.
if you're latency is less than 0.001ms then think about re-coding in ASM.. the loop written by a bad language running 1000 times would take 1micro second to execute or less on an average hardware... do the math!
I quickly read this long thread, don't know whether I'm repeating points from someone else. When programming complex systems like nowadays computers,you never know the outcome of a particular way of programming until you test. And testing shows that often, ways that look cumbersome produce the fastest results. This totally supercedes the language you are using. So, though I believe that C# wastes machine resources, it can have parts correctly optimized which outperform standard C++. Let me give you an example. Some years ago I read a study from AMD where they tried to do a simple task, copying memory, as fast as possible. They were just using Assembly. They began with standard REP MOVSD and compared results with memory bandwidth: speed was much lower,so went on experimenting. Any x86 programmer knows that REP MOVSD sucks a lot and is there for compatibility only.So he would think that using MOV, some jump instructions, and a bit of loop unrolling, interleaving instructions so that the superscalar pipe doesn't stall, would solve the problem. That's what the study tried. And it improved the results, which remained far from the bandwidth limit. To cut a long story short, they ended up examining the cache structure, and adding a loop - before the actual copy - which read a word from each cache line IN REVERSE ORDER to fill up the cache, using some specific AMD instructions (MFENCE, I believe). This complicated program would nearly reach memory bandwidth. Had someone written all that stuff in C (or even maybe C#), would have outperformed a straightforward ASM loop with MOV instructions,loop unrolling,instruction interleaving. Yet I still use ASM in my Visual Basic 6 software, and get improvements in speed, which are quite useful for reducing order submission latency and dealing with many symbols data in fast markets, even on old hardware.
It's good to know someone out there is using ASM. As for your example, I agree, we (or actually I) completely forget sometimes that people who build compilers have entire dedicated teams for each of the simple functions, one of which is the one you mentioned with copying memory. A lot of these standardized tasks are handled superbly by C++ and are often faster than a straight forward ASM code, but, certain loops and complex conditionals get bugged up and slowed down with C++ compilers, so that's the only case I'd say ASM can be useful, and only if it's critical, ie your latency issue is a matter of nano-seconds just because of that little part. So the whole practice of trying to do ASM ends up being a fun experiment more than a truly useful functionality, in most cases. In your case however, coding in anything other than VB6 would be faster (except in a few special cases).
My point is that performance depends on efficiency of "predefined blocks" like memory copy and other system tasks like GUI interface. When you talk about the use of "raw" language, VB6 is really not bad, I decompiled some code and it was better than I thought. Doesn't compare with Intel C++ commercial version of course, but it's more than enough for normal,common tasks. Then, when I need speed, I switch to ASM (for example, parsing of the stream I receive from my broker is mostly done in ASM). I use system API a lot with libraries and not "Declare"s, sometimes replacing VB6 .ocx like the one for CommonControls. My ListViews are generated with calls to user32.dll. These tricks help also reduce memory consumption,which in turn speeds up the whole system. My trading software, which includes charts and DOM trading, runs smoothly on a Duron 900Mhz and takes not more than 12MB. Still way too much for me, but try and see a commercial one... This way of programming doesn't relate to a particular language, and speeds up things a lot. The point is that you have to know your system and identify the critical parts to optimize them; language is just one part.
.NET is highly optimized after, what, 10 years... And code designed for speed by a competent engineer will match almost anything... And be infinitely cheaper to maintain... Which is a huge advantage when Algo Engineers are way up there in 6 figure land. And "optimizing" means managing the threading of your app... Not letting Windows merge you pr0n surfing with you Algorithmic Trading. Basically, whole idea that Lone Wolf coders can compete with banks, ECNs, hedge funds, etc... Is Are-You-On-Drugs-Space-Cadet territory. The only game small firms can realistically play... Is Medium Frequency Trading with decent latency done as cheaply as possible.