Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pointers Are More Abstract Than You Might Expect in C

stefansf.de

Post reply on HN
Print view View original

251–260 of 267 posts

Re: Pointers Are More Abstract Than You Might Expect in C

#251

Post by [deleted] »

tzs wrote: post #170
clarry wrote: post #139

Earlier quoted context omitted.

> > For the purposes of these operators, a pointer to an object that is not an element of an array behaves the same as a pointer to the first element of an array of length one with the type of the object as its element type. > I don't see any way to read these as not requiring the pointers to compare as equal if the compiler happens to put a and b adjacent in memory in the right order and with no padding between them…

Then let's make them real arrays: #include #define N 8 int main(void) { int a[N], b[N]; int *p = &a[0]; int *q = &b[N]; printf("%p %p %d\n", (void *)p, (void *)q, p == q); return 0; } Results: $ gcc -std=c11 -O1 ar.c; ./a.out 0x7ffd32d048c0 0x7ffd32d048c0 0 $ gcc -std=c11 ar.c; ./a.out 0x7ffe3f8ccd60 0x7ffe3f8ccd60 1

[deleted]

Re: Pointers Are More Abstract Than You Might Expect in C

#252

Post by smolsky »

tzs wrote: post #170
clarry wrote: post #139

Earlier quoted context omitted.

> > For the purposes of these operators, a pointer to an object that is not an element of an array behaves the same as a pointer to the first element of an array of length one with the type of the object as its element type. > I don't see any way to read these as not requiring the pointers to compare as equal if the compiler happens to put a and b adjacent in memory in the right order and with no padding between them…

Then let's make them real arrays: #include #define N 8 int main(void) { int a[N], b[N]; int *p = &a[0]; int *q = &b[N]; printf("%p %p %d\n", (void *)p, (void *)q, p == q); return 0; } Results: $ gcc -std=c11 -O1 ar.c; ./a.out 0x7ffd32d048c0 0x7ffd32d048c0 0 $ gcc -std=c11 ar.c; ./a.out 0x7ffe3f8ccd60 0x7ffe3f8ccd60 1

BTW, things work correctly when the objects live inside a real array:

  #include 

  int main(void) {
    int arr[16];
    int *p = &arr[0] + 1;
    int *q = &arr[1];
    printf("pointers: %p %p %d\n", p, q, p == q);
    return 0;
  }
The result is perfectly correct and predictable, as the Standard guarantees pointer comparisons in this case:

  pointers: 0x71b35ac790d4 0x71b35ac790d4 1
The original code in the article relies on UB, I think, so all bets are off.

Re: Pointers Are More Abstract Than You Might Expect in C

#253

Post by kbenson »

pests wrote: post #119
kbenson wrote: post #103

Earlier quoted context omitted.

> faster even than hand-tuned assembly I think you and I are working off different definitions of what that means, as my definition doesn't really allow for a faster implementation (unless there's some really spooky stuff going on in the compiler). I suspect you mean faster than a popular hand tuned implementation.

I don't believe it is possible to hand tune every program to beat a compiler.

But it should be possible to hand tune to match a compiler, right? And that would mean the compiler was not faster, which is the general claim I was calling into question.

Re: Pointers Are More Abstract Than You Might Expect in C

#254

Post by jeremiep »

steveklabnik wrote: post #159
jeremiep wrote: post #143

Earlier quoted context omitted.

When you realize the compiler's optimizations only account for about 10% of the total program's performance you find that the other 90% is entirely up to the programmer. Architecture, data structures, batching operations, memory locality, and a bunch of other metrics are all concepts the compiler can't really help you with whatsoever and they have a much larger impact on performance than the 10% the compiler is actua…

Where do you get that 90/10 split from? Just curious.

Talks from Mike Acton and Scott Meyers, specifically "Data-Driven Development" and "CPU Caches and why you should care" respectively.

I forgot exactly where I got that number, but it's been a pretty good metric so far.

In a nutshell; the compiler is great a micro-optimizations and absolutely terrible at macro-optimizations. The former will get you a few percent of perf boosts while the later usually results in orders of magnitudes of performance gains.

Its near impossible to apply macro-optimizations at the end of a project without massive refactors.

Re: Pointers Are More Abstract Than You Might Expect in C

#255

Post by jeremiep »

MaxBarraclough wrote: post #226
jeremiep wrote: post #143

Earlier quoted context omitted.

When you realize the compiler's optimizations only account for about 10% of the total program's performance you find that the other 90% is entirely up to the programmer. Architecture, data structures, batching operations, memory locality, and a bunch of other metrics are all concepts the compiler can't really help you with whatsoever and they have a much larger impact on performance than the 10% the compiler is actua…

