3 ms·

Well I'm one of those idiots then. Currently, I'm employed to write very fast scientific and engineering software. We work almost entirely in C because it gives

by cd_cd 10y ago

Well I'm one of those idiots then. Currently, I'm employed to write very fast scientific and engineering software. We work almost entirely in C because it gives the performance we need (and not just because of memory management). Programming in C makes it very easy to assess what is causing performance bottlenecks as the disassembly maps tightly to the C code (typically 1:3 to 1:6 source to instruction ratio). This makes it easy to assess if the symbolic code needs changing or the compiler just isn't doing a good enough job and you may need to use intrinsics or rewrite in assembly. And I can tell you this is a massive sector employing a lot of engineers.

lmm 10y ago
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 10y ago
  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 10y ago
    > 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 10y ago
      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.

by cd_cd 10y ago

lmm 10y ago

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 10y ago
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 10y ago
  > 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 10y ago
    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.