浅谈处理器形态对于编程的影响

写了硬件的发展史之后，属于历史，那么我们也要展望一下未来的可能性。所以就有了今天这一篇。我们知道硬件的设计需求是根据具体使用场景的遇到的痛点，然后可能会提出新的需求。

我们也会发现各个架构有一定的趋同性，无论是x86还是arm也在相互学习，x86学习arm的低功耗，arm也想提高性能。所以精简指令和复杂指令不再那么纯粹。各种总线也在相互借鉴，比如都有内存分页，除了寄存器定义不同，宏观上的分页结构基本是一致的。所以好的东西都在用，这样对软件也有一个好处，硬件形态的设计规范，会使得软件的移植性更好。

除了一些特定使用场景的硬件设计，我们普遍希望的是提高处理速度。我们以服务器使用场景为例子，来一些可能已经存在的猜测，然后我们再展望一下未来处理器（光子计算机和量子计算机等）的形态对于编程的影响

先说可能存在的猜想。我们说过服务器为了提高吞吐量，是分布式的，提高稳定性支持内存，cpu的热插拔等。那么为了提高性能。

在一个服务器主板上可能是怎样的呢？是单个操作系统还是多个操作系统呢？对于同构的处理器可以是单个系统。对于异构的只能是多个系统。假设猜测是多操作系统之间的配合协调。实际也有可能是一个分布式的操作系统。单系统。但是不影响我们说明问题。

我们假设我们访问百度，百度不可能只有一个机房，一个机房不可能只有一个服务器。这些从百度的网址找到具体的服务器（通常肯定是多个，然后负载均衡）。我们就假设找到了一个服务器，然后这个服务器的形态是怎样的会好呢。我们猜测的硬件形态如下图：

注意这里的cpu1，2，3表示的不是core，而是一颗多核心的cpu。由于我们假设是多系统的，那么我们就假设这几个cpu都跑linux，系统在各自cpu的local memory里面。然后global memory是每个cpu都可以访问的。这样这几个cpu之间就可以通过共享内存来通信，至于gloabl memory里面是什么结构来组织的实现共享内存通信，这个是实现问题。假设global里面有一个内存数据库。这样相当于多个cpu使用了一个内存数据库。或者是一个内存文件系统，那么多个cpu之间共享了一个文件系统。或者更简单的一些消息通信机制，比如就是个类似ringbuffer的东西，这样cpu之间可以根据定义的ringbuffer的结构通信。

服务器重要的是什么一个是速度，还有一个是数据的备份，保存，数据库之类的。数据库有内存数据库redis，还有磁盘数据库mysql之类的。所以最终的数据都要进入磁盘。所以这个就有一个矛盾并发和互斥访问的矛盾。为了速度我们在不断的提高并发的可能，提高单个核心的速度，但是对于同一个数据库，同一个总线，同一块内存，同一个磁盘的访问总会互斥，有些是硬件上要支持的互斥，有些是软件保证的互斥。所以就要考虑尽量减少互斥的范围。

目前的情况是我们的cpu的两个核心，访问内存的时候，是互斥访问的，因为是同一个总线。那么有没有这样一种可能，如下图：

如上图我们两颗cpu访问同一内存条假设20G，那么红色的部分就要保证互斥访问，访问者，要先获得总线所有权，然后访问释放。对于整个20G的地址空间都要互斥。这样互斥的共享空间限制太大了20个G。由硬件保证在微观上两个cpu访问内存条是互斥访问的。

那么我做一个猜想有没有这样一种memory，比如可以提供2，4，8个通道，这样多个cpu使用不同的通道，只要访问地址不同，就在硬件上，不会争夺总线。或者难以实现的话，我们弱化一些，每4K为一个地址范围。比如这20G的地址空间是0-20G，那么假设一个cpu访问的地址是0《addr《4K，如果另外一个cpu也访问这个内存条，那么如果地址范围也在0-4K那么就要总线互斥，但是如果访问的是4k-8k，那么就可以不需要总线互斥，在微观上，硬件上确实做到一定程度的并发访问。猜测的可能的硬件形态如下图：

如上图，cpu1通过红色的总线访问这个内存条，cpu2通过绿色的总线访问这个内存条，内存条出厂的时候有一个判断电路，看红色和绿色的地址是否4K空间冲突。如果不冲突，那么可以微观上完全并发，如果冲突，那么就只能互斥访问。

异构内存文件系统 ：可能没有这个概念，是我臆造的，不知道是否存在。

我们的总线上有多颗cpu，每颗都有自己的系统，但是我们的memory里面可以有一个内存文件系统，我把它叫做异构共享文件系统，两颗cpu都可以访问，并且两个cpu里面可以跑不同的系统，也不要求是同一种硬件架构。如下图：

前面的一些属于一些合理猜测或者臆造，不知道是否存在，也许还真的已经存在。

接下来我们说光子计算机和量子计算机。有一段时间炒作的很火，我们不说炒作嫌疑，毕竟无论什么行业刚开始都会有夸大炒作。但是只要发展方向是对的迟早实现，就是时间问题。

光子计算机低功耗，速度快，量子计算机更是速度快。那么假设这些最终都实现了，那么编程的形态会不会变化？我们现在学习的编程语言，编程思想，整个软件生态还能不能用？

我认为对于软件生态是一个机会，可能c语言，java语言等等各种编程语言还能用，也许会有新的语言出来。新的系统出来。这个对于整个软件生态都是机会。新的计算形态完全没有必要整个将老的推翻。而是适配向上兼容。

也许新的计算机表示信息不再是2进制，都不好说，但是我们的高级语言是通过编译器编译的。对于语言不需要知道计算机信息表示是几进制。这个通过编译工具链掩盖了。

所以新的针对光子处理器，量子形态的处理器会出现对应的编译工具链。向上兼容现有的软件生态（语言，系统，工具），也许不完全兼容，但是大部分兼容。我们在量子计算机和光子计算机上运行我们原来在传统计算机上的程序，我们不需要知道底层是光子计算机还是量子计算机。就像我们写的程序。我们用不同的工具链编译运行。我们不需要知道是x86的还是arm的一样。这就是向上兼容。通过编译工具来翻译。加上光子计算机和量子计算机的速度的极大提升，会出现新的针对这么高速度的的操作系统，新的软件生态的扩充，而不是消灭老的。对于软件来说反而是机会。也许会出现新的针对该种计算机的新的编程语言，但是完全不会消灭老的语言。新的应用场景会出现，同样对于应用编程者也是机会。