普通开发人员应该对裸机了解多少？
有一天，我突然意识到，我对我希望软件运行的硬件几乎一无所知。我担任开发人员已经大约 5 年了，但自从离开大学后我就没有研究过硬件理论/设计。我什至不再建造自己的机器，因为，说实话，我宁愿多花几块钱，让计算机科学的退学者在商店为我建造它。
虽然很好地理解幕后发生的基础知识显然很重要，但作为开发人员，它离我们太远了，我们真的不需要关心编程 I/O< 的复杂性。 /code> 或 内存映射 I/O 等，..
或者我们呢？
请注意，我在这里谈论的是您的日常 LOB 开发人员，而不是专门的裸机人员。
因此，您可以定义“平均”，但总的来说，一个有能力的程序员应该能够潜入多深？
It struck me the other day that I know nearly nothing about the hardware I expect my software to run on. I've been a dev for around 5 years but I haven't looked into hardware theory/design since i left University. I don't even build my own machines anymore because, being brutally honest, I'd rather pay the extra few bucks and let the Comp Sci drop-out build it at the shop for me.
Whilst it's clearly important to have a good understanding of the basics of what's going on under the hood, it's abstracted so far away from us as devs we really don't need to concern ourselves with the intricacies of Programmed I/O or Memory-Mapped I/O etc,..
Or do we?
Note that I'm talking about your every-day LOB dev here and not the dedicated bare-metal guys.
So, define 'average' how you will but overall, how deep should a competent programmer be able to dive?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这取决于你的发展水平有多高。
但在所有开发中，您可能应该了解基础知识。例如，
另一方面，我认为了解内存映射 IO 等具体细节，或者了解 NAND 和 NOR 闪存之间的区别对于普通*（桌面/Web）开发人员来说并不重要。即使是现代 CPU 架构的知识本身也可能是一门科学，看看它们在过去几年中变得多么复杂，更不用说 现代编译器发出的代码变得越来越难以预测（链接的文章表明，现在在低级别上比编译器更难优化）。这就像几十年前成为一名汽车修理工更容易一样，今天没有多少人会尝试自己修理汽车。
**“平均”的定义可能有所不同。*
It depends on how high-level your development is.
But in all development, you probably should know the fundamentals. E.g.,
On the other hand, I don't think knowing the specifics like what memory-mapped IO is, or knowing the difference between NAND and NOR flash is really important for an average* (desktop/web) developer. Even the knowledge of the architecture of a modern CPU is probably going to be a science in itself seeing how complex they've got in the past years, not to mention that the code emitted by modern compilers is becoming more difficult to predict (the article linked shows that it's harder now to outsmart the compiler at low-level optimizations). It's similar to being a car mechanic was easier a few decades ago, today not that many people will try to fix their cars by themselves.
**Definition of "average" may vary.*
我发现能够理解编译器发出的汇编语言（在我的例子中是 C++）非常有用。当考虑优化等问题和解决困难的调试问题时，这非常有帮助。
I find it extremely useful to be able to understand the assembly language emitted by the compiler, C++ in my case. This is very helpful when considering issues like optimisation, and resolving difficult debugging problems.
在不了解底层硬件的情况下当然是可能的。然而，了解一点点例如缓存如何工作以及特定目标机器上哪些操作快/慢将有助于您在设计软件时做出更好的设计决策。
就我个人而言，我认为了解我每天至少花费 10 个小时工作的机器的情况是一种极大的满足感；）
但话又说回来，为什么要满足于平均水平呢？
It's certainly possible to get by without knowing anything about the underlying hardware. However knowing even a little bit about for instance how caches work and which operations are fast/slow on your particular target machine will help you make much better design decisions when designing the software.
On a personal note I think there's great satisfaction in knowing how the machine I spend at least 10 hours a day at work ;)
And then again why settle for average?
很多情况下，你不知道你的程序将在哪个硬件上运行，所以过多地关心一台机器的一些具体细节是没有意义的。用户可能会在某些 64 位 RISC 硬件上的虚拟机中运行 Win32 可执行文件，谁知道呢。除非您明确了解目标硬件，否则最好使用操作系统和标准库为您提供的抽象，并按预期使用它们。相信构建操作系统、编译器和库的人能够正确完成他们的工作。
In many cases, you don't know which hardware your program will run on, so caring too much about some specific details of one machine makes no sense. Users might run your Win32 executable in a virtual machine on some 64Bit RISC hardware, who knows. Unless you definitely know the target hardware, it's better to use the abstractions that the OS and the standard libs give you, and use them as intended. Trust the people who build the OS, the compiler, the libs to do their job properly.
操作系统开发人员在抽象底层物理世界方面做得非常出色。他们的目的是为普通开发人员提供许多硬件的通用接口，以便他可以专注于其应用程序并开发可移植、更易于维护并能够获得操作系统更新优化的代码。
因此，对于制作普通应用程序的普通开发人员来说，我认为最好不要问太多有关硬件的问题。
OS developers make a great job in order to abstract the underlying physical world. Their purpose is to provide the average developer with a common interface to many hardwares so he can focus on its application and develop code that is portable, easier to maintain and able to gain optimizations on OS updates.
So for an average developer making an average application, I think it is better not to ask too many questions about hardware.