• 为什么没有“128位”的通用处理器


    在专用领域,比如DSP,GPU中,通用寄存器通常都很宽,也就是说大于通常的32位或者64位。其原因在于,这些针对特定领域设计的处理器,其硬件架构是为问题服务的,举例来说,GPU处理颜色的时候,一个像素ARGB是四个32位或者16位的浮点数,所以寄存器有128位或者64位宽也就不足为奇了。

    那么我们为什么没有见到,或者说市场上为什么没有“128位”的通用处理器呢?这有很多计算机体系结构的原因在里面,容我一一说来:

    首先,我们得定义这个“128位”是什么。以传统的POWER、x86和x64来说,处理器的位数是用通用寄存器的宽度来定义的,即32位处理器的通用寄存器是32位,64位处理器的寄存器是64位,那么如果我们有了128位处理器,也应该一样。但是,这么做有必要么?常规的整数运算是用不到这么大的寄存器的,真正的大数运算也不会用这种方法来实现。而在现代的32位、64位处理器中,更重要的浮点运算所使用的浮点寄存器早已经是128位甚至256位了。所以128位通用寄存器在这里没什么意义。

    那么就有人说,我们需要128位的寻址能力。好吧,64位的寻址能力是2^64字节,大约是1.84467441 × 1019 字节,如果你对这个科学计数法表示的数字没什么感觉,我用另外一种写法:18.45 EB 也就是大约18200000 TB,如果说这个不够用,那你需要的不是人类目前的硅芯片计算机,你需要求助于E.T.。

    使用大地址空间有几个额外的问题,尤其是对RISC处理器来说,会带来致命的性能问题。很多用户,尤其是初级的计算机用户,并不知道RISC这四个字母下隐藏的计算机哲学,或者说艺术:所有的OP code都是定长。以POWER为例,访问32位的常量地址,需要分两次计算16位的地址,因为OP code中只有16bits来存放这样的数据,64位则需要四个OP存放。而在CISC处理器中,地址可以直接编码在指令里,导致指令明显变长,比如32位的跳转通常是5个字节,而64位下面甚至需要15个字节。这只是问题的开始:随着使用的OP的增多,对CPU总线和cache的压力也越来越大,原本一个时钟周期能fetch两条指令,现在可能一条都取不到;原本可以存放两条、四条指令的cache空间,现在只能存放一条指令。

    另一个原因是程序中的数据结构。学过计算机科学初级内容的人都知道,现代数据结构中最最最最最基本的要素是:指针。大多数关键的数据结构都离不开指针:链表、树……,对于程序来说,从32位编译成64位会大幅增加运行时的内存消耗,道理很简单,指针本身变长了,存储指针自身需要的空间增加了。变成128位是什么样呢?可想而知。同样访问内存中的数据需要更多的时间,因为数据本身变大了,假设一个结构体里面有两个指针,32位下编译出来需要8个字节,64位就需要16个字节(假设4字节对齐)。同理,cache面临更大的压力。

    上面是软件上的,或者说是理论上的,那么我们来看看硬件上的问题。既设我们需要制造“128位”的通用处理器,有128位的地址总线,128位甚至256位的数据总线,那么什么样的封装能满足要求呢?在现代处理器3~~4G的这个工作频率上,安排这么大量的总线连接,那么保守估计需要1500~~2500个针脚的封装才能稳定工作(需要大量的供电和接地针脚来瓶很电流和改善信号质量),而且这么高密度的,还有大电流,估计要12~~24层布线,设计生产这样的一块PCB本身就是挑战电子制造业,至于良品率和价格就不敢想了。

    既然我们有了便宜的4核、8核处理器,为什么要设计生产完全不可行,没有任何工业和商业价值的“128位”处理器呢?所以,市场上没有“128位”通用处理器。

  • 相关阅读:
    Freemarker与Springmvc
    Freemarker与普通java
    Freemarker与Servlet
    跳舞的时间插件
    video标签播放视频
    字符串反转
    菲波拉契数列
    求所有子数组的和的最大值
    Spring AOP 5种通知与java动态代理
    线程维护日志队列
  • 原文地址:https://www.cnblogs.com/skogkatt/p/4163384.html
Copyright © 2020-2023  润新知