3 ms·

Already in his first example, where he says he doesn't use range-based for in order to help the compiler and get a charitable result, he doesn't get the point,

Already in his first example, where he says he doesn't use range-based for in order to help the compiler and get a charitable result, he doesn't get the point, I think. You write code in a certain way in order to be able to use abstractions like range-based for, or functional style. If you are hand-unrolling the loop, or using a switch statement instead of polymorphism, you loose the ability to use that abstraction. Esentially the whole point of object orientation is to enable polymorphism without having big switch statements at each call site. (That, and encapsulation, and nice method call syntax.) When people dislike object orientation, it's often because they don't get or at least don't like polymorphism. Most people, most of the time, don't have to think about stuff like cache coherency. It is way more important to think about algorithmic complexity, and correctness. And then, if you find your code is too slow, and after profiling, you can think about inlining stuff or using structs-of-arrays instead of arrays-of-structs and so on.

Jach 4y ago
Perhaps some biases can be excused by committing to C++. Using dynamic dispatch in that language seems to be slow when it's pretty much always some vtable lookups under the hood, but it doesn't have to be that way. Implementations of other languages like Smalltalk or Common Lisp automatically apply (or have as options to specify) various strategies to make convenient abstractions a lot more performant. In Java Land the JVM can do many impressive things -- and interestingly, more numbers of smaller size methods helps, as it tends to "give up" if a function is a giant sprawling mess. A fun story from https://snakeisland.com/aplhiperf.pdf https://snakeisland.com/aplhiperf.pdf on the utility of people using standard inner product / matrix multiplication operators, instead of hard-coding their own loops or whatever: > In the late 1970’s, I was manager of the APL development department at I.P. Sharp Associates Limited. A number of users of our system were concerned about the performance of the ∨.∧ inner product on large Boolean arrays in graph computations. I realized that a permuted loop order would permit vectorization of the Boolean calculations, even on a non-vector machine. David Allen implemented the algorithm and obtained a thousand-fold speedup factor on the problem. This made all Boolean matrix products immediately practical in APL, and our user (and many others) went away very happy. > What made things even better was that the work had benefit for all inner products, not just the Boolean ones. The standard +.× now ran 2.5—3 times faster than Fortran. The cost of inner products which required type conversion of the left argument ran considerably faster, because those elements were only fetched once, rather than N times. All array accesses were now stride one, which improved cache hit ratios, and so on. So, rather than merely speeding up one library subroutine, we sped up a whole family of hundreds of such routines (even those that had never been used yet!), with no more effort than would have been required for one. Or, just look at SQL. I sure appreciate not having to write explicit loops querying the correct indexes every time I want to access some data.

Jach 4y ago

Perhaps some biases can be excused by committing to C++. Using dynamic dispatch in that language seems to be slow when it's pretty much always some vtable lookups under the hood, but it doesn't have to be that way. Implementations of other languages like Smalltalk or Common Lisp automatically apply (or have as options to specify) various strategies to make convenient abstractions a lot more performant. In Java Land the JVM can do many impressive things -- and interestingly, more numbers of smaller size methods helps, as it tends to "give up" if a function is a giant sprawling mess. A fun story from https://snakeisland.com/aplhiperf.pdf https://snakeisland.com/aplhiperf.pdf on the utility of people using standard inner product / matrix multiplication operators, instead of hard-coding their own loops or whatever: > In the late 1970’s, I was manager of the APL development department at I.P. Sharp Associates Limited. A number of users of our system were concerned about the performance of the ∨.∧ inner product on large Boolean arrays in graph computations. I realized that a permuted loop order would permit vectorization of the Boolean calculations, even on a non-vector machine. David Allen implemented the algorithm and obtained a thousand-fold speedup factor on the problem. This made all Boolean matrix products immediately practical in APL, and our user (and many others) went away very happy. > What made things even better was that the work had benefit for all inner products, not just the Boolean ones. The standard +.× now ran 2.5—3 times faster than Fortran. The cost of inner products which required type conversion of the left argument ran considerably faster, because those elements were only fetched once, rather than N times. All array accesses were now stride one, which improved cache hit ratios, and so on. So, rather than merely speeding up one library subroutine, we sped up a whole family of hundreds of such routines (even those that had never been used yet!), with no more effort than would have been required for one. Or, just look at SQL. I sure appreciate not having to write explicit loops querying the correct indexes every time I want to access some data.