I think this is absolutely not a .NET issue. .NET, properly handled, can outperform most C++ installs.
It probably runs down to bad management of the whole thing, as well as totally crap programming. Seeing MS was "involved" and having been in some projects like that - this may not necessarily mean MS was responsible. There is so damn much politics involve din proejcts like that.
GIven the quality of development and information flow I often have seen at oursources, it is likely MS did in the involvement a great job, but Accenture fed them wrong data an the whole thing was so tangled up in politics that is jut hit a wall.
One has to distribute the amount of transactions they handle per second with the amount of servers invovled and will realize this is a really low number coming out
Not saing .NET is perfect or something, but whenever I see a name like "accenture" in a project list, I personally make sure I do not get involved. Ever. Period.
Add to that some likely stupid decisions by the architect team (which most likely has no clue how an exchange works etc.) and you end up with a stupid system design that kills performance.
If the MS OS is configured with minimal overhead, not using .NET, programing to the bare metal with C++/assembler, SIMD usage, the disk formatted and aligned properly, elevating application execution to high priority and minimizing the context switching, using your desktop or server only for trading, it is possible to get a good performance from the current machines.
Except all that is useless / not needed. OS overhead is minimal. SIMD will not get you anything in clearing applications - you simply miss the problem for this. No data level parallelism in price determination, sorry. Disk alignment should also be irrelevant.... In fact, an exchange clearing application should not be disc bound or do more to a database than logging under normal operations - and keep all things in memory. High priority is another irrelevant issue. Point is - what is the sense of putting an application of high priority if NOTHING ELSE GOES ON ON THE SERVER? Yeah, you are first in the line. Oh, and the only one. And minimal context switching is not something to optimize, because, again, one application = minimum context switching.
In the end, we will never know. But there are non-trivial chances that this was either written as single threaded application running in a windows form that was never shown to the end user or it was written as managed code in stored procedures running in the database (with the "application" just calling those). Both are awkward stupid design decisions I have seen in real world projects, in both cases asked to get involved and in both cases some outsourcing team had kicked up major crap.
Exchange clearing applications are inherently simple from the interfacing (i.e. nothing utterly complicated like 3d involved). Properly tuned MS IO stacks are not bad in performance, memory is memory, CPU is CPU (and in fact, C# is not that bad performance wise). So at the end it runs down to - programming skill. And that is not exactly something companies like Accenture are known for, sadly.
)