Pointers Are More Abstract Than You Might Expect in C • Hacker News Board

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

#161

Post by emodendroket » Mon, Jul 02, 2018, 6:00 PM UTC

kbenson wrote: post #135

MaxBarraclough wrote: post #115

Earlier quoted context omitted.

Obviously Zig's output (courtesy of its LLVM backend) can be expressed and distributed as assembly code, but it's not hand-tuned, it's compiler-generated. Whether the hand-tuned assembly code they used was the fastest out there, I'm not sure. I'd hope so, or they're being misleading. I might get time to re-watch the relevant part of the video - it's around the 21 minutes mark - https://youtu.be/Z4oYSByyRak?t=1292

My point is that all the fastest hand-tuned assembly has to do to match the compiled output is to do the same thing. The compiler has no ability to do anything a hand-tuned assembly cannot, by definition of how this all works. So, saying it's faster than hand-tuned assembly doesn't really make sense, but saying it's faster than current optimal hand-tuned assembly could , but that also probably requires searching for…

I mean, there's nothing a computer does playing chess that a human couldn't, and yet the world's best players simply can't beat the world's best chess-playing programs.

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

#162

Post by emodendroket » Mon, Jul 02, 2018, 6:01 PM UTC

jeremiep wrote: post #143

pests wrote: post #119

Earlier quoted context omitted.

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

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…

In a sense you're right, but hand-tuning assembly is kind of an orthogonal problem to determining whether you're using the right algorithms and data structures.

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

#163

Post by reza_n » Mon, Jul 02, 2018, 6:04 PM UTC

pjmlp wrote: post #147

reza_n wrote: post #96

Earlier quoted context omitted.

> C aficionados often claim they love C because it's "simple"(it isn't) That's what they mean, they love C because you can't really do OO with it I do not think C programmers are anti OO. Infact, a lot of C patterns are modeled on OO (struct + function). I think the appeal of C is that you are able to write the fastest implementation any given algorithm, something that just isn't possible in most other languages.

> I think the appeal of C is that you are able to write the fastest implementation any given algorithm, something that just isn't possible in most other languages. If you told this out loud during the 80's and early 90's everyone would just laugh.

True, and I meant this in the context where you could embed assembly into your functions if needed.

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

#164

Post by marcosdumay » Mon, Jul 02, 2018, 6:04 PM UTC

NeedMoreTea wrote: post #33

gilgoomesh wrote: post #25

Earlier quoted context omitted.

You don't need to use any polymorphism (generics or traits) in Rust. You can use it as a pure structs and functions language like C (especially if you're not using the standard library). The argument in favour of at least some polymorphism is that it helps to minimise highly repetitive code that would be avoided in C through aliasing, type punning or other pointer conversion.

That was the argument of C++ advocates in the 90s.

It was just recently that C++ got some underpowered kind of generics (beyond templates). So, no, I don't think anybody advocated that in the 90's.

Late 90's advocacy was much more on the lines of "OOP lets you reuse code" and "widget libraries are great, and they all but require OOP". One of those is blatantly correct.

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

#165

Post by monocasa » Mon, Jul 02, 2018, 6:08 PM UTC

xenadu02 wrote: post #154

mpweiher wrote: post #3

Earlier quoted context omitted.

> the compiler needs to optimise ... wants to. There fixed that for you ;-) The weird special cases were largely(1) introduced recently by optimizer writers hijacking the standard in order to soften the semantics so that previously illegal optimizations would now be legal, by simply declaring the vast majority of existing C code as "undefined" and up for grabs. Which is why the Linux kernel, among others, has to set…

> The weird special cases were largely(1) introduced recently by optimizer writers hijacking the standard in order to soften the semantics so that previously illegal optimizations would now be legal, by simply declaring the vast majority of existing C code as "undefined" and up for grabs. Citation needed. Signed overflow being undefined behavior was a direct consequence of different hardware representations of number…

IMO, signed overflow should be implementation defined behavior, rather than the anything goes of undefined behavior.

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

#166

Post by monocasa » Mon, Jul 02, 2018, 6:12 PM UTC

jschwartzi wrote: post #101

j16sdiz wrote: post #61

Earlier quoted context omitted.

Afaik, sparcs and many other traditional unix-running cpus does not support unaligned memory access

Technically, neither does ARM. Although you can enable emulation for unaligned accesses. One of the first things I did when setting up QNX was enabling emulation for unaligned accesses to eliminate a SIGBUS termination on some of our applications.

ARM supports it now, and with next to no perf cost.

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

#167

