• cpu的流水线(转)


     “为什么SP2800+比CD330快”,网上也有很多网友问“为什么AMD的CPU的主频比INTEL的低,但是游戏性能却比INTEL的强?”,“为什么INTEL的多媒体比AMD强?”,“为什么INTEL的多任务会比AMD的好?”
      这些有很大一部分归功与CPU的流水线...
      我们先说说流水线,我们用生产汽车的流水线来作比喻,比如说生产一辆汽车需要1小时的时间,如果只有一道工序,那么就要1小时的时间才能生产出一辆汽车。如果分成两道工序,每个工序就要30分钟,那么30分钟就能生产一辆汽车。如果分成四道工序,每个工序就要15分钟,那么每15分钟就能下线一辆汽车,但是生产一辆汽车的时间却没有变化。因此提高汽车下线频率有两种办法:1,减少生产一辆汽车的时间;2,多分几道工序。
      而CPU的流水线也是一样的道理,理论上AMD和INTEL从接到一条指令到完成的时间是一样的(下面就说是绝对速度)。而AMD只有10级的流水线,而INTEL的PRESCOTT核心的CPU却有高达31级的流水线,因此INTEL的频率都较高。这样分析就行了吗?当然不是,31级流水线虽然提高了频率,可是也增加延迟(10级流水线有10次延迟,31级流水线有31次延迟),同时也增加了出错的概率(31级流水线就要31次出错的可能,一出错就得从头再来)。于是我们就得出,AMD的CPU频率较低,而性能却很强,而INTEL却反之。
      于是乎,AMD在游戏这种对突发处理,追求绝对速度的应用上占尽了优势,所谓突发处理,举个例子吧:比在打CS时,作一个向左移动的动作,我们就希望CPU马上作出反映,这时就需要CPU的绝对的速度,而不是其频率。
      现在可能有些朋友就会问了:“既然提高流水线只是提高了频率,对CPU的性能没有多少的提高,为什么INTEL还要拼命提高他的频率呢?”其实提高频率还是很有用的。
      在多媒体方面,我们知道播放一个HDTV文件,就需要一桢一桢地处理数据,这时候,就需要有很好的频率,而对绝对速度却没有多大的要求。因此,我们会发现在多媒体方面INTEL的CPU会有很好的表现。
      另外,前段时间也吵的沸沸扬扬的多任务的问题,在我的实践中,INTEL的多任务的确会比AMD的好点(不包括现在的高端产品)。其实有一部分也归功与31级的流水线,多任务就好比要同时处理多个指令,这时由于AMD的频率较低,在流水线外等待的时间也就长了,造成堵塞。而INTEL较高的频率就畅通的多了。可是为什么不包括现在的高端呢?那是因为现在AMD高端的绝对速度就能弥补频率的劣势。那又问“为什么A64的频率也不见得有多高,可是也不见得其多任务差。”那是因为它把内存控制器集成到CPU中去,降低了延迟,另外也改进了提高命中率的算法(也就是降低了出错的概率),使得绝对速度有提高了。

      首先,我们来看看CPU是怎样处理一个指令的,比如一个“A+B”的指令,CPU要执行这条指令,先得知道A和B在什么地方,要对这些数值进行什么样的操作,然后编译成机器语言,接着执行命令,最后把这些储存起来。
      现在,我们简单地模拟处理器完成一条指令要做的工作。要处理一条指令,处理器必须:
    1,提取数据;
    2,编译成机器语言;
    3,执行指令;
    4,储存数据;
    OK,接着我们来看看流水线,为什么要流水线呢?我们先来看看没有流水线的CPU。


    无流水线处理器

    ┌────────────────────────────────┐

     提取 译码 执行 存储  

    └────────────────────────────────┘

    ├────────────  个时钟周期 -────────────┤

      

    ├──────────── △T = 1秒  -────────────┤

      我们可以看出CPU只有一个阶段,指令被逐步提取,编译,执行,存储。这就是说,我们上面的这个CPU能在一个时钟周期内做所有的事情(提取、编译、执行、存储)。我们设这个CPU的工作频率是1Hz,也就是每秒钟执行1条指令。当然如果有10秒钟,那就是:10 秒 X (1 时钟周期/1 秒) X (1 指令/1 时钟周期) = 10 指令。
      现在,我们开始探讨流水线。流水线能够提升时钟频率和整体性能(记住,更快的时钟频率并不能直接转化成更快的性能)。
      但是如何提高时钟频率呢?一个是用物理方法提高CPU完成指令的速度。另一个就是… 我们先来看看下面两张图。

    两段流水线CPU

    ┌───────────────┬───────────────┐

     提取 译码  执行 存储  

    └───────────────┴───────────────┘

    ├───  个时钟周期 ────┤

      

    ├──────────── △T = 1秒  ────────────┤



    四-段流水线CPU

    ┌───────┬────────┬────────┬────────┐

     提取  译码  执行  存储  

    └───────┴────────┴────────┴────────┘

     1个时钟周期 

      

    ├──────────── △T = 1秒  -──────────────┤


      细心的朋友很快就发现了,既然不能在同一个周期内做很多事情,那就分几个周期来做嘛!而每个周期的时间可以由触发信号来决定的(晶振体),这个我们可以很容易的提高,而在0.25秒内完成一个步骤,也没有达到物理的极限。
      这个四-段流水线CPU现在就是工作在4Hz的频率下了,可是速度提高了吗?我们来看看:
    10 秒 X (4 时钟周期/1 秒) X (0.25 指令/1 时钟周期) = 10 指令
      这个和那个1Hz无流水线的CPU一样10秒钟只能执行10条指令。但我们可以在包装盒上写上“4 Hz”而不是“1 Hz”。很不幸,数字是一个卖点。给一个电脑盲出示一个 4 Hz 的处理器和一个 1 Hz 的处理器,他将认为 4 Hz 的那一个更快,即使事实并非如此。
      可是既然不能提高速度,我们又费那么大的劲干什么呢?嘿嘿,重点来了…
      我们先来了解下流水线的工作方式,首先接受一条指令,做‘提取’这个步骤,做完后把他交给‘译码’来做,接着下个周期就继续提取下条指令,这时候CPU就是同时在做第一条指令的‘译码’和第二条指令的‘提取’,到了第三个周期,CPU就是同时在做第一条指令的‘执行’,第二条指令的‘译码’以及第三条指令的‘提取’…以此类推…
      现在有没有发现上面那个公式有点问题?当经过1秒钟以后,也就是4个周期以后,CPU就会每个周期完成一个指令,就是就0.25秒完成一个。哈哈哈,也就是说,10秒以后CPU完成了37条指令,要比10条指令多得多。
      可是在另一方面,完成一条指令所需的时间都是1秒。
      好了,解释完流水线,我们再来看看在实际的运用中的情况。
      先说说游戏,游戏中的指令一般都是即时的,这时候就是需要的就是这个所完成的时间,而对于每秒完成几个指令的要求是不是那么高了。需要的就是SPEED…
    而在多媒体运用中,数据是一帧一帧地读取的,这时候就需要有高频率,对于完成这个指令要多少时间就不是那么讲究了,只要够流畅就好了…
      而在多任务方面,多任务就是同时有好几个指令等着执行,无流水线的那个CPU就必须要有1秒,一条指令才能到流水线中处理,而4段流水线的那个CPU就只需要0.25秒。
    现在又有了另一个问题了,A64的流水线并没有增加,可是一样在多媒体和多任务方面也有很好的表现,这是为什么呢?
      我认为有几个方面:
      1、A64把内存控制器集成到CPU中去,使得‘提取’的延迟减少了。CPU要提取一个数据,就要先到内存中找,在送回到CPU,这中间通常都要好几个周期的时间,这时的CPU就是处于闲置状态,而如果减少了这其中的延迟,也就是减少了CPU闲置的时间,提高的速度。
      2、A64提高了分支预测算法…等(其他的一些算法以及指令我并没有具体的资料,在这也不好做说明)的效率。
      我们来了解下分支预测,我们在做‘执行’这个步骤时就需要有‘提取’和‘译码’这两个步骤的结果,这时如果预测下下前两步的结果,用这个结果做‘执行’,就能提高效率,但如果算错了,就得重新来了,降低了效率。这时就需要很好的算法。

     

     http://ce.sysu.edu.cn/hope/Item.aspx?id=12701

     

  • 相关阅读:
    [LeetCode] Implement Stack using Queues
    [LeetCode] String Compression
    [国嵌攻略][060][LCD工作原理解析]
    [国嵌攻略][059][2440-DMA程序设计]
    [国嵌攻略][057][串口控制台建立]
    [国嵌攻略][056][串口驱动程序设计]
    [国嵌攻略][054][NandFlash驱动设计_写]
    [问题笔记][指针相加翻译成汇编右移2位]
    [国嵌攻略][053][6410和210按键中断编程]
    [国嵌攻略][050][2440按键中断编程]
  • 原文地址:https://www.cnblogs.com/bizhu/p/2522555.html
Copyright © 2020-2023  润新知