4 ms·

You cannot just look at the cost and energy expenditure of running the program, you should also look at the development, which is a lot more expensive for C. An

You cannot just look at the cost and energy expenditure of running the program, you should also look at the development, which is a lot more expensive for C. And more importantly you should look at the opportunity cost of the programs not being written and improving the world due to the use of a less productive language.

dijit 3y ago
Programs are run more often than they are written. So while I agree that it should be considered. Please remember that the weight can be totally different depending on if it's a one-off program, a small utility that's intended for a population of 100 people- or if it's curl.
- fvdessen 3y ago
  Yes, but the small utility is used to save time, and thus energy. If it is not written because it is too expensive / complex to do it in C, then people will continue to waste energy. It is better to have the utility even if it is not perfectly implemented than not having it
  - dijit 3y ago
    That is indeed my point.
bayindirh 3y ago
Let's take a simulation code, where accuracy and precision is important, and is achievable in both C and Y (a hypothetical, more productive language). Let's say you spent a couple of months less time in Y to get the same program, but your hot core loop, which handles the iterations, runs 1-2 seconds slower in general. Let's say this loop takes 30 seconds in C, and 32 seconds in Y. You need 4000 calls of this function for a single solve. You lost 8000 seconds per solve. 2.2 hours. In every ~650 runs, you lose these two months of time you saved in development. 650 runs is a lot of runs you think. No it's not. It's a single run, fired in parallel on a 1/3rd of a 2000 node cluster, which is small in supercomputing world. These two seconds saves me 2 hours on a single run. Which means I mean I save a day in 12 runs. This means, I can run at least 650 more test cases on the same cluster. This snowballs as the research moves forward. Losing a couple months in C or FORTRAN doesn't mean much in a multi-year research project. You reap the speed benefits measured in CPU-years. This is why we still love C/C++/FORTRAN. Because they're more productive in the end.
- fvdessen 3y ago
  But in the couple of months you didn't have your better weather simulation, the rest of the world was working less efficiently because your better data was not available. This might (or might not) offset your simulation efficiency.
  - bayindirh 3y ago
    Long tail of science doesn't iterate like a startup. 48hrs to PoC, 2 months to product, 24 months to exit is not something you do. Bleeding edge science rarely works at break-neck competition. When you're competing you can iterate programs while your research is ongoing, so these two seconds doesn't lose its value either. Even if you start to churn late, you finish early, because it's like an ion drive. Small, yet constant acceleration brings you great speed on the long run. These projects generally run for years, too.
- maweki 3y ago
  By that argument, we should spend an arbitrary amount of time writing everything in very efficient assembler code, as long as we will ... after years and years of coding ... run the code often enough. It's not only about the number of answers in $timeframe, it's also about timeliness of the first answer.
  - bayindirh 3y ago
    In reality, a well optimized C code with a good compiler can really reach to the practical limits of an hardware platform. On another side note, as I noted earlier, science doesn't work like this for most of the time, unless we're going something like COVID-19. Even in these cases, you already have a good enough software base to begin with. So you iterate upon the better one while you bang the living life out of your existing solutions.
    - jerven 3y ago
      I just want to note, that reliability becomes an issue at scale as well. C can be the first to crash making it's "faster speed" useless. An example: there was a benchmark game for DNA GC counting. C was the fastest at beginning (a vectorized rust version has taken over). However, the C version in the lead at that time was the only version that could not count the GC ratio in human Chromosome X. Due to segfault/integer overflow. So in practical terms the C version was really infinitely slow even if the top ranker in the benchmark. On a person note: I am dealing with C segfault ruining 261 hours of compute, which will probably need about a 1000 or so more to debug :(
AussieWog93 3y ago
C _is_ the most productive language for certain tasks!

dijit 3y ago

Programs are run more often than they are written. So while I agree that it should be considered. Please remember that the weight can be totally different depending on if it's a one-off program, a small utility that's intended for a population of 100 people- or if it's curl.

fvdessen 3y ago
Yes, but the small utility is used to save time, and thus energy. If it is not written because it is too expensive / complex to do it in C, then people will continue to waste energy. It is better to have the utility even if it is not perfectly implemented than not having it
- dijit 3y ago
  That is indeed my point.

bayindirh 3y ago

Let's take a simulation code, where accuracy and precision is important, and is achievable in both C and Y (a hypothetical, more productive language). Let's say you spent a couple of months less time in Y to get the same program, but your hot core loop, which handles the iterations, runs 1-2 seconds slower in general. Let's say this loop takes 30 seconds in C, and 32 seconds in Y. You need 4000 calls of this function for a single solve. You lost 8000 seconds per solve. 2.2 hours. In every ~650 runs, you lose these two months of time you saved in development. 650 runs is a lot of runs you think. No it's not. It's a single run, fired in parallel on a 1/3rd of a 2000 node cluster, which is small in supercomputing world. These two seconds saves me 2 hours on a single run. Which means I mean I save a day in 12 runs. This means, I can run at least 650 more test cases on the same cluster. This snowballs as the research moves forward. Losing a couple months in C or FORTRAN doesn't mean much in a multi-year research project. You reap the speed benefits measured in CPU-years. This is why we still love C/C++/FORTRAN. Because they're more productive in the end.

fvdessen 3y ago
But in the couple of months you didn't have your better weather simulation, the rest of the world was working less efficiently because your better data was not available. This might (or might not) offset your simulation efficiency.
- bayindirh 3y ago
  Long tail of science doesn't iterate like a startup. 48hrs to PoC, 2 months to product, 24 months to exit is not something you do. Bleeding edge science rarely works at break-neck competition. When you're competing you can iterate programs while your research is ongoing, so these two seconds doesn't lose its value either. Even if you start to churn late, you finish early, because it's like an ion drive. Small, yet constant acceleration brings you great speed on the long run. These projects generally run for years, too.
maweki 3y ago
By that argument, we should spend an arbitrary amount of time writing everything in very efficient assembler code, as long as we will ... after years and years of coding ... run the code often enough. It's not only about the number of answers in $timeframe, it's also about timeliness of the first answer.
- bayindirh 3y ago
  In reality, a well optimized C code with a good compiler can really reach to the practical limits of an hardware platform. On another side note, as I noted earlier, science doesn't work like this for most of the time, unless we're going something like COVID-19. Even in these cases, you already have a good enough software base to begin with. So you iterate upon the better one while you bang the living life out of your existing solutions.
  - jerven 3y ago
    I just want to note, that reliability becomes an issue at scale as well. C can be the first to crash making it's "faster speed" useless. An example: there was a benchmark game for DNA GC counting. C was the fastest at beginning (a vectorized rust version has taken over). However, the C version in the lead at that time was the only version that could not count the GC ratio in human Chromosome X. Due to segfault/integer overflow. So in practical terms the C version was really infinitely slow even if the top ranker in the benchmark. On a person note: I am dealing with C segfault ruining 261 hours of compute, which will probably need about a 1000 or so more to debug :(

AussieWog93 3y ago

C _is_ the most productive language for certain tasks!