了解计算水平

对不起，我的困惑的问题。我在寻找一些指针。

到目前为止，我主要在应用程序层上使用Java和Python，并且对操作系统和硬件的理解还很模糊。我想了解更多有关较低级别的计算的信息，但是它确实以某种方式变得不知所措。在大学里，我参加了一门有关微程序设计的课程，即如何使处理器硬连线以实现ASM代码。到目前为止，我一直认为，如果对“低水平”知识更多，我将无法完成更多工作。

我有一个问题：硬件怎么可能几乎完全被开发人员隐藏？准确地说，操作系统是硬件的软件层吗？一个小例子：在编程中，我从来没有遇到过了解什么是L2或L3缓存的需求。对于典型的业务应用程序环境，几乎不需要了解汇编程序和较低级别的计算，因为当今存在几乎所有内容都可以使用的技术堆栈。我猜这些较低级别的重点是为高层提供接口。另一方面，我想知道较低的水平会对整个图形计算产生什么影响。

因此，另一方面，存在理论上的计算机科学分支，该分支适用于抽象计算模型。但是，我也很少遇到这样的情况，我发现它在复杂性模型，证明验证等类别中很有帮助。我有点知道，有一个称为NP的复杂性类，它们是无法解决的我想念的是一个框架，供您考虑这些事情。在我看来，这里有各种不同的阵营，很少互动。

最近几周，我一直在阅读有关安全性问题的信息。在这里，许多不同的层以某种方式汇聚在一起。攻击和利用几乎总是发生在较低级别，因此在这种情况下，有必要了解OSI层的详细信息，OS的内部工作原理等。

考虑这些事情的关键词是抽象。

抽象只是意味着故意忽略系统的细节，以便在从多个子系统中组装一个较大的系统时，可以将其视为单个不可分割的组件。这是难以想象的强大-写一个现代的应用程序，同时考虑内存分配的细节和登记蔓延和晶体管运行时会以某种理想化的方式是可行的，但它是无比容易不考虑它们，而只使用高级操作。现代计算范例主要依赖于多个抽象层次：固态电子，微编程，机器指令，高级编程语言，OS和Web编程API，用户可编程框架和应用程序。如今，几乎没有人可以理解整个系统，甚至没有一种可以想象的途径可以使我们回到那种状态。

抽象的另一面是力量的损失。通过将细节决策留给较低层次，我们通常会接受以较低的效率进行决策，因为较低层次没有“全局”，并且只能通过本地知识来优化其工作，而不是（潜在地）像人一样聪明。（通常。通常，由于处理器架构变得如此复杂，因此如今，对于机器而言，将HLL编译为机器代码通常比由最有知识的人来完成更好。）

安全问题是一个有趣的问题，因为抽象中的缺陷和“漏洞”通常可以被利用来破坏系统的完整性。当API假定您可以调用方法A，B和C，但前提是条件X成立时，很容易忘记条件，并且不为违反条件而发生的后果做好准备。例如，经典的缓冲区溢出利用了这样一个事实，即除非您自己分配了此特定的内存块，否则写入内存单元会产生不确定的行为。API仅保证东西结果会发生，但实际上结果是由下一个较低级别的系统详细信息定义的-我们故意忘记了！只要我们满足该条件，这就无关紧要，但是，如果不满足，那么深入了解这两个级别的攻击者通常可以根据需要指挥整个系统的行为，并导致不良情况的发生。

内存分配错误的情况特别糟糕，因为事实证明，在大型系统中，如果没有单个错误，手动管理内存确实非常非常困难。这可能被视为失败的抽象案例：尽管可以用C来完成您需要的一切mallocAPI，这很容易被滥用。编程社区的某些成员现在认为这是在系统上引入层级边界的错误位置，而是通过自动内存管理和垃圾回收来推广语言，这虽然失去了一些功能，但却提供了防止内存损坏和未定义行为的保护。实际上，当今仍然使用C ++的主要原因在于，它允许您精确控制何时获取和释放哪些资源。通过这种方式，当今托管和非托管语言之间的主要分裂可以被视为对在何处精确定义抽象层的分歧。

对于计算中的许多其他主要替代范例也可以说相同的问题-在必须构建大型系统的所有时间里，这个问题确实不断出现，因为我们根本无法为当今常见的复杂需求从头设计解决方案。（近来AI的一个普遍观点是，人脑实际上的确是这样工作的-通过反馈回路，大规模互连的网络等产生的行为，而不是单独的模块和层之间具有简单抽象的接口，这就是为什么我们在模拟我们自己的情报方面几乎没有成功。）