We don't - and in this example we'd combine atomics rather than guess that the user wanted the thread to yield between them, since they never told us that.

That's not true, you are making a guess: that the user doesn't care about the intermediate stage. Not guessing would mean generating the code as specified. It doesn't matter if you think its a bad idea, the whole ethos of C is trust the programmer.

> you are making a guess: that the user doesn't care about the intermediate stage

That's not a guess - the user didn't put anything in between them so we know they haven't required them to be separate.

Keeping them separate would be making the guess - a guess that they need them to be separate. Why should we invent that constraint when the user never wrote it?

> Not guessing would mean generating the code as specified.

We are generating it as specified - nothing in the specification says atomic actions have to be run independently. Why should I invent extra constraints that don't exist in the specification?

Oh come on, that language lawyering is sophistry. If I write 4 instructions that are "atomic" I expect 4 instructions. If I end up with one, they werent really "atoms" were they? I do not expect what you just said. I may think, gee, perhaps I don't need 4 instructions, but what you are doing is undeniably changing the meaning of the program, even if you think it's close enough. The fact that there's an article about this tends to agree with me that most people think: wtf happened?

> If I write 4 instructions that are "atomic" I expect 4 instructions.

Why do you expect that? Nobody ever promised you that. If you expect something you weren’t promised then that’s on you.

> If I end up with one, they werent really "atoms" were they?

Atomic has a technical definition - it means either applied fully or not at all. That doesn’t preclude combining.

> what you are doing is undeniably changing the meaning of the program

It doesn’t! According to the spec we’re both working off. If you think the spec is wrong then change it. But I can’t guess what you want unless you tell me using the spec.

> Why do you expect that?

Because I wrote it?

> Nobody ever promised you that.

I just assumed that compiler writers had empathy for humans, my bad.

> It doesn’t! According to the spec we’re both working off. If you think the spec is wrong then change it. But I can’t guess what you want unless you tell me using the spec.

How big is the spec and how many working programmers do you think are super intimately familiar? Do you think this article would be on the front page if this information wasn't surprising? Are you building a compiler for humans, or are you just chasing metrics and getting the smug satisfaction of telling users "I told you so" when shit doesn't work in an intuitive way?

If you want to beat me over the head with "the spec says", you win, master language lawyer. I build things for a living and I like it when the code I specify is the code that's generated. You can blame users all you want, but maybe after the trillionth zero day exploit because nobody gets these things right you might consider empathy and developer ergonomics.

> I like it when the code I specify is the code that's generated

But you aren't specifying it!

You're asking me to follow extra constraints that you haven't written down and we haven't agreed. Don't you think it's unreasonable when you say it out loud like that?

If you want extra constraints on top of what is already agreed in the spec then we can do that, but you have to ask for it and you have to bring me a workable spec. You want me to 'intuit' but really you want me to read your mind and follow a lot of unwritten rules!

I think we have a fundamental difference on what a compiler should do. I want the compiler to take my exact instructions and generate the best machine code it can, that follows those exact instructions. You want to rewrite my program to be more optimal. The tension here is that, even though I'm sure you can do that, I have to debug the result, and the result I have to debug is now stripped of symbols and super hard to relate back to my original source code. So ok, I am only adding one constraint but it's a big one: don't ever change the line-by-line meaning of my source code. If I wrote a line of code I intended for it to be executed, I don't want my memsets removed or my atomics collapsed, not because you can't do it, but because I need to debug it. I don't think taking advantage of undefined behavior to create optimizations is useful because being wrong 10% faster isn't really that useful. And I think optimizations like removing memsets are a really bad idea; not only does it potentially make peoples data insecure but the only people that are ever going to find a bug like that are people looking for vulnerabilities.

And frankly, here's the thing: I don't care that much about most of your optimizations. If I'm making my code fast, what I'm fretting about is designing my data structures to fit in cache, or using SIMD instructions, or offloading work to the GPU or other coprocessors. Screwing with the meaning of my code just makes my life harder.

But the meaning of your program is not being changed or screwed with. The optimised version implements the same meaning as your original program.

The problem is you don't understand the meaning of what you've written. You think the language has extra meaning that it doesn't. You can already get the meaning you want through existing constructs like volatile and yield and memset_s.

> The problem is you don't understand the meaning of what you've written.

