Re:Why is this C++ code faster than my hand-written assembly...
by mark-r on Tuesday August 22, 2017 @02:19PM
(#15075062)
That was my point, I'm not expending cycles choosing between ++x and x++. I've just chosen a different default than most of the code I've seen, and you still need to realize when the default doesn't do what you want - but that's usually obvious.
Sorry to hear about your unsuccessful projects, that's a bummer. I hope that premature optimization wasn't a major part of the blame for any of them.
Re:Why is this C++ code faster than my hand-written assembly...
by ben0x539 on Tuesday August 22, 2017 @02:43PM
(#15075258)
It's so irritating that golang has x++ but not ++x. I never remember until shit isn't compiling. Grr!
Re:Why is this C++ code faster than my hand-written assembly...
by laythea on Tuesday August 22, 2017 @03:01PM
(#15075400)
This vastly differs depending on what software you write. I have done lots of necessary performance optimizations. Of course, there is a balance. To say never first optimize, is as bad as optimizing everything, in my opinion. It should require a case by case "study" of whether it is worth it. This kind of judgement comes with experience.
That might sound a little extreme, but in the past 5 years I've run into exactly 1 problem that was solved by busting out the profiler and optimizing. In that same time, I can't count on all my digits the number of features that didn't ship, estimates that were overshot, deadlines that were slipped, etc etc. I've even been part of a team that ran out of runway while popping open jsPerf to choose between !! and Boolean(). Our app was fast as hell -- too bad no one will ever get to use it.
If you're expending cycles choosing between ++x and x++ and you're not ahead of schedule, please stop.