I am quite interested in this point. Could you or anyone elaborate on why whole-array constructs are more difficult to optimize than loops? Is this claim applicable to other whole-array operations such as matmul
and broadcasting?
When saying loops are easier to optimize than whole-array constructs, I guess there is a hidden assumption that the loops are well written (e.g., respecting the column-major order), if not well tuned according to the hardware.
However, ideally, shouldn’t the compilers do that kind of tuning for us, as what has been happening in MATLAB since the last century? Shouldn’t the programmers focus more on the mathematics and logic of the algorithms, which are better formulated using whole-array operations? As long as the whole-array operations are not “stupidly written” (e.g., solving a linear system Ax=b
by taking the inverse of A
), shouldn’t we expect the compilers (machines) to optimize the computation for us (humans) in most cases, leaving us focusing on the more creative part of the job?
Surely, there must be someone who teaches the compilers how to optimize array operations in the first place. However, why should the programmers teach their own compilers for their own code & hardware manually in an ad-hoc fashion? Shouldn’t we let the professionals (compiler designers) do the professional thing except for rather special/rare cases? I know that it poses huge difficulties for the professionals, but isn’t this the way we make advances in science and technology in general?
Take matmul
as an example. What are the major difficulties if we want compilers to optimize it? Is there some stupidity in writing A = matmul(B, C)
so that compilers are incapable of rescuing this piece of code?
What is wrong if I claim that the following two pairs of comparisons are similar?
Explicit loops v.s. Whole-array constructs/operations
Addition by assembly code v.s. Addition by+
Sorry if my questions do not make much sense. I am not one of “the professionals” when talking about compilers, code optimization, or even programming. Thanks.