How could a compiler break the lockless hashing method?

[mvk]

BTW still looks like intel is 30x more sales overall. Based on their total sales by quarter.

The x86 design, especially combined with Intel's manufacturing process, has high margins. Interestingly, Intel will use their new 14nm process also for 64-bit quad core ARM manufacturing from beginning next year. This will eat from their capacity for producing x86 designs, but clearly they expect to be better off anyway. And they are already manufacturing ARM processors on the earlier nodes. I would not be surprised if one of the next macbook pro generations will become fully ARM-based. Not sure what to think of that, chesswise.

[hgm]

But all I get back is "but it is undefined behavior according to the standard."

Well, this discussion can of course never come to a conclusion, because there are two camps that argue from different underlying axioms. On the one side there are people that take it for granted that

"Standards are there to be complied with"

while on the other side we have

"Evil standards are there to be fought and overturned"

[rbarreira]

But all I get back is "but it is undefined behavior according to the standard."

Well, this discussion can of course never come to a conclusion, because there are two camps that argue from different underlying axioms. On the one side there are people that take it for granted that

"Standards are there to be complied with"

while on the other side we have

"Evil standards are there to be fought and overturned"

I didn't see anyone fighting or trying to overturn any standard. Just whining about things that have been in the standard for decades.

But I do see Bob getting backed into a corner of ridiculousness (see his last reply to me as an example... pretty soon he'll start demanding that compilers implement strong AI in order to discern Bob's intention with the code).

[wgarvin]

But all I get back is "but it is undefined behavior according to the standard."

Well, this discussion can of course never come to a conclusion, because there are two camps that argue from different underlying axioms. On the one side there are people that take it for granted that

"Standards are there to be complied with"

while on the other side we have

"Evil standards are there to be fought and overturned"

Actually, I would characterize the second side more as "Muahahaha!! I reject your reality and substitute my own!!"

But sure, if you want to fight the evil standards, go tell the standards committee they should do something about this stuff. Tell the compiler developers you won't buy their products unless they be more careful. Other groups are doing those things, and maybe it will do some good.

But in the meantime, its a good idea to just be careful and avoid UB wherever possible. But if you don't write code for any safety-critical or security-conscious applications, then its probably fine to just keep doing whatever you usually do and not worry about it too much. If you aren't currently encountering weird UB-related behaviors in your compiled code, then you can cross your fingers and hope that state of affairs persists for several more years, and all else being equal, it "probably" will. A large fraction of programmers, perhaps even the majority of them, don't seem to have any conscious awareness of UB with all its weird subtleties, and yet they are still able to write working or mostly-working programs and get by. Even though a fraction of those programs contain UB time-bombs, maybe the standards committee will be able to defuse some of those cases by just standardizing whatever current compilers have tended to do at -O2 or something like that.

[bob]

BTW still looks like intel is 30x more sales overall. Based on their total sales by quarter.

The x86 design, especially combined with Intel's manufacturing process, has high margins. Interestingly, Intel will use their new 14nm process also for 64-bit quad core ARM manufacturing from beginning next year. This will eat from their capacity for producing x86 designs, but clearly they expect to be better off anyway. And they are already manufacturing ARM processors on the earlier nodes. I would not be surprised if one of the next macbook pro generations will become fully ARM-based. Not sure what to think of that, chesswise.

I would hope not, myself. The i7's make really fast boxes...

[bob]

But all I get back is "but it is undefined behavior according to the standard."

Well, this discussion can of course never come to a conclusion, because there are two camps that argue from different underlying axioms. On the one side there are people that take it for granted that

"Standards are there to be complied with"

while on the other side we have

"Evil standards are there to be fought and overturned"

I didn't see anyone fighting or trying to overturn any standard. Just whining about things that have been in the standard for decades.

But I do see Bob getting backed into a corner of ridiculousness (see his last reply to me as an example... pretty soon he'll start demanding that compilers implement strong AI in order to discern Bob's intention with the code).

No. You just refuse to read. Use the best math available on the cpu, and let overflow happen when it must. The a * b / c is NOT an inconsistent argument. A reasonable assumption is to think "the operations should be computed as given. If the final result overflows, fine. If not, even better.