You're right to emphasise good data-structures and algorithms (also concurrency, parallelism, etc), but compiler optimisation is nothing to sneeze at. '10%' is laughably off-base. From a quick google: compiler optimisation can accelerate CPU-bound code to over 5x the unoptimised performance. https://www.phoronix.com/scan.php?page=article&item=clang-gc...

They seem to be benchmarking very specific things and not actual applications. These numbers do not hold in the real world.

Re: Pointers Are More Abstract Than You Might Expect in C

#256

Post by mpweiher »

shakna wrote: post #230
mpweiher wrote: post #78

Earlier quoted context omitted.

Yes, because the pointers are different at -O. As there are no guarantees as to the relative placement of auto/stack variables relative to each other, that is perfectly fine.

If the behaviour differs at optimisation levels, would that not suggest that it is not a sane behaviour?

Not in this case, no, not at all.

Finding a different layout for auto variable in the stack frame at different optimization levels is perfectly fine.

Re: Pointers Are More Abstract Than You Might Expect in C

#257

Post by steveklabnik »

jeremiep wrote: post #254
steveklabnik wrote: post #159

Earlier quoted context omitted.

Where do you get that 90/10 split from? Just curious.

Talks from Mike Acton and Scott Meyers, specifically "Data-Driven Development" and "CPU Caches and why you should care" respectively. I forgot exactly where I got that number, but it's been a pretty good metric so far. In a nutshell; the compiler is great a micro-optimizations and absolutely terrible at macro-optimizations. The former will get you a few percent of perf boosts while the later usually results in orders…

Cool, I'll check those out, thank you!

Re: Pointers Are More Abstract Than You Might Expect in C

#258

Post by [deleted] »

steveklabnik wrote: post #159
jeremiep wrote: post #143

Earlier quoted context omitted.

When you realize the compiler's optimizations only account for about 10% of the total program's performance you find that the other 90% is entirely up to the programmer. Architecture, data structures, batching operations, memory locality, and a bunch of other metrics are all concepts the compiler can't really help you with whatsoever and they have a much larger impact on performance than the 10% the compiler is actua…

Where do you get that 90/10 split from? Just curious.

[deleted]

Re: Pointers Are More Abstract Than You Might Expect in C

#259

Post by Narishma »

steveklabnik wrote: post #257
jeremiep wrote: post #254

Earlier quoted context omitted.

Talks from Mike Acton and Scott Meyers, specifically "Data-Driven Development" and "CPU Caches and why you should care" respectively. I forgot exactly where I got that number, but it's been a pretty good metric so far. In a nutshell; the compiler is great a micro-optimizations and absolutely terrible at macro-optimizations. The former will get you a few percent of perf boosts while the later usually results in orders…

Cool, I'll check those out, thank you!

I believe the 10/90 number may be from this talk, though I don't have time to rewatch it to confirm: https://www.youtube.com/watch?v=rX0ItVEVjHc

Re: Pointers Are More Abstract Than You Might Expect in C

#260

Post by bsder »

zubyak wrote: post #250
bsder wrote: post #231

Ummm, when I run this on gcc 7.3.0 on OS X I actually get: 0x7fff5dbd89fc 0x7fff5dbd89fc 1 Which kind of shoots the whole article in the foot ...

Did you compile it using '-std=c11 -O1' ?

No, but that just makes me assume that this is an optimization bug. Especially since -O4 actually coughs up different pointers:

  gcc-7 -std=c11 -O4 -o test test.c
  $ ./test
  0x7fff5b5f5a08 0x7fff5b5f5a10 0
The following code works as expected even with your flags and the pointers are clearly not related to one another:

  #include 
  #include 
  
  int main(void) {
      uint32_t *p = ((uint32_t *)0x7fffffffffff3eac)+1;
      uint32_t *q = (uint32_t *)0x7fffffffffff3eb0;
      printf("%p %p %d\n", (void *)p, (void *)q, p == q);
      return 0;
  }
So, I would either chalk this up to either 1) "compiler optimization bug" unless a gcc maintainer explicitly gave me a reason to believe to the contrary or 2) getting your underwear eaten by weasels because you optimized after invoking undefined behavior (attempting to probe stack layouts qualifies as undefined behavior in a big way).

My assumption would be that the compiler had to do something screwball that it got wrong because you actually asked for a pointer to a stack object that it had optimized to always be in registers.

Post reply on HN