You're entitled to your opinion of course. Just for fun try implementing gauss jordan method in C# - it is prohibitively slow once you go beyond a dimension of

You're entitled to your opinion of course. Just for fun try implementing gauss jordan method in C# - it is prohibitively slow once you go beyond a dimension of 10 where you have millions of linear systems to solve. C has no problem even with much, much larger systems. As for data size - rule number one, when implementing a numerical method you always vectorise and unroll where possible. That means padding your data to a multiple that eliminates remainder loops and helps compiler exploitation of SIMD or VXA. If padding cannot be applied for a particular numerical method then use sparse or elimination methods to get the requisite multiple. In short, you control the data size, alignment and packing - the programmer determines what is best for the target platform and doesn't leave it in the hands of the run-time environment gods. In my experience there are orders of magnitude differences between C and C# when you get down to heavyweight number crunching. I implemented a simple kriging method in C# as a demo for my colleagues it took about 2 minutes for a really modest situation with handful of controls and low resolution grid. I was actually concerned that my implementation was really crap. I migrated the same algorithm over to C and it took about 5 seconds. In fairness that was about 5 years ago but makes the point. For other things like FFTs there is only a gain of about x2 migrating to the C language. But that modest change is probably due to the fact that both the C# implementation and C implementations are using native libraries for cos and sin which is typically where the bottleneck is for any DFT implementation.