"I will never know exactly how a microprocessor works - but that doesn't impede my programming skills"
Yesitdoes.
To pick just a single example: if you don't understand how your CPUs cache architecture works, and how it interacts with hardware paging (and ultimately swapping), you aren't qualified to do performance analysis atall. But you will anyway, and you will get it wrong, and you will forever be wondering why your MySQL database doesn't scale properly. Or why adding a bunch of RAM to the box didn't work the way you expected. Or you'll write dumb "optimized" code with local copies of things that could be computed, and fail to understand the benchmarks showing why it doesn't work.
As a programmer, you are a user of a tool. If you want to be an effective user of that tool, you need to have some understanding of how it works. No, you don't need to be a fully trained ASIC design architect, or semiconductor process engineer, or solid state physicist. But yes: you should understand how a circuit works, and what the parts of your computer are, and how they interact.
And your statement that "specialists" can get by without knowing "a little about a lot" just confuses me. Every talented "specialist" I've ever known has an encyclopedic knowlege of all sorts of things outside their specialty. A better word for a "specialist" that only knows their specialty is probably just "worker", or "lackey".
You can only really get the lowhanging fruit that way. There are so many different methods of optimization that you have to know where to start. You have to have a good model of the underlying system. Otherwise you won't understand why boxed integers are inherently slow. Or why an array of tuples can be much slower than a tuple of arrays.
Modern languages completely abstract from fundamental things like indirection. Consequently, it becomes almost impossible to accurately estimate the performance of algorithms in high level programming languages.
Waiting for people with experience optimizing prolog programs to disagree with me...
Sure, you can analyze, but there are cases where you will not be able to do much about your findings without an understanding of computer architecture.
Yes it does.
To pick just a single example: if you don't understand how your CPUs cache architecture works, and how it interacts with hardware paging (and ultimately swapping), you aren't qualified to do performance analysis at all. But you will anyway, and you will get it wrong, and you will forever be wondering why your MySQL database doesn't scale properly. Or why adding a bunch of RAM to the box didn't work the way you expected. Or you'll write dumb "optimized" code with local copies of things that could be computed, and fail to understand the benchmarks showing why it doesn't work.
As a programmer, you are a user of a tool. If you want to be an effective user of that tool, you need to have some understanding of how it works. No, you don't need to be a fully trained ASIC design architect, or semiconductor process engineer, or solid state physicist. But yes: you should understand how a circuit works, and what the parts of your computer are, and how they interact.
And your statement that "specialists" can get by without knowing "a little about a lot" just confuses me. Every talented "specialist" I've ever known has an encyclopedic knowlege of all sorts of things outside their specialty. A better word for a "specialist" that only knows their specialty is probably just "worker", or "lackey".