[lmm]

I mean, what do you want me to say? Yes, judging by what you've said and without knowing the details of your requirements, I think it's most likely you (and your organization) are among the idiots. I've worked in that sector, replacing that kind of code with higher-level code in a "slow" language that somehow managed to run orders of magnitude faster, because when you're in the trees of disassembly and intrinsics it's all too easy to miss the forest of using the wrong algorithm or even making a calculation that just isn't necessary. Even in the cases where you don't make that kind of mistake, you can fix a problem with generated assembly as many times as you like and it will all be worthless compared to fixing the problem in the compiler once and for all.

There is good, valuable work being done in that world, don't get me wrong, and it's entirely possible you're on that side of things - but it's very much the exception rather than the rule IME.

[cd_cd]

Well if you use a poor implementation or the wrong algorithm then you're going to get poorer performance in any language. However, all things being equal, you're not going to get better performance from a higher level language and you certainly cannot fine tune the implementation for a particular platform as you can with lower level code - that's a fact. Now whether it is worthwhile doing that depends on each case and how long the process takes to execute. I often prototype in higher level languages including R, Python and C#. Once I need a professional implementation or put them into commercial software I use C even if the front end is written in C#. C is just orders of magnitude faster than C#, even when the C# multithreaded, is coded in unsafe mode and optimised and C is single threaded and compiled with no optimisation.

[lmm]

> all things being equal, you're not going to get better performance from a higher level language

Not remotely true if one of those things being equal is programmer time/effort, IME.

> you certainly cannot fine tune the implementation for a particular platform as you can with lower level code

Compilers can and do. JIT can allow even better tuning than is possible in C, as it can take the input data into account.

> C is just orders of magnitude faster than C#, even when the C# multithreaded, is coded in unsafe mode and optimised and C is single threaded and compiled with no optimisation.

Not remotely supported by any benchmark I've ever seen. The latest techempower benchmarks show a factor of 1.3x-7x difference between C and C# depending on the benchmark; the shootout is similar as far as I can tell from the unhelpful website. Not even a single order of magnitude, much less orders plural. (And benchmarks are the best possible case for C: tiny pieces of code where you can do a level of manual tuning that would be completely unreasonable to do on realistic-sized programs).

[cd_cd]

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.

[lmm]

We're both entitled to our opinions, but I've mentioned a couple of specific public (published) benchmarks for mine - do you have anything like that for yours?

[cd_cd]

Links would be good. And on that...

Could you provide a link to heavy numerical operations - btw, ones that use native libraries don't count cause it ain't the C# implementation doing the work? As I've said there are some routines where C# performs fine but for heavy-weight modelling requiring intense arithmetic matrix/vector operations it is just too slow. What's more the benchmark for a single run does not always scale to many. The overhead becomes compounded when you're doing the same operation over and over again due to GC and cache misses.

http://www.sebastiansylvan.com/post/why-most-high-level-lang...

I love C#, I think it is a great language but it just doesn't belong at the level where I NEED to code at.

https://msdn.microsoft.com/en-us/library/ms973852.aspx

C is a pain in the ass to do the things that C# is good at. If it works for you across the board then fine but I would stop assuming everyone else is an idiot.