stride in slices

[DigitalDesigns]

On Tuesday, 5 June 2018 at 21:35:03 UTC, Steven Schveighoffer 
wrote:
> On 6/5/18 5:22 PM, DigitalDesigns wrote:
>> On Tuesday, 5 June 2018 at 20:07:06 UTC, Ethan wrote:
>
>>> In conclusion. The semantics you talk about are literally 
>>> some of the most basic instructions in computing; and that 
>>> escaping the confines of a for loop for a foreach loop can 
>>> let the compiler generate more efficient code than 
>>> 50-year-old compsci concepts can.
>> 
>> Ok asshat! You still don't get it! I didn't say ranges would 
>> not compile down to the same thing! Do you have trouble 
>> understanding the English language?
>
> Nope, he doesn't. Look at what you said:
>
> "Maybe in theory ranges could be more optimal than other 
> semantics but theory never equals practice. "
>
> And now you have been shown (multiple times) that in practice 
> ranges in fact outperform for loops. Including the assembly to 
> prove it (which helps with this comment: "Having some "proof" 
> that they are working well would ease my mind.")

No, you have shown a few fucking cases, why are you guys 
attacking me for being dense?

You can't prove that ranges are more optimal than direct 
semantics! Do it! I'd like to see you try!


> So tone down the attitude, you got what you *clearly* asked for 
> but seem reluctant to acknowledge. Ranges are good, for loops 
> are good too, but not as. So maybe you should just use ranges 
> and use the correct optimization flags and call it a day? Or 
> else use for loops and accept that even though they may not run 
> as quickly, they are "safer" to use since some malicious coder 
> could come along and add in sleeps inside the std.algorithm 
> functions.
>
> -Steve

What it seems is that a few of you are upset because I didn't bow 
down to your precious range semantics and ask for clarification. 
At first I was jumped on then someone did some tests and found 
out that it wasn't so rosy like everyone thought. Of course, the 
work around is to force optimizations that fix the problem when 
the problem doesn't exist in for loops. Then you come along and 
tell me that specific cases prove the general case... that is 
real dense.

You know, it takes two to have an attitude! I asked for 
information regarding stride. I got the range version, it turned 
out to be slower in some corner case for some bizarre reason. I 
was then told it required optimizations(why? That is fishy why 
the corner cause would be 200% slower for a weird edge case) and 
then I was told that ranges are always faster(which is what you 
just said because you act like one example proves everything). 
Every step of the way I am told "don't worry". You've already 
stepped in the shit once and you expect me to believe everything 
you say?

Why is it so hard to have a test suite that checks the 
performance of range constructs instead of just getting me to 
believe you? Huh? Do you really think I'm suppose to believe 
every thing any asshat says on the net just because they want me 
to? Back up your beliefs, that simple. Provide timings for all 
the range functions in various combinations and give me a worse 
case scenario compared to their equivalent hand-coded versions. 
Once you do that then I will be able to make an informed decision 
rather than doing what you really want, which is except your 
world as authority regardless of the real truth.