3 ms·

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 sa

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 :(
    - bayindirh 3y ago
      Then I can say that the C version for that game was designed badly from the start. You should not do that kind of mistakes when laying your foundation down. I understand your pain. I have written a material simulator in C++ which didn't use any safety barriers after the startup process, which made sure that it was safe to start the hot loop. On the other hand, my code never had a memory leak or never crashed, because I knew what I was going into and designed it appropriately. Most importantly, that thing is fast. Millions of iterations per core per second fast.

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 :(
  - bayindirh 3y ago
    Then I can say that the C version for that game was designed badly from the start. You should not do that kind of mistakes when laying your foundation down. I understand your pain. I have written a material simulator in C++ which didn't use any safety barriers after the startup process, which made sure that it was safe to start the hot loop. On the other hand, my code never had a memory leak or never crashed, because I knew what I was going into and designed it appropriately. Most importantly, that thing is fast. Millions of iterations per core per second fast.