Post by marcosdumay » Mon, Jul 02, 2018, 6:12 PM UTC

nostalgeek wrote: post #13

gilgoomesh wrote: post #2

This scratches the surface of why I hope C slowly fades away as the default low-level language. C sounds simple when you look through K&R C. C lets you feel like you understand the stack, ALU and memory. A pointer is just an integer and I can manipulate it like an integer. But the reality is filled with a staggering number of weird special cases that exist because memory doesn't work like a simple flat address space;…

The following is purely my opinion. Rust might have gone too far the other way. Yes it strives to be a modern language, with a lot of functional programming features and "OOP" done right (aka no inheritance, simply method polymorphism). To me Rust is more a C++ replacement than a C replacement. A replacement for C should try to be as simple as possible while fixing C weak typing mess with strong typing for instance,…

> "OOP" done right

I wouldn't call the Rust semantics "OOP". But it has a pretty complete implementation of type classes, with class inheritance.

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

#168

Post by mpweiher » Mon, Jul 02, 2018, 6:15 PM UTC

xenadu02 wrote: post #154

mpweiher wrote: post #3

Earlier quoted context omitted.

> the compiler needs to optimise ... wants to. There fixed that for you ;-) The weird special cases were largely(1) introduced recently by optimizer writers hijacking the standard in order to soften the semantics so that previously illegal optimizations would now be legal, by simply declaring the vast majority of existing C code as "undefined" and up for grabs. Which is why the Linux kernel, among others, has to set…

> The weird special cases were largely(1) introduced recently by optimizer writers hijacking the standard in order to soften the semantics so that previously illegal optimizations would now be legal, by simply declaring the vast majority of existing C code as "undefined" and up for grabs. Citation needed. Signed overflow being undefined behavior was a direct consequence of different hardware representations of number…

> I keep seeing people like you claim we should just "fix" undefined behavior

Nope. Just don't take undefined behavior to mean "do arbitrary optimizations that dramatically alter the behavior of programs".

Let's see what C89 says about undefined behavior:

"3.4.3 Undefined behavior --- behavior, upon use of a nonportable or erroneous program construct, of erroneous data, or of indeterminately-valued objects, for which the Standard imposes no requirements. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message)."

Note the "permissible".

Newer versions of the standard:

"3.4.3 undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message)."

Note that the wording has change from "permissible" to "possible". To me the older version indicates that this is the range of things the compiler is allowed to do, and that range is from "do nothing" to "behaving during translation or execution in a documented manner characteristic of the environment".

I don't think "silently do arbitrary optimizations, removing arbitrary code or let demons fly out of your nose" is in the range between "nothing" and "documented behavior characteristic of the environment". And also not between that and "terminate execution".

However, the newer version says "possible", and this to me sounds a lot less like a restriction of what the compiler is allowed to do, and much more like an illustration of things the compiler could do.

And of course that is exactly what has been happening. And it is detrimental.

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

#169

Post by kbenson » Mon, Jul 02, 2018, 6:17 PM UTC

emodendroket wrote: post #161

kbenson wrote: post #135

Earlier quoted context omitted.

My point is that all the fastest hand-tuned assembly has to do to match the compiled output is to do the same thing. The compiler has no ability to do anything a hand-tuned assembly cannot, by definition of how this all works. So, saying it's faster than hand-tuned assembly doesn't really make sense, but saying it's faster than current optimal hand-tuned assembly could , but that also probably requires searching for…

I mean, there's nothing a computer does playing chess that a human couldn't, and yet the world's best players simply can't beat the world's best chess-playing programs.

This assumes that the problem of a chess game and providing optimal solutions for an algorithm defined in a higher level language (or pseudocode) are similar enough that the same strengths apply. They may be, but I don't think that's something you can assume without some sort of evidence.

Though, I guess the same could be said of my prior statements. To my knowledge, compilers aren't generally looking through a search space for optimized solutions as many common game AI algorithms do (which would would be in line with my statements about AI/ML/etc above). I don't have the relevant citations or experience to state that with authority though.

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

#170

Post by tzs » Mon, Jul 02, 2018, 6:18 PM UTC

clarry wrote: post #139

tzs wrote: post #57

Earlier quoted context omitted.

> I like the behavior of the compiler here. There is no guarantee that a and b are next to each other in memory. That's why the comparison fails, the alternative makes is runtime/compiler/optimization level dependent which would be a total mess Yes, there is no guarantee that they are next to each other, but in this case they happen to be next to each other, and according to the spec as quoted in the article, two poi…

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