>You have two matrices, with allocated memory A and B, that you want to multiply and store to allocated memory C, as efficiently as possible

If matrices are small, 1 core would be more efficient. If matrices are big, GPU would be more efficient.

Vector instructions or GPGPU.

Assume no GPU. Vector instructions will only use one core at a time.

We are in 2019, even low level microcontrollers have dumbed down GPUs.

Plus I already answered your questions, not moving goal posts here.

I wanted an efficient no threads solution to a very common problem of matrix multiplication using multiprocessor CPUs. You gave me nonsense answers like vector operations (uses only one CPU at a time) and GPUs (memory transfer bottleneck, need to copy arrays, significantly less RAM compared to CPU RAM, and GPUs make it a completely different game). So no, I'm not moving goalposts.

You did not define what efficient means.

For example, a SIMD implementation will outperform a multithreaded implementation on a CPU without support for hardware threads.

My nonsense answer just happens to be what HPC is moving into, and when HPC wants to scale it uses MPI coupled GPUs, not plain old threads.

And will spend more time shuffling data through their horribly bottle-necked memory interfaces than the CPU would take handling the matrix operation, especially if the GPU is already used for graphics.

Multi-core systems and tools that can use them are valuable and very much reality right now.

Yep, CUDA and Vulkan Compute are such a waste in HPC, thankfully ML research is doubling down on threads.

You were the one who introduced GPUs on low-end embedded chips as an argument. HPC is a slightly different world.

Nah, you are the one that moved the goal posts after my first answer.

That was my first reply to you today...

As much as I often appreciate your no-nonsense perspective on things and you posting it, things like this don't really do you a favor.

EDIT: tweaked last line to be a bit less snippy

I don't always look at nicks.