This is the problem with the attitude of compiler writers. Of course there are bugs. Nobody perfect. Pobodys nerfect? If I accidentally left a sign overflow in the code, or something of that nature, I think any (human) reading the code would understand what I meant, but the compiler is like "'Lets get weird!'". Yes I CAN get the meaning through the existing construct. That, however, is not my point. I am perfectly skilled and capable of doing this. What I'm questioning is why tool vendors think it's useful or practical to take advantage of users mistakes. I'd rather have a diagnostic of "why are you adding these numbers multiple times?" then have the compiler silently rewrite something I did on purpose.

I'm not writing this in the abstract, I'm writing this because things like this have hurt me in the past. It's super annoying. I don't care about your optimization to make things five percent faster if I spend three days debugging why the release build crashes if the window is full screen, but the debug build runs fine 100% of the time. The code has a bug, I own this, but I don't see how the attitude of "if your code has a bug, we will turn it into fucking dragons" is even remotely useful. Usually it's not even my code I'm fixing, it's someone elses. I just want people to stop breaking things to meet a dumb benchmark.

It sounds like you're railing against optimising based on undefined behaviour. That's a separate thing - that's not what's being discussed in this article or thread - this is all well-defined behaviour.

> I want the compiler to take my exact instructions and generate the best machine code it can, that follows those exact instructions.

Two problems.

1. Your definition of "exact" is not exact. It is exact in your mind, but it isn't going to be precisely the same across all developers and compiler authors cannot reasonably develop hard requirements from this. This is especially true when targeting different machines. Operations on a uin64_t aren't going to look the same on a 32 bit machine, for example.

2. Attempting to do this makes your programs slow as hell. You can claim that compiler optimizations don't matter... but you are free to deploy debug builds if you really think this. C and C++ especially aim to provide a sort of ambient performance where everything is fast rather than just providing speed for hot loops. People complain nearly daily about modern applications being slow and then turn around and say we should throw away decades of compiler optimizations.

I think you're severely underestimating how much slower everything would be if compilers weren't allowed to optimize anymore.

Here's where I start when I'm optimizing things:

- Does my data fit in cache

- Can I make it fit in cache?

- Have I packed my memory efficiently?

- Am I using the right algorithm?

"Can the compiler inline this" is like 5000 on my list of things I care about. Compiler optimizations are mostly only useful to people who werent paying attention in the first place.

> "Can the compiler inline this" is like 5000 on my list of things I care about. Compiler optimizations are mostly only useful to people who werent paying attention in the first place.

Okay, you're definitely severely underestimating how much slower everything would be if compilers weren't allowed to optimize anymore.

Yeah. For somebody who really cares a lot about cache misses he sure doesn't seem to be concerned about basic things like leaving virtual function calls in place.

> I build things for a living and I like it when the code I specify is the code that's generated.

Okay, then specify -O0 and enjoy your dumpster fire performance.

-O0 doesn't necessarily change this. After all, optimizations aren't allowed to violate the spec (if they do, they're buggy). So any code that can be output by an optimizing compiler could (in principle) be output by a non-optimizing compiler.

To be fair, it's usually like 5% slower. But I also don't usually have control over the flags if I'm writing a library.

I’d be curious to know what benchmarks you’re using on which O0 is only 5% slower. I suspect your program must be almost entirely IO-bound, if this is the case. In that case, Python, Ruby, or shell probably wouldn’t be much slower either.

Writing games, I've rarely seen the optimizer do anything of substantial use.

If you're going to use atomics, you should be reading what guarantees those atomics actually provide. In this case of memory_order_relaxed they pretty clearly specify they don't provide any cross-thread synchronization. So if you wrote those 4 atomics expecting something the docs explicitly & clearly say it doesn't provide, that's pretty much entirely your fault and not "language lawyering"

'atomic' isn't uncuttable in the sense that it is irreducible, but in the sense that it cannot be stopped/does not produce intermediaries. If you write four atomic instructions you should expect that they will not be interrupted, nothing more. of course I'm not an expert, but I think that is where your misunderstanding has originated.

> 'atomic' isn't uncuttable

Well then it's a pretty bad name no? Considering what the word atomic means.

Did you even read the post you're replying to. "Uncuttable" can apply to multiple properties of an instruction's execution - "atomic" colloquially refers to one of these properties.

You seem to want "atomic" to mean "the data that corresponds to the instruction cannot be divided" but it means "the execution of the instruction cannot be divided", those aren't the same thing.

The four hardest problems in computer science are cache invalidation, naming stuff, and off by one errors. Please accept that your understanding was flawed and have empathy for the people who named stuff.