7 ms·

It's just one line. Put this before the loop if the code logically shouldn't trigger this. assert( B < B_TYPE_MAX - 4 ); Or use an if statement if it could

by dsfuoi 10y ago

It's just one line. Put this before the loop if the code logically shouldn't trigger this. assert( B < B_TYPE_MAX - 4 ); Or use an if statement if it could trigger at runtime. Also the code is clearer on intent.

pcwalton 10y ago
You misunderstood the problem. The problem isn't that programmers can't write loops that are easy to optimize. It's rather that, in practice, they don't write loops that are easy to optimize. That's ultimately a problem with the C language.
- dsfuoi 10y ago
  If the loops can be written and the programmers don't write them, the problem is with the language!? No, it's pretty clear where the problem is with C, programmers.
  - pcwalton 10y ago
    The easiest way to write the loop is the way that is hard to optimize. This is a fact that is beyond dispute: empirically, programmers use int to index over arrays in for loops without writing asserts. That is in fact a problem with the language.
    - dsfuoi 10y ago
      programmers use int to index over arrays in for loops without writing asserts. That is in fact a problem with the language. Ok let me get this clear, you're saying that the language is at fault because the programmers don't write correct code. I have no words.
      - deleted 10y ago
        [deleted]
      - stouset 10y ago
        Emphatically yes. When designing tools for use by humans, you need to accept the fact that humans, with all our failings, will be the ones using the tools. So tools should be made resilient against typical ways in which humans fail. We've been paying for shortcomings in C's design for decades with bugs and security failures that simply don't happen in other languages. That you refuse to see this is baffling to me.
      - pcwalton 10y ago
        > Ok let me get this clear, you're saying that the language is at fault because the programmers don't write correct code. Yes. A good language makes the correct thing the easy thing.
      - rdc12 10y ago
        When a common idiom becomes the wrong way to do something, someone messed up pretty badly (and preexisting idiom at that). Arguably the designers of amd64 should have caught this before releasing the ABI or the language design could have been specified so this wasn't an issue in the first place.
haberman 10y ago
Can assert() actually function this way? Can you use assert to tell the optimizer it can assume something is true? I've noticed that memcpy(x, y, 4) on x86 can generate very efficient code (register move), but on ARM it expands to something much more verbose because the addresses might not be aligned. Could this effectively function as a way of promising to the compiler that the addresses are aligned? void move4_aligned(void *dst, const void *src) { assert(((uintptr_t)dst & 0x3) == 0); assert(((uintptr_t)src & 0x3) == 0); memcpy(dst, src, 4); }
- nkurz 10y ago
  Can assert() actually function this way? Can you use assert to tell the optimizer it can assume something is true? Yes, but it would have the potentially surprising behavior that compiling your release version with -DNDEBUG might slow it down. We ran into this a couple years ago: https://plus.google.com/+DanielLemirePhD/posts/BTSams19Ero https://plus.google.com/+DanielLemirePhD/posts/BTSams19Ero Recent compilers support some extensions that can do it better. GCC and CLang use __builtin_assume_aligned(), and ICC uses __assume_aligned() (haven't tested the synonym).
- quotemstr 10y ago
  > Can assert() actually function this way? Can you use assert to tell the optimizer it can assume something is true? Trivially. #ifdef NDEBUG # define assert_and_assume(cond) if(!(cond)) __builtin_unreachable((cond)) #else # define assert_and_assume assert #endif
  - haberman 10y ago
    Interesting! This assert_and_assume() seems strictly better than vanilla assert() for any predicates that don't have side effects. But I guess you have to be sure that the compiler is able to deduce that there aren't side effects and feels comfortable optimizing away the predicate in release mode.

by dsfuoi 10y ago

pcwalton 10y ago

You misunderstood the problem. The problem isn't that programmers can't write loops that are easy to optimize. It's rather that, in practice, they don't write loops that are easy to optimize. That's ultimately a problem with the C language.

dsfuoi 10y ago
If the loops can be written and the programmers don't write them, the problem is with the language!? No, it's pretty clear where the problem is with C, programmers.
- pcwalton 10y ago
  The easiest way to write the loop is the way that is hard to optimize. This is a fact that is beyond dispute: empirically, programmers use int to index over arrays in for loops without writing asserts. That is in fact a problem with the language.
  - dsfuoi 10y ago
    programmers use int to index over arrays in for loops without writing asserts. That is in fact a problem with the language. Ok let me get this clear, you're saying that the language is at fault because the programmers don't write correct code. I have no words.
    - deleted 10y ago
      [deleted]
    - stouset 10y ago
      Emphatically yes. When designing tools for use by humans, you need to accept the fact that humans, with all our failings, will be the ones using the tools. So tools should be made resilient against typical ways in which humans fail. We've been paying for shortcomings in C's design for decades with bugs and security failures that simply don't happen in other languages. That you refuse to see this is baffling to me.
    - pcwalton 10y ago
      > Ok let me get this clear, you're saying that the language is at fault because the programmers don't write correct code. Yes. A good language makes the correct thing the easy thing.
    - rdc12 10y ago
      When a common idiom becomes the wrong way to do something, someone messed up pretty badly (and preexisting idiom at that). Arguably the designers of amd64 should have caught this before releasing the ABI or the language design could have been specified so this wasn't an issue in the first place.

haberman 10y ago

Can assert() actually function this way? Can you use assert to tell the optimizer it can assume something is true? I've noticed that memcpy(x, y, 4) on x86 can generate very efficient code (register move), but on ARM it expands to something much more verbose because the addresses might not be aligned. Could this effectively function as a way of promising to the compiler that the addresses are aligned? void move4_aligned(void *dst, const void *src) { assert(((uintptr_t)dst & 0x3) == 0); assert(((uintptr_t)src & 0x3) == 0); memcpy(dst, src, 4); }

nkurz 10y ago
Can assert() actually function this way? Can you use assert to tell the optimizer it can assume something is true? Yes, but it would have the potentially surprising behavior that compiling your release version with -DNDEBUG might slow it down. We ran into this a couple years ago: https://plus.google.com/+DanielLemirePhD/posts/BTSams19Ero https://plus.google.com/+DanielLemirePhD/posts/BTSams19Ero Recent compilers support some extensions that can do it better. GCC and CLang use __builtin_assume_aligned(), and ICC uses __assume_aligned() (haven't tested the synonym).
quotemstr 10y ago
> Can assert() actually function this way? Can you use assert to tell the optimizer it can assume something is true? Trivially. #ifdef NDEBUG # define assert_and_assume(cond) if(!(cond)) __builtin_unreachable((cond)) #else # define assert_and_assume assert #endif
- haberman 10y ago
  Interesting! This assert_and_assume() seems strictly better than vanilla assert() for any predicates that don't have side effects. But I guess you have to be sure that the compiler is able to deduce that there aren't side effects and feels comfortable optimizing away the predicate in release mode.