|
JawnV6 posted:x86 branches a lot, one's expected every 3~5 instructions. Those optimizations seem more like wishful thinking than actual guidance. More of a waste of cache line resources than fetch/predict resources. It sucks for a trace cache since you can't go beyond that, but again they're limited enough that 32b shouldn't cause too much of that pressure. Yeah I guess the only real meat in that switch is cmp, je, ..., and all of the breaks would go pretty quick. I forgot that the cmp/jmps get fused. I also never considered the switch case you brought up. The first time I read that you should have only one branch per 32 bytes, I got a chuckle because, yeah, that seems like an impossible thing! When trying to implement this, I've found that it's a trade off with xchgs or how much you can amortize your branching. I think I'm just hung up on branch prediction because it seems like a tough hit. I'm trying to re-learn assembly by doing 64 bit now and processors got ... interesting. I was hoping you'd reply, your posting has taught me a few things. Edit: You're right, it's xor ecx, ecx. Also, is there a book you can recommend that focuses on AMD64? I don't wanna read about segmentation and stuff. dougdrums fucked around with this message at 17:00 on Jul 3, 2015 |
# ? Jul 3, 2015 16:49 |
|
|
# ? Jun 7, 2024 20:52 |
|
comedyblissoption posted:Mostly. But it's not just a syntactical difference. The main point is that the ternary is much safer since the ternary must evaluate to an expression. What do you mean by safer?
|
# ? Jul 3, 2015 16:57 |
|
I think he means that, if you were to write that in a non-ternary way, as the programmer you're not forced to specify what would be the default case.
|
# ? Jul 3, 2015 17:03 |
|
A chained if/else does not force assignment on all paths to a value when that is your intention. Someone could easily forget the default case in if/elses, mess up the bracing on the if/elses, forget a break in the switch statements, forget an else in the chain of if elses, etc. They could do this by adding to the existing logic. Then you're possibly left scratching your head on if they intended to omit the break/else or not. Also, it's been my experience that people really like to intermix assignment logic with other logic in the if/elses unnecessarily. comedyblissoption fucked around with this message at 17:09 on Jul 3, 2015 |
# ? Jul 3, 2015 17:05 |
|
comedyblissoption posted:In some places, it is idiomatic and not universally hated for the reasons above. Other than in bespoke artisanal C macros, I never saw it being used in any codebase.
|
# ? Jul 3, 2015 17:14 |
|
Here's an example:code:
code:
code:
|
# ? Jul 3, 2015 17:15 |
|
comedyblissoption posted:A chained if/else does not force assignment on all paths to a value when that is your intention. Honestly, this stuff are what code reviews are for. comedyblissoption posted:Also, it's been my experience that people really like to intermix assignment logic with other logic in the if/elses unnecessarily. This complaint doesn't make any sense. Sometimes you have to do other stuff besides assignments if a condition is met.
|
# ? Jul 3, 2015 17:16 |
|
HardDisk posted:Honestly, this stuff are what code reviews are for. HardDisk posted:This complaint doesn't make any sense. Sometimes you have to do other stuff besides assignments if a condition is met.
|
# ? Jul 3, 2015 17:19 |
|
comedyblissoption posted:Here's an example: The first one.
|
# ? Jul 3, 2015 17:23 |
|
HardDisk posted:The first one.
|
# ? Jul 3, 2015 17:24 |
|
Both returning null and a default value are valid paths, so you can see why I got it wrong. My biggest problem with it is that most people that use it just write garbage and think that's clever code, when it's just harder to read than a chain of if/elif/else. I can see why it's safer, and the way you indented the clauses do help making it less of a lovely syntax. But I guess it's just preference at this point.
|
# ? Jul 3, 2015 17:33 |
|
Some languages use an expression based syntax to programming. They force all ifs to have a corresponding else. They may have pattern matching. They will often have compiler flags that enforce exhausting all cases for pattern matching. These idioms very likely improve the safety of programs by forcing programmers to acknowledge all branches.
|
# ? Jul 3, 2015 17:33 |
|
HardDisk posted:Both returning null and a default value are valid paths, so you can see why I got it wrong.
|
# ? Jul 3, 2015 17:34 |
|
I feel like we're discussing code style preferences at this point, and that never ends well, when it ends. And I guess that's on me.
Space Kablooey fucked around with this message at 17:41 on Jul 3, 2015 |
# ? Jul 3, 2015 17:37 |
|
I think the crux of the issue is a preference between statement-based programming and expression-based programming.
|
# ? Jul 3, 2015 17:51 |
|
People complain about the conditional operator syntax in C but I remain happy I get to write fooficate(invert ? -x : x) instead of fooficate(-x if invert else x). Also, my eyebrows twitch a bit every time someone calls it "the ternary operator".
|
# ? Jul 3, 2015 18:16 |
|
comedyblissoption posted:Here's an example: The ternary operators here are beautiful, complete and say what they do with certainty. If someone looks at them and balks, then they need to get more familiar with the ternary operator and be a better programmer. TheBlackVegetable fucked around with this message at 18:24 on Jul 3, 2015 |
# ? Jul 3, 2015 18:21 |
Xerophyte posted:People complain about the conditional operator syntax in C but I remain happy I get to write fooficate(invert ? -x : x) instead of fooficate(-x if invert else x). Also, my eyebrows twitch a bit every time someone calls it "the ternary operator". fooficate(x * -invert)
|
|
# ? Jul 3, 2015 18:31 |
|
Xerophyte posted:Also, my eyebrows twitch a bit every time someone calls it "the ternary operator". I thought it was mostly a PHP thing to call it "the ternary operator" but reading this thread I guess this isn't true... TheBlackVegetable posted:If someone looks at them and balks, then they need to get more familiar with the ternary operator and be a better programmer. People must comply with my hipster coding preferences to be better, mmmyes...
|
# ? Jul 3, 2015 18:34 |
To add to what's been said here, IIRC there are some cases in C++ where you literally cannot use a chain of if/else and instead need to use a ternary expression. I think it's whenever you are within constexpr expression, but I might be wrong there (and I'm phone posting so it'll be a bit before I can verify).
|
|
# ? Jul 3, 2015 18:34 |
VikingofRock posted:To add to what's been said here, IIRC there are some cases in C++ where you literally cannot use a chain of if/else and instead need to use a ternary expression. I think it's whenever you are within constexpr expression, but I might be wrong there (and I'm phone posting so it'll be a bit before I can verify). Initializing references and consts are those cases, yes. Although I guess with C++11 you could use a lambda function to wrap more complex initialization logic.
|
|
# ? Jul 3, 2015 18:41 |
|
My favorite use of ternary operator: http://stackoverflow.com/questions/9101719/im-looking-for-a-free-tool-stand-alone-or-add-in-that-can-decompose-ternary-ex
|
# ? Jul 3, 2015 18:41 |
|
dougdrums posted:I think I'm just hung up on branch prediction because it seems like a tough hit. I'm trying to re-learn assembly by doing 64 bit now and processors got ... interesting. I was hoping you'd reply, your posting has taught me a few things. We once had a failure where there were 5 mispredictions. Given that information and the code snippet an architect, full chip guy, and I all gave answers for where the mispredictions were. All the answers were different. All were wrong. Don't focus on tracing one sequence, think about classes of prediction and branch type. More statistical measures. Caching is going to dominate any branching wins. dougdrums posted:Also, is there a book you can recommend that focuses on AMD64? I don't wanna read about segmentation and stuff.
|
# ? Jul 3, 2015 18:50 |
nielsm posted:Initializing references and consts are those cases, yes. Although I guess with C++11 you could use a lambda function to wrap more complex initialization logic. Ah yeah that was it. Thank you.
|
|
# ? Jul 3, 2015 19:02 |
|
Symbolic Butt posted:I thought it was mostly a PHP thing to call it "the ternary operator" but reading this thread I guess this isn't true... It's a basic feature of the language, if you can't read it at a glance (properly formatted ) you need to learn more. The if / else is also fine, but the point was it's potentially ambiguous in that case and there's a less ambiguous way to express the logic. You don't have to write the way you don't want to, but you shouldn't have any problem with someone using those operators in that way. TheBlackVegetable fucked around with this message at 19:21 on Jul 3, 2015 |
# ? Jul 3, 2015 19:16 |
|
HardDisk posted:Honestly, this stuff are what code reviews are for. Please stop rounding your probabilities to 0 or 1.
|
# ? Jul 3, 2015 19:58 |
|
nielsm posted:fooficate(x * -invert) That does something different.
|
# ? Jul 3, 2015 20:00 |
Zopotantor posted:That does something different. Yeah okay. x * (int(!!invert)*2-1) And let's assume x is a type that behaves like a normal number.
|
|
# ? Jul 3, 2015 20:13 |
nielsm posted:Yeah okay. You prefer that to what Xerophyte wrote?
|
|
# ? Jul 3, 2015 20:19 |
|
sarehu posted:Please stop rounding your probabilities to 0 or 1. Can't help it, those numbers are the only things that goes through my head.
|
# ? Jul 3, 2015 20:49 |
|
VikingofRock posted:You prefer that to what Xerophyte wrote? Some people think ternaries are the devil despite being one of the simpler operators. I personally love ?: and ??
|
# ? Jul 3, 2015 20:56 |
|
I dislike ?? because it just reminds me the language has null, the billion dollar mistake
|
# ? Jul 3, 2015 21:46 |
|
JawnV6 posted:I rest my case. Just because PHP does something doesn't automatically make it a bad choice, notwithstanding that there are a lot of bad choices in PHP. I always think that restricting case statements to literals (in languages that do that) is artificial. Seems much more natural to have code:
code:
NB. I am aware that the above doesn't take account of fallthrough/goto-case, but a switch statement using these is equivalent to the if-else version if you add gotos in the appropriate places.
|
# ? Jul 3, 2015 22:23 |
|
It's an archaic hold-over from C. Switch and break is just awful. My best guess is that switch and its attendant pitfalls were copied over into Java and C# and otherlangs to make language switching dubiously and very slightly easier. I would find it hard to believe a language designer actually thinking C-style switch is the best we can do. Also the switch on literals will likely transform to efficient jumps once it becomes assembly/bytecode and not just a nested series of if/else. The switch semantics probably intentionally guarantee this for this specific reason.
|
# ? Jul 3, 2015 22:30 |
|
Apparently in C# the compiler makes putting break at the end of a case in a switch both mandatory and explicit, so they fixed the dumb break semantics. But you need to be explicit because otherwise programmers from C or C++ backgrounds would be confused. http://stackoverflow.com/a/3109495
|
# ? Jul 3, 2015 22:35 |
|
comedyblissoption posted:Also the switch on literals will likely transform to efficient jumps once it becomes assembly/bytecode and not just a nested series of if/else. The switch semantics probably intentionally guarantee this for this specific reason. LLVM can transform switch-like if/else groups into a switch and then into jmps as well.
|
# ? Jul 3, 2015 22:37 |
|
comedyblissoption posted:Apparently in C# the compiler makes putting break at the end of a case in a switch both mandatory and explicit, so they fixed the dumb break semantics. But you need to be explicit because otherwise programmers from C or C++ backgrounds would be confused. Related to the content in that link, the answer by paxdiablo apparently originally claimed that you can use "continue" to mean explicit fallthrough, but it's pointed out in comments that this is incorrect - continue is not legal in a switch. But wait, that means (presumably) that if you have a switch statement inside a loop then you can use break and/or continue and they'll refer to different control structures - one will refer to the switch and the other to the loop. Whereas in general we'd expect break and continue to relate to the same control structure. How nasty is that? Again going on memory PHP treats continue as meaningful in a switch and defines it to have the same effect as break. I will risk being controversial and say that I think PHP made a better choice than other languages here.
|
# ? Jul 3, 2015 22:53 |
|
cond or pattern matching or case expressions would've been a lot better decision than the crippled switch, but familiarity for programmers unfortunately trumps designing the language to be better
|
# ? Jul 3, 2015 23:01 |
|
I don't have the code anymore, but the senior dev at my last job (embedded dev) had some real gems. For example he wanted to transfer an ordered list of strings to another application. So he serialized manually to XML (this is C++, so you usually have to do everything yourself, this isn't a WTF). Only this is how he did it: code:
Other times, a simple key/value collection (just a serialized struct) would be something like this: code:
code:
He was considered a genius/hero by the CEO, because of how much work he did. This is what it's like in HW companies.
|
# ? Jul 3, 2015 23:04 |
|
|
# ? Jun 7, 2024 20:52 |
|
Hammerite posted:Just because PHP does something doesn't automatically make it a bad choice, notwithstanding that there are a lot of bad choices in PHP. I always think that restricting case statements to literals (in languages that do that) is artificial. Seems much more natural to have Literally everything PHP does that differs from the mainstream is a bad choice
|
# ? Jul 3, 2015 23:17 |