Optimization by accepting side effects

Re:Optimization by accepting side effects by 3JPLW on Monday October 28, 2013 @02:10PM (#6628641)

Another class of these optimizations that are even harder (for me) to spot exploit matrix decompositions, multiplications, etc. If you can manage to convert your problem into some linear algebra system, a fast BLAS can do wonders. And then selectively using some BLAS result (that has side-effects as the article defines them) is even harder.

Unfortunately, it's often just as hard to distinguish such code from magic when reading it.

[ Parent | on HN ]

Re:Optimization by accepting side effects by gms on Monday October 28, 2013 @02:41PM (#6628885)

It's a rule of thumb that the more optimised your code is, the less readable it is.

[ Parent | on HN ]

Re:Optimization by accepting side effects by mildtrepidation on Monday October 28, 2013 @04:37PM (#6629613)

I think this is a poor generalization. It's only valid if you assume that you can only ever do things in languages that do not have idiomatic features or implementations well-suited to the task at hand.

Is a well-structured and readable (to a C programmer) program written in C less readable than a more verbose and DSL-laden program written in Ruby or a purely functional (whether that's relevant to the solution or not) program written in Common Lisp to solve the same problem? It might be... depending on your background and how well those tools fit the problem.

"Optimization" doesn't have to start after the product is working. Choosing a platform that supports your requirements from the start, if that's an option you have, has the potential to significantly mitigate what we'd traditionally call optimization in the sense of "we built it, holy crap, now how do we scale it?"

[ Parent | on HN ]

Re:Optimization by accepting side effects by mistercow on Monday October 28, 2013 @05:23PM (#6629918)

The statement "more optimized = less readable" isn't true across the entire curve. But it is generally pretty accurate at the limit. Maybe not for every problem, but for the majority of problems. No language can be expressive for anything but a tiny slice of the space of effective optimizations.

[ Parent | on HN ]

Re:Optimization by accepting side effects by dllthomas on Monday October 28, 2013 @05:06PM (#6629788)

I think there was a clear "ceteris paribus" implicit in the parent.

[ Parent | on HN ]

Re:Optimization by accepting side effects by baddox on Monday October 28, 2013 @06:29PM (#6630289)

You can at least try to hide ugly optimizations in subroutines while keeping the subroutines' "contracts" clear.

[ Parent | on HN ]

Re:Optimization by accepting side effects by mistercow on Monday October 28, 2013 @06:51PM (#6630389)

It's actually kind of a nice thing about optimizations that are non-portable, because the fallback implementation can act as an explanation of what the code does. Clearly commenting optimized code is a difficult art.

[ Parent | on HN ]