There are two ways to improve performance of a given program. You either go lower level, giving more control over the execution and specifying what you want exactly, or you go higher, not constraining the execution as much, allowing for better optimizations.
For example a manual for loop will almost always be harder to optimize than a map. The latter gives explicit permission for reordering, allowing for vectorization and parallelization automatically.
Also, I would think twice before claiming FP non-ideal for PLs - modern CPUs employ just as much FPism as they are considered imperative. OOE doesn’t sound too imperative to me. And at the end of the way, imperative steps are just sequential state changes from a different perspective.
What I mean mostly are out-of-order-execution (reorder these instructions and return results as if they were executed in order - it is worthwhile because useful work can be done “in the background” while the CPU waits for memory. But this transformation is not too imperative in my opinion) and SIMD instructions (and in extension GPUs) are much more about transformations on data than a traditional Turing-machine - but there are no sharp boundaries anywhere here. It is just not smart to dismiss such a big and important part of CS, when it has plenty of applications.
For example a manual for loop will almost always be harder to optimize than a map. The latter gives explicit permission for reordering, allowing for vectorization and parallelization automatically.
Also, I would think twice before claiming FP non-ideal for PLs - modern CPUs employ just as much FPism as they are considered imperative. OOE doesn’t sound too imperative to me. And at the end of the way, imperative steps are just sequential state changes from a different perspective.