Terminology's job is to help us think, and I am distinctly underwhelmed by the track record of the "concurrency vs. parallelism" terminology. It sets up an abso

Terminology's job is to help us think, and I am distinctly underwhelmed by the track record of the "concurrency vs. parallelism" terminology. It sets up an absolution distinction for something that is almost always on a gradient, and it seems to abstract away some of the most important details to concentrate on less important details. In particular, the problem itself often tends to pick whether you're "concurrent" or "parallel", which means it's not a useful metric to analyze possible solutions with since it doesn't change based on your potential solution because it doesn't provide a gradient to descend. I find it much more productive to consider "what resources do I have" vs "what resources is my code consuming". I think this focuses on the real questions, which is not "is this more about parallelism or more about concurrency?" but, do I have enough CPU cores for what I need? Am I using GPU resources? Can I use one or the other more effectively for this problem? Is this algorithm disk or RAM limited? etc. etc. In addition to simply subsuming all the considerations about "parallel vs. concurrent", this mindset raises questions like that last one that isn't even related to that question, but more directly gets at the real issues with making code run well on the real machines you have. This does provide a gradient to descend; "oh, I'm trashing memory, I can fix it with this... I can move this CPU task to the GPU... I can trade this CPU expense to reduce memory load...", etc.