5 ms·

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

by 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.

by maweki 3y ago

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.