vyodaiken

8 ms·

31.
by vyodaiken 5y ago
I wanted to show that we don't need UB justified deletes to get good code generation. There was no need to break all that working code when we could have just told people that size_t counters worked better in loops on x86-64 than ints.
32.
by vyodaiken 5y ago
Nobody knows UB rules. The WG14 discussions are full of confusion.
33.
by vyodaiken 5y ago
Fixed it, but same kind of result https://gcc.godbolt.org/z/hx1zjE5xW
34.
by vyodaiken 5y ago
That is completely false. Look up "restrict" and there are many other contexts. BTW, "prove" and "assume" are different things. This is an old argument, which in a just world would have been settled by Dennis R
35.
by vyodaiken 5y ago
the offset is used to compute the index, not the count.
36.
by vyodaiken 5y ago
It's not an interesting optimization. Micro-benchmarks are of limited utility. The extra complication is to protect the code from flying off and writing on random memory. Well worth it.
37.
by vyodaiken 5y ago
You are being snide and inaccurate. Studies show 80% or more of GCC optimization improvements come from the core simple methods. Trying to compensate for the lack of data to support your argument by claiming (falsely) it's taught in a
38.
by vyodaiken 5y ago
Wang et al tried this an experiment and found no serious wins.
39.
by vyodaiken 5y ago
I don't know how you can say that z = x+y; if(z< x )overflowerror(); //important computation and for(i=start, i >= start && i < n; i++)docomputation(x[i]); etc.
40.
by vyodaiken 5y ago
So I create a thread with a custom stack which is an allocated buffer. At the top, I write a sequence of bytes in some order. Then I periodically read the top of the stack to see if the stack is getting close to overflow. Meanwhile, the thr
41.
by vyodaiken 5y ago
What indicates the the current semantics won't change next week? After all, it is completely up to the compiler, no?
42.
by vyodaiken 5y ago
Good question. I'd love to know. Is there any way to find out?
43.
by vyodaiken 5y ago
That article is nonsensical. Seymour Cray and colleagues and Tomasula and colleagues invented ILP, branch prediction, etc. in the 1960s before C was thought of. The PDP11 is much more similar to modern x86s than to the weird architectures o
44.
by vyodaiken 5y ago
The Chisnall article is a tutorial in incorrect Computer Architecture. PDP11s had caches by the 1970s and always had memory management. IPL was invented in the 1960s and has nothing to do with C. Branch predictors were invented in the 1960s
45.
by vyodaiken 5y ago
And switch the i to a size_t and get vector code without the possibility of writing to random memory because your int overflows and GCC wants to pretend it cannot. This is a poorly written loop. C design model is that if it is not critical,
46.
by vyodaiken 5y ago
It's not designed to overflow, and automobiles are not designed to crash, but airbags are good engineering anyways
47.
by vyodaiken 5y ago
I think the author of that blog was correct: the preferred path is for the compiler to provide data to the programmer to simplify the loop. For your godbolt example, use the C compiler not c++
48.
by vyodaiken 5y ago
in which case the overflow will cause the loop to change some random memory, but its ok since removing a single instruction test that is easy to pipeline is worth incorrect results!
49.
by vyodaiken 5y ago
link?
50.
by vyodaiken 5y ago
Exactly - it was done for meaningless benchmarking reasons. C programmers would be happy to use "restrict" as an opt-in for those, but this argument about FORTRAN goes back to the initial days of the standard when Dennis Ritchie
51.
by vyodaiken 5y ago
The compiler should have valid rules, not invalid ones.
52.
by vyodaiken 5y ago
There is not a single compelling example. Just contrived examples with dubious speedups and obvious errors.
53.
by vyodaiken 5y ago
There is zero evidence that this dichotomy is our only choice. You are also conflating two different things. Ignoring possible out of bounds pointers is perfectly fine. Deleting assignments from aliased pointers is not. Very different thin
54.
by vyodaiken 5y ago
a) the assumption is not false if it is not false! b) the speedup is not shown anywhere
55.
by vyodaiken 5y ago
Linux clone, pthreads, and os code commonly look at stack boundaries
56.
by vyodaiken 5y ago
You are advocating incorrect code that uses a few less machine operations than correct code.
57.
by vyodaiken 5y ago
Sure, if you leave out error checks code runs faster. Compile mutexes to no-ops and get an even better speedup.
58.
by vyodaiken 5y ago
Clang uses vectors for both. https://gcc.godbolt.org/z/G997Ge9KT
59.
by vyodaiken 5y ago
Leaving overflow to the processor is an example of ignoring it with unpredictable results. Deleting overflow checks because you assume, incorrectly, that overflow is impossible is not an example of ignoring with unpredictable effects, it d
60.
by vyodaiken 5y ago
There is zero customer demand for less reliable code as a tradeoff for "performance"

More ›