That is not a "ridiculousness" post, nor does it require any AI whatever. It just requires an absence of "artificial stupidity" which is what you get if you get different answers based on different levels of optimization. And yes, I know that is perfectly plausible in the case of undefined variables. But a compiler can detect most of those and produce a warning. It is the undefined behavior optimizations that are a problem.

[bob]

But all I get back is "but it is undefined behavior according to the standard."

Well, this discussion can of course never come to a conclusion, because there are two camps that argue from different underlying axioms. On the one side there are people that take it for granted that

"Standards are there to be complied with"

while on the other side we have

"Evil standards are there to be fought and overturned"

Actually, I would characterize the second side more as "Muahahaha!! I reject your reality and substitute my own!!"

But sure, if you want to fight the evil standards, go tell the standards committee they should do something about this stuff. Tell the compiler developers you won't buy their products unless they be more careful. Other groups are doing those things, and maybe it will do some good.

But in the meantime, its a good idea to just be careful and avoid UB wherever possible. But if you don't write code for any safety-critical or security-conscious applications, then its probably fine to just keep doing whatever you usually do and not worry about it too much. If you aren't currently encountering weird UB-related behaviors in your compiled code, then you can cross your fingers and hope that state of affairs persists for several more years, and all else being equal, it "probably" will. A large fraction of programmers, perhaps even the majority of them, don't seem to have any conscious awareness of UB with all its weird subtleties, and yet they are still able to write working or mostly-working programs and get by. Even though a fraction of those programs contain UB time-bombs, maybe the standards committee will be able to defuse some of those cases by just standardizing whatever current compilers have tended to do at -O2 or something like that.

I will ask again, how can you avoid writing potential UB code if you do things like this:

a = b + c;

???

It can overflow. Do YOU test every add before-hand to see if, for example, MAXINT - C > B? Nobody writes code like that. But if, suddenly, the compiler can see that B is quite large, it is apparently free to just delete that statement period since it will produce UB. Or it can make the program abort. Or anything else it might dream up.

So "avoiding UB" is not exactly a trivial exercise. Better if the compiler just does the right thing and moves on, without trying to guess whether something will overflow or not and do some tricky optimization assuming it will not happen, and then blaming the programmer when the program hangs due to the optimization, caused by UB that the original programmer did not predict.

It is easy to say "just don't do it." But I'll bet you have done it thousands of times without even thinking about it. We all know the limits of 32 bit or 64 bit integer math. If we step over them, we step over them. It is not a hanging offense.

[bob]

Sorry you feel that way. I simply have my opinion, developed over several years of compiler development.

Objection, facts not in evidence. Please show us which conforming C compiler you actually developed? Or any other compiler that was used by anyone except yourself, your students or coworkers.

Didn't write a C compiler. Did work on a FORTRAN compiler for a long time that was used in production on TI supercomputers. Did work on a basic compiler (not interpreter) that was used in production for several years both within academic labs and outside. I also wrote a (puke) Pascal compiler that was used for students to write assignments in for many years. Was not available on the machine we were using (A Xerox box) at the time. That enough?

Pick up a good compiler book. One of the classic tests for optimizers is to produce the exact same results as the unoptimized code. C does not meet that standard. It did in the past.

When exactly did C meet that standard? Give me a compiler that has a working optimizer and I can easily make programs that give different results based on the optimization level.

Most older gcc's, for example. Feel free to try. But the program MUST work correctly with no optimization, and not be based on intentional bad programming such as not defining a value before it is used...

[rbarreira]

No. You just refuse to read. Use the best math available on the cpu, and let overflow happen when it must.

But that is exactly what the compilers try to do. They use the "best math" (in which best is usually dictated by performance and not some irrelevant notion of "best" which can still give different results depending on the hardware).

[Rein Halbersma]

2 billion CPUs in 3 months is not enough for you?

http://news.softpedia.com/news/ARM-Reco ... 6252.shtml

OK, my mistake.

"Just as I thought I was out, they pull me back in."
Mods, please make that post sticky! That single utterance alone was worth the price of admission.