3 ms·

In Python numeric computing it's common for your outer loops to be for loops and your inner loops to be vectorized PyTorch/whatever. I personally like being ab

In Python numeric computing it's common for your outer loops to be for loops and your inner loops to be vectorized PyTorch/whatever. I personally like being able to easily comprehend and control what's being vectorized. Maybe it would be nice if my compiler could automatically replace any inefficient loops with vectorized equivalents, and I could think in whichever idiom came more naturally to the problem at hand. But I don't think there's anything too illogical about looping over epochs and batches, and then computing your loss function with matrices. Maybe I'm just used to a suboptimal way of doing things :)

StefanKarpinski 5y ago
> Maybe it would be nice if my compiler could automatically replace any inefficient loops with vectorized equivalents The trouble is that a for loop is much more expressive than vectorized operations, so most for loops cannot be transformed into vectorized equivalents. The reason convincing people to write vectorized code works for performance is that you're constraining what they can express to a small set of operations that you already have fast code for (written in C). Instead of relying on compiler cleverness, this approach relies on human cleverness to express complex computations with that restricted set of vectorized primitives. Which is why it can feel like such a puzzle to write vectorized code that does what you want—because it is! So even if a compiler could spot some simple patterns and vectorize them for you, it would be incredibly brittle in the sense that as soon as you change the code just a little, it would immediately fall off a massive performance cliff. I guess that's actually the second problem—the first problem is that there isn't any compiler in CPython to do this for you.