Is This a Branch?
bartwronski.com
Is This a Branch?
1–10 of 78 posts
Re: Is This a Branch?
#2Another good example why premature optimization is usually counterproductive.
I really like the use of the assembly comparisons to check and prove assumptions.
Re: Is This a Branch?
#3Ifs are generally bad for readability though, because they force the reader to understand your control flow. Replacing an if with a ternary makes it more readable, not because the generated code is any different, but because a reader immediately knows that they don't need to scan through the two sides for control flow constructs (because the two sides of the ternary are guaranteed to be expressions rather than blocks). An if might occasionally be clearer than some convoluted algebra, but not often.
Re: Is This a Branch?
#4Ifs are generally bad for readability though, because they force the reader to understand your control flow. Replacing an if with a ternary makes it more readable, not because the generated code is any different, but because a reader immediately knows that they don't need to scan through the two sides for control flow constructs (because the two sides of the ternary are guaranteed to be expressions rather than blocks…
Some languages allow blocks in a ternary... ruby, for example
Re: Is This a Branch?
#5Another good example why premature optimization is usually counterproductive. I really like the use of the assembly comparisons to check and prove assumptions.
The disassembly can lie, however, i.e. the CPU can do a lot of work in the time a cache miss takes (or some other dependency induced stall, or misprediction) - you have to measure it, in the situation where the code is actually being used (i.e. contrived benchmarks will again often lie as they usually don't fill the cache, and are easy to predict)
Re: Is This a Branch?
#6Ifs are generally bad for readability though, because they force the reader to understand your control flow. Replacing an if with a ternary makes it more readable, not because the generated code is any different, but because a reader immediately knows that they don't need to scan through the two sides for control flow constructs (because the two sides of the ternary are guaranteed to be expressions rather than blocks…
Do you know if there's any evidence that ternaries beat ifs for people understanding code in practice or in people's self-assessments? Would not have been my guess at all.
Re: Is This a Branch?
#7Ifs are generally bad for readability though, because they force the reader to understand your control flow. Replacing an if with a ternary makes it more readable, not because the generated code is any different, but because a reader immediately knows that they don't need to scan through the two sides for control flow constructs (because the two sides of the ternary are guaranteed to be expressions rather than blocks…
I have been reading HN for a long time but your comment is the first time I violently felt the need to create an account and respond. I want you to consider how significant that is. Ternaries are NEVER easier to read.
Re: Is This a Branch?
#8Another good example why premature optimization is usually counterproductive. I really like the use of the assembly comparisons to check and prove assumptions.
The disassembly can lie, however, i.e. the CPU can do a lot of work in the time a cache miss takes (or some other dependency induced stall, or misprediction) - you have to measure it, in the situation where the code is actually being used (i.e. contrived benchmarks will again often lie as they usually don't fill the cache, and are easy to predict)
Yeah, I was actually wondering if maybe gcc did that second one with floats on purpose because of profiling data that they have.
Re: Is This a Branch?
#9Ifs are generally bad for readability though, because they force the reader to understand your control flow. Replacing an if with a ternary makes it more readable, not because the generated code is any different, but because a reader immediately knows that they don't need to scan through the two sides for control flow constructs (because the two sides of the ternary are guaranteed to be expressions rather than blocks…
The ternary and unary increment/decrement operators are things I thought I’d miss, but in fact absolutely do not miss. May they forever perish. If-as-expression always!
Re: Is This a Branch?
#10Ifs are generally bad for readability though, because they force the reader to understand your control flow. Replacing an if with a ternary makes it more readable, not because the generated code is any different, but because a reader immediately knows that they don't need to scan through the two sides for control flow constructs (because the two sides of the ternary are guaranteed to be expressions rather than blocks…
Do you know if there's any evidence that ternaries beat ifs for people understanding code in practice or in people's self-assessments? Would not have been my guess at all.
An anecdotal data point: I prefer ternaries unless the if statement is for control flow. They're terser and don't stick out as much in the code.