├── fu-lufduo-ji-hu-lian.md ├── fu-ludcun-chu-xi-tong.md ├── qian-yan ├── bu-chong-cai-liao.md ├── dang-qian-ban-ben.md ├── xuan-cai-yu-zu-zhi.md ├── bang-zhu-gai-jin-zhe-ben-shu.md ├── README.md ├── jie-yu.md ├── zhang-jie-jie-gou.md ├── an-li-yan-jiu-yu-xi-ti.md ├── wo-men-wei-shi-mo-xie-zhe-ben-shu.md ├── yue-du-dao-lan.md └── nei-rong-gai-shu.md ├── fu-lueqian-ru-shi-xi-tong.md ├── fu-luazhi-ling-ji-she-ji-yuan-ze.md ├── di-wu-zhang-xian-cheng-ji-bing-hang.md ├── fu-lugshen-ru-xiang-liang-chu-li-qi.md ├── fu-lukzhi-ling-ji-jia-gou-de-hui-gu.md ├── di-er-zhang-nei-cun-ceng-ci-jie-gou-she-ji.md ├── di-qi-zhang-ling-yu-te-ding-jia-gou-dsa.md ├── fu-lumli-shi-guan-dian-he-can-kao-wen-xian.md ├── di-san-zhang-zhi-ling-ji-bing-hang-ji-qi-ying-yong.md ├── fu-lubnei-cun-ceng-ci-jie-gou-de-hui-gu ├── README.md ├── zhai-yao.md └── b.1-jie-shao │ ├── README.md │ ├── huan-cun-xing-neng-hui-gu.md │ ├── yi-ge-li-zi-opteron-de-shu-ju-huan-cun.md │ └── si-ge-nei-cun-ceng-ci-de-wen-ti.md ├── fu-lucliu-shui-xian-chu-ji-he-zhong-ji-gai-nian.md ├── fu-lu-hvliw-he-epic-de-ying-jian-he-ruan-jian.md ├── fu-lujji-suan-ji-suan-shu-arithmetic-xiang-guan.md ├── di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi ├── README.md ├── an-li-yan-jiu-he-xi-ti.md ├── 1.9-ji-suan-ji-liang-hua-she-ji-yuan-ze │ ├── README.md │ ├── ju-bu-xing-yuan-li.md │ ├── guan-zhu-chang-jian-qing-kuang.md │ ├── li-yong-bing-hang-hua-de-you-shi.md │ ├── a-mu-da-er-ding-lv.md │ └── chu-li-qi-xing-neng-fang-cheng.md ├── 1.5-ji-cheng-dian-lu-zhong-gong-shuai-he-neng-hao-de-fa-zhan-qu-shi │ ├── README.md │ ├── you-yu-neng-hao-de-xian-zhi-ji-suan-ji-jia-gou-de-zhuan-bian.md │ ├── dian-yuan-he-neng-hao-yi-ge-xi-tong-de-shi-jiao.md │ └── wei-chu-li-qi-nei-de-neng-hao-he-gong-shuai.md ├── 1.6-cheng-ben-de-fa-zhan-qu-shi │ ├── cheng-ben-yu-jia-ge.md │ ├── zhi-zao-cheng-ben-yu-yun-ying-cheng-ben.md │ ├── README.md │ ├── shi-jian-shu-liang-he-shang-pin-hua-de-ying-xiang.md │ └── ji-cheng-dian-lu-de-cheng-ben.md ├── 1.8-ping-ce-bao-gao-he-zong-jie-xing-neng │ ├── bao-gao-xing-neng-jie-guo.md │ ├── ji-zhun-ping-ce │ │ ├── zhuo-mian-ying-yong-ji-zhun.md │ │ ├── fu-wu-qi-ying-yong-ji-zhun.md │ │ └── README.md │ ├── README.md │ └── zong-jie-xing-neng-jie-guo.md ├── 1.13-li-shi-guan-dian-he-yin-yong.md ├── 1.2-ji-suan-ji-de-lei-bie │ ├── zhuo-mian-ji-suan-ji.md │ ├── README.md │ ├── fu-wu-qi.md │ ├── wu-lian-wang-qian-ru-shi-ji-suan-ji.md │ ├── ge-ren-yi-dong-zhong-duan.md │ ├── ji-qun-shu-ju-cang-ku-gui-mo-de-ji-suan-ji.md │ └── bing-hang-xing-he-bing-hang-jia-gou-de-lei-bie.md ├── 1.3-ji-suan-ji-ti-xi-jie-gou-de-ding-yi │ ├── README.md │ ├── ming-fu-qi-shi-de-ji-suan-ji-ti-xi-jie-gou-she-ji-zu-zhi-organization-he-ying-jian-yi-man-zu-she-ji.md │ └── zhi-ling-ji-jia-gou-ji-suan-ji-ti-xi-jie-gou-de-xia-ai-guan-dian.md ├── zhai-yao.md ├── 1.4-ji-shu-qu-shi │ ├── jing-ti-guan-xing-neng-he-dao-xian-de-kuo-da.md │ ├── xing-neng-qu-shi-dai-kuan-de-ti-sheng-da-yu-yan-chi.md │ └── README.md ├── 1.10-ba-ta-men-fang-zai-yi-qi-xing-neng-jia-ge-he-gong-hao.md ├── 1.7-ke-kao-xing.md ├── 1.12-jie-lun.md ├── 1.1-jie-shao.md └── 1.11-miu-wu-he-xian-jing.md ├── fu-luida-gui-mo-duo-chu-li-qi-he-ke-xue-ji-suan-de-ying-yong.md ├── fu-luldi-zhi-fan-yi-address-translation-de-gao-ji-gai-nian.md ├── di-si-zhang-shi-liang-simd-he-gpu-jia-gou-zhong-de-shu-ju-ji-bing-hang-xing.md ├── di-liu-zhang-da-gui-mo-shu-ju-zhong-xin-ji-ji-suan-ji-de-bing-hang-xing-qing-qiu-ji-bing-hang-rlp-he.md ├── .gitbook └── assets │ ├── NeatReader-1655966534161.png │ ├── NeatReader-1655971846641.png │ ├── NeatReader-1655973062512.png │ ├── NeatReader-1656036294746.png │ ├── NeatReader-1656036763291.png │ ├── NeatReader-1656036839026.png │ ├── NeatReader-1656036932626.png │ ├── NeatReader-1656038704682.png │ ├── NeatReader-1656042175346.png │ ├── NeatReader-1656042513762.png │ ├── NeatReader-1656051642636.png │ ├── NeatReader-1656051872089.png │ ├── NeatReader-1656051959385.png │ ├── NeatReader-1656052563666.png │ ├── NeatReader-1656052640777.png │ ├── NeatReader-1656053294194.png │ ├── NeatReader-1656054072377.png │ ├── NeatReader-1656054202769.png │ ├── NeatReader-1656054748201.png │ ├── NeatReader-1656056146809.png │ ├── NeatReader-1656056159337.png │ ├── NeatReader-1656056559161.png │ ├── NeatReader-1656056564441.png │ ├── NeatReader-1656056805913.png │ ├── NeatReader-1656056957721.png │ ├── NeatReader-1656057376561.png │ ├── NeatReader-1656057506513.png │ ├── NeatReader-1656057859481.png │ ├── NeatReader-1656058409761.png │ ├── NeatReader-1656058472393.png │ ├── NeatReader-1656061094113.png │ ├── NeatReader-1656322656983.png │ ├── NeatReader-1656322715023.png │ ├── NeatReader-1656323421583.png │ ├── NeatReader-1656323586591.png │ ├── NeatReader-1656324054606.png │ ├── NeatReader-1656324098695.png │ ├── NeatReader-1656341460740.png │ ├── NeatReader-1656383901164.png │ ├── NeatReader-1656383984531.png │ ├── NeatReader-1656384759539.png │ ├── NeatReader-1656385548291.png │ ├── NeatReader-1656387657963.png │ ├── NeatReader-1656387700011.png │ ├── NeatReader-1656387980419.png │ ├── NeatReader-1656388027819.png │ ├── NeatReader-1656395507026.png │ ├── NeatReader-1656396161147.png │ ├── NeatReader-1656396164885.png │ ├── NeatReader-1656396418163.png │ ├── NeatReader-1656396777907.png │ ├── NeatReader-1656397108003.png │ ├── NeatReader-1656397161075.png │ ├── NeatReader-1656397448347.png │ ├── NeatReader-1656397645547.png │ ├── NeatReader-1656397682499.png │ ├── NeatReader-1656398200347.png │ ├── NeatReader-1656398331171.png │ ├── NeatReader-1656398369483.png │ ├── NeatReader-1656404177994.png │ ├── NeatReader-1656404273820.png │ ├── NeatReader-1656404361034.png │ ├── NeatReader-1656404493858.png │ ├── NeatReader-1656406108658.png │ ├── NeatReader-1656406935362.png │ ├── NeatReader-1656407418363.png │ ├── NeatReader-1656407607705.png │ ├── NeatReader-1656408465465.png │ ├── NeatReader-1656408708450.png │ ├── NeatReader-1656472554738.png │ ├── NeatReader-1656472960435.png │ ├── NeatReader-1656480822434.png │ ├── NeatReader-1656492913257.png │ ├── NeatReader-1656493288625.png │ ├── NeatReader-1656493705674.png │ ├── NeatReader-1656494474009.png │ ├── NeatReader-1656494595169.png │ ├── NeatReader-1656574241439.png │ ├── NeatReader-1656574280092.png │ ├── NeatReader-1656574355157.png │ ├── NeatReader-1656574378708.png │ ├── NeatReader-1656574934509.png │ ├── NeatReader-1656575156094.png │ ├── NeatReader-1656576186629.png │ ├── NeatReader-1656577525140.png │ ├── NeatReader-1656771737281.png │ ├── NeatReader-1656775564259.png │ ├── NeatReader-1656833433564.png │ ├── NeatReader-1656834718438.png │ ├── NeatReader-1657449430083.png │ ├── NeatReader-1656480822434 (1).png │ ├── NeatReader-1656494595169 (1).png │ └── NeatReader-1656574378708 (1).png ├── README.md └── SUMMARY.md /fu-lufduo-ji-hu-lian.md: -------------------------------------------------------------------------------- 1 | # 附录F-多机互联 2 | 3 | -------------------------------------------------------------------------------- /fu-ludcun-chu-xi-tong.md: -------------------------------------------------------------------------------- 1 | # 附录D-存储系统 2 | 3 | -------------------------------------------------------------------------------- /qian-yan/bu-chong-cai-liao.md: -------------------------------------------------------------------------------- 1 | # 补充材料 2 | 3 | -------------------------------------------------------------------------------- /qian-yan/dang-qian-ban-ben.md: -------------------------------------------------------------------------------- 1 | # 当前版本 2 | 3 | -------------------------------------------------------------------------------- /qian-yan/xuan-cai-yu-zu-zhi.md: -------------------------------------------------------------------------------- 1 | # 选材与组织 2 | 3 | -------------------------------------------------------------------------------- /fu-lueqian-ru-shi-xi-tong.md: -------------------------------------------------------------------------------- 1 | # 附录E-嵌入式系统 2 | 3 | -------------------------------------------------------------------------------- /fu-luazhi-ling-ji-she-ji-yuan-ze.md: -------------------------------------------------------------------------------- 1 | # 附录A-指令集设计原则 2 | 3 | -------------------------------------------------------------------------------- /di-wu-zhang-xian-cheng-ji-bing-hang.md: -------------------------------------------------------------------------------- 1 | # 第五章 线程级并行 2 | 3 | -------------------------------------------------------------------------------- /fu-lugshen-ru-xiang-liang-chu-li-qi.md: -------------------------------------------------------------------------------- 1 | # 附录G-深入向量处理器 2 | 3 | -------------------------------------------------------------------------------- /fu-lukzhi-ling-ji-jia-gou-de-hui-gu.md: -------------------------------------------------------------------------------- 1 | # 附录K-指令集架构的回顾 2 | 3 | -------------------------------------------------------------------------------- /qian-yan/bang-zhu-gai-jin-zhe-ben-shu.md: -------------------------------------------------------------------------------- 1 | # 帮助改进这本书 2 | 3 | -------------------------------------------------------------------------------- /di-er-zhang-nei-cun-ceng-ci-jie-gou-she-ji.md: -------------------------------------------------------------------------------- 1 | # 第二章 内存层次结构设计 2 | 3 | -------------------------------------------------------------------------------- /di-qi-zhang-ling-yu-te-ding-jia-gou-dsa.md: -------------------------------------------------------------------------------- 1 | # 第七章 领域特定架构（DSA） 2 | 3 | -------------------------------------------------------------------------------- /fu-lumli-shi-guan-dian-he-can-kao-wen-xian.md: -------------------------------------------------------------------------------- 1 | # 附录M-历史观点和参考文献 2 | 3 | -------------------------------------------------------------------------------- /di-san-zhang-zhi-ling-ji-bing-hang-ji-qi-ying-yong.md: -------------------------------------------------------------------------------- 1 | # 第三章 指令级并行及其应用 2 | 3 | -------------------------------------------------------------------------------- /fu-lubnei-cun-ceng-ci-jie-gou-de-hui-gu/README.md: -------------------------------------------------------------------------------- 1 | # 附录B-内存层次结构的回顾 2 | 3 | -------------------------------------------------------------------------------- /fu-lucliu-shui-xian-chu-ji-he-zhong-ji-gai-nian.md: -------------------------------------------------------------------------------- 1 | # 附录C-流水线：初级和中级概念 2 | 3 | -------------------------------------------------------------------------------- /fu-lu-hvliw-he-epic-de-ying-jian-he-ruan-jian.md: -------------------------------------------------------------------------------- 1 | # 附录H-VLIW和EPIC的硬件和软件 2 | 3 | -------------------------------------------------------------------------------- /fu-lujji-suan-ji-suan-shu-arithmetic-xiang-guan.md: -------------------------------------------------------------------------------- 1 | # 附录J-计算机算数（Arithmetic）相关 2 | 3 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/README.md: -------------------------------------------------------------------------------- 1 | # 第一章 量化设计和分析的基础知识 2 | 3 | -------------------------------------------------------------------------------- /fu-luida-gui-mo-duo-chu-li-qi-he-ke-xue-ji-suan-de-ying-yong.md: -------------------------------------------------------------------------------- 1 | # 附录I-大规模多处理器和科学计算的应用 2 | 3 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/an-li-yan-jiu-he-xi-ti.md: -------------------------------------------------------------------------------- 1 | # 案例研究和习题 2 | 3 | -------------------------------------------------------------------------------- /fu-luldi-zhi-fan-yi-address-translation-de-gao-ji-gai-nian.md: -------------------------------------------------------------------------------- 1 | # 附录L-地址翻译（Address Translation）的高级概念 2 | 3 | -------------------------------------------------------------------------------- /di-si-zhang-shi-liang-simd-he-gpu-jia-gou-zhong-de-shu-ju-ji-bing-hang-xing.md: -------------------------------------------------------------------------------- 1 | # 第四章 矢量、SIMD和GPU架构中的数据级并行性 2 | 3 | -------------------------------------------------------------------------------- /qian-yan/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: 约翰-亨尼西 和 大卫-帕特森 3 | --- 4 | 5 | # 前言 6 | 7 | 8 | 9 | 【待继续】 10 | -------------------------------------------------------------------------------- /di-liu-zhang-da-gui-mo-shu-ju-zhong-xin-ji-ji-suan-ji-de-bing-hang-xing-qing-qiu-ji-bing-hang-rlp-he.md: -------------------------------------------------------------------------------- 1 | # 第六章 大规模数据中心级计算机的并行性：请求级并行（RLP）和数据级并行 2 | 3 | -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1655966534161.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1655966534161.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1655971846641.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1655971846641.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1655973062512.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1655973062512.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656036294746.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656036294746.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656036763291.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656036763291.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656036839026.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656036839026.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656036932626.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656036932626.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656038704682.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656038704682.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656042175346.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656042175346.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656042513762.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656042513762.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656051642636.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656051642636.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656051872089.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656051872089.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656051959385.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656051959385.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656052563666.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656052563666.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656052640777.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656052640777.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656053294194.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656053294194.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656054072377.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656054072377.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656054202769.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656054202769.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656054748201.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656054748201.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656056146809.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656056146809.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656056159337.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656056159337.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656056559161.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656056559161.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656056564441.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656056564441.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656056805913.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656056805913.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656056957721.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656056957721.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656057376561.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656057376561.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656057506513.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656057506513.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656057859481.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656057859481.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656058409761.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656058409761.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656058472393.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656058472393.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656061094113.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656061094113.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656322656983.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656322656983.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656322715023.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656322715023.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656323421583.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656323421583.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656323586591.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656323586591.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656324054606.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656324054606.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656324098695.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656324098695.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656341460740.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656341460740.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656383901164.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656383901164.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656383984531.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656383984531.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656384759539.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656384759539.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656385548291.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656385548291.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656387657963.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656387657963.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656387700011.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656387700011.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656387980419.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656387980419.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656388027819.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656388027819.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656395507026.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656395507026.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656396161147.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656396161147.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656396164885.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656396164885.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656396418163.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656396418163.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656396777907.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656396777907.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656397108003.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656397108003.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656397161075.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656397161075.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656397448347.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656397448347.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656397645547.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656397645547.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656397682499.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656397682499.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656398200347.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656398200347.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656398331171.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656398331171.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656398369483.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656398369483.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656404177994.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656404177994.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656404273820.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656404273820.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656404361034.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656404361034.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656404493858.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656404493858.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656406108658.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656406108658.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656406935362.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656406935362.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656407418363.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656407418363.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656407607705.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656407607705.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656408465465.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656408465465.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656408708450.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656408708450.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656472554738.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656472554738.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656472960435.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656472960435.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656480822434.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656480822434.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656492913257.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656492913257.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656493288625.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656493288625.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656493705674.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656493705674.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656494474009.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656494474009.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656494595169.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656494595169.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656574241439.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656574241439.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656574280092.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656574280092.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656574355157.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656574355157.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656574378708.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656574378708.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656574934509.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656574934509.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656575156094.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656575156094.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656576186629.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656576186629.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656577525140.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656577525140.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656771737281.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656771737281.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656775564259.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656775564259.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656833433564.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656833433564.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656834718438.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656834718438.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1657449430083.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1657449430083.png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656480822434 (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656480822434 (1).png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656494595169 (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656494595169 (1).png -------------------------------------------------------------------------------- /.gitbook/assets/NeatReader-1656574378708 (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/TuringKi/Gitbook-Computer-Architecture-A-Quantitative-Approach-6th-Chinese/HEAD/.gitbook/assets/NeatReader-1656574378708 (1).png -------------------------------------------------------------------------------- /qian-yan/jie-yu.md: -------------------------------------------------------------------------------- 1 | # 结语 2 | 3 | 这本书再次成为真正的合著版本，我们每个人都写了一半的章节，并在附录中占有同等份额。我们无法想象，如果没有其他作者做一半的工作，在任务似乎无望的时候提供灵感、提供关键的见解来解释一个困难的概念、在周末提供各章节的评论。以及在我们其他义务的压力使我们难以拿起笔的时候表示同情，这将需要多长时间。 4 | 5 | 因此，我们再次共同承受你对本书内容的责难。 6 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.9-ji-suan-ji-liang-hua-she-ji-yuan-ze/README.md: -------------------------------------------------------------------------------- 1 | # 1.9 计算机量化设计原则 2 | 3 | 在上一章我们已经看到了如何定义、评测和总结性能、成本、可靠性、能耗和功率，现在我们可以探索在计算机的设计和分析中有用的准则和原则了。本节介绍了关于设计的重要意见，以及两个用来评估替代方案的方程式。 4 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.5-ji-cheng-dian-lu-zhong-gong-shuai-he-neng-hao-de-fa-zhan-qu-shi/README.md: -------------------------------------------------------------------------------- 1 | # 1.5 集成电路中功率和能耗的发展趋势 2 | 3 | 今天，对于几乎每一类计算机来说，能源都是计算机设计师面临的最大挑战。首先，电源必须被引入并分布在芯片周围，而现代微处理器仅在电源和地线方面就使用了数百个引脚和多个互连层。其次，电源以热量的形式散失，这些热量必须被带离芯片。 4 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.6-cheng-ben-de-fa-zhan-qu-shi/cheng-ben-yu-jia-ge.md: -------------------------------------------------------------------------------- 1 | # 成本与价格 2 | 3 | 随着计算机的商品化，制造产品的成本和产品的售价之间的利润率一直在缩小。这些利润率用于支付公司的研究和开发（R\&D）、市场、销售、制造设备维护、建筑租金、融资成本、税前利润和税收。许多工程师惊讶地发现，大多数公司只将收入的4%（在商品PC业务中）至12%（在高端服务器业务中）用于研发，这包括所有工程化。 4 | -------------------------------------------------------------------------------- /qian-yan/zhang-jie-jie-gou.md: -------------------------------------------------------------------------------- 1 | # 章节结构 2 | 3 | 我们所选择的材料是在一个一致的框架上延伸出来的，每一章都遵循这个框架：我们首先解释一章的观点，然后是 "交叉问题 "部分，该部分显示了一章中涉及的观点如何与其他章节中的观点互动。随后是 "把它放在一起 "部分，通过展示这些观点在实际机器中的应用，把这些观点联系在一起。 4 | 5 | 接下来是 "谬误和陷阱"，让读者从别人的错误中学习。我们展示了一些常见的误解和架构陷阱的例子，即使你知道它们在等着你，也很难避免。谬误和陷阱 "部分是本书中最受欢迎的部分之一。每一章的结尾都有一个 "结语 "部分。 6 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.8-ping-ce-bao-gao-he-zong-jie-xing-neng/bao-gao-xing-neng-jie-guo.md: -------------------------------------------------------------------------------- 1 | # 报告性能结果 2 | 3 | 报告性能测量的指导原则应该是可重复性--列出另一个实验者复现结果所需的一切。SPEC基准报告要求对计算机和编译器标志进行完整的描述，并公布基线和优化的结果。除了硬件、软件和基线调整参数的描述之外，SPEC以表格和图表形式描述了实际性能时间。TPC基准报告甚至更加完整，因为它必须包括基准审计的结果和成本信息。这些报告是寻找计算系统真实成本的绝佳来源，因为制造商在高性能和性价比方面进行竞争。 4 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.13-li-shi-guan-dian-he-yin-yong.md: -------------------------------------------------------------------------------- 1 | # 1.13 历史观点和引用 2 | 3 | 附录M（可在线获取）包括对本文各章中提出的关键思想的历史视角。这些历史观点部分使我们能够通过一系列机器追踪一个想法的发展，或者描述重要的项目。如果你对研究一个想法或处理器的最初发展感兴趣，或者想进一步阅读，每段历史的末尾都提供了参考资料。在本章中，请看M.2节 "计算机的早期发展"，以讨论数字计算机的早期发展和性能测试方法。 4 | 5 | 当你阅读这些历史材料时，你很快就会意识到，与许多其他工程领域相比，计算机发展的较短历史的一个重要好处是，一些先驱者仍然活着--我们可以通过简单地询问他们来了解这段历史! 6 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.6-cheng-ben-de-fa-zhan-qu-shi/zhi-zao-cheng-ben-yu-yun-ying-cheng-ben.md: -------------------------------------------------------------------------------- 1 | # 制造成本与运营成本 2 | 3 | 在本书的前四版中，成本指的是建造一台计算机的成本，价格指的是购买一台计算机的价格。随着包含数万台服务器的WSCs的出现，除了购买成本外，计算机的运营成本也很高。经济学家将这两项成本称为资本支出（CAPEX）和运营支出（OPEX）。 4 | 5 | 如第6章所示，假设IT设备的使用寿命较短，为3-4年，服务器和网络的摊销购买价格约为每月运营WSC成本的一半。大约40%的月度运营成本是用于电力使用和分配电力及冷却IT设备的摊销后的基础设施，尽管这些基础设施的摊销期为10-15年。因此，为了降低WSC的运营成本，计算机架构的设计者需要有效地使用能源。 6 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.6-cheng-ben-de-fa-zhan-qu-shi/README.md: -------------------------------------------------------------------------------- 1 | # 1.6 成本的发展趋势 2 | 3 | 尽管成本在某些计算机设计中往往不那么重要，特别是在超级计算机中，对成本敏感的设计越来越重要。事实上，在过去的35年里，利用技术改进来降低成本，以及提高性能，一直是计算机行业的一个主要主题。 4 | 5 | 教科书往往忽略了成本-性能的一半，因为成本会发生变化，从而使书本过时，而且这些问题很微妙，在不同的行业领域也有不同。然而，对于计算机架构的设计者来说，了解成本及其因素是至关重要的，这样才能做出明智的决定，在成本成为问题的情况下，是否应该在设计中加入新的功能。(你无法想象，建筑师在设计摩天大楼时，没有任何关于钢梁和混凝土的成本信息！）。 6 | 7 | 本节讨论了影响计算机成本的主要因素，以及这些因素如何随时间变化。 8 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.8-ping-ce-bao-gao-he-zong-jie-xing-neng/ji-zhun-ping-ce/zhuo-mian-ying-yong-ji-zhun.md: -------------------------------------------------------------------------------- 1 | # 桌面应用基准 2 | 3 | 桌面基准分为两大类：处理器密集型基准和图形密集型基准，尽管许多图形基准包括密集的处理器活动。SPEC最初创建了一个专注于处理器性能的基准集（最初称为SPEC89），它已经发展到第六代。SPEC CPU2017，继SPEC2006、SPEC2000、SPEC95 SPEC92和SPEC89之后。SPEC CPU2017由一组10个整数基准（CINT2017）和17个浮点基准（CFP2017）组成。图1.17描述了当前的SPEC CPU基准和它们的前辈。 4 | 5 | ![](../../../.gitbook/assets/NeatReader-1656341460740.png) 6 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.9-ji-suan-ji-liang-hua-she-ji-yuan-ze/ju-bu-xing-yuan-li.md: -------------------------------------------------------------------------------- 1 | # 局部性原理 2 | 3 | 重要的基本观察来自于程序的属性。我们经常利用的最重要的程序属性是局部性原理：程序倾向于重复使用它们最近使用过的数据和指令。一个被广泛接受的经验法则是，一个程序的90%的执行时间只花在10%的代码上。局部性的一个含义是，我们可以根据一个程序最近的访问情况，合理准确地预测它在不久的将来会使用哪些指令和数据。局部性原理也适用于数据访问，尽管不像代码访问那样强烈。 4 | 5 | 已经观察到两种不同类型的局部性。时间局部性说的是，最近访问的项目很可能很快就会被访问。空间局部性说的是，那些地址相近的目标往往在时间上被紧密地被引用。我们将在[第二章](../../di-er-zhang-nei-cun-ceng-ci-jie-gou-she-ji.md)看到这些原则的应用。 6 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.2-ji-suan-ji-de-lei-bie/zhuo-mian-ji-suan-ji.md: -------------------------------------------------------------------------------- 1 | # 桌面计算机 2 | 3 | 第一，也可能仍然是以美元计算的最大市场，是桌面计算机。桌面计算机包括从售价低于300美元的低端上网本到可能售价2500美元的高端、高度可配置的工作站。自2008年以来，每年生产的台式电脑中，有一半以上是配置了电池的笔记本电脑。台式计算机的销售正在下降。 4 | 5 | 在整个价格和能力范围内，台式机市场往往被驱动到优化性价比。系统的性能（主要以计算性能和图形性能来衡量）和价格的这种结合，对这个市场的客户来说是最重要的，因此对计算机的设计者来说也是如此。因此，最新的、性能最高的微处理器和成本较低的微处理器往往首先出现在桌面系统中（关于影响计算机成本的问题，见1.6节）。 6 | 7 | 台式计算在应用和基准测试方面也倾向于合理的特征，尽管越来越多的以网络为中心的交互式应用在性能评估方面带来了新的挑战。 8 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.3-ji-suan-ji-ti-xi-jie-gou-de-ding-yi/README.md: -------------------------------------------------------------------------------- 1 | # 1.3 计算机体系结构的定义 2 | 3 | 计算机设计者所面临的是一项复杂的任务：确定哪些属性对一台新的计算机来说是重要的，然后设计它。在成本、功率和可用性的限制下，最大限度地提高性能和能效。这项任务有很多方面，包括指令集设计、功能组织（译者注：计算机组成的各个部件）、逻辑电路的设计和实现。这些实现可能包括集成电路设计、封装、电源和冷却系统。优化设计需要熟悉非常广泛的技术，从编译器和操作系统到逻辑设计和封装。 4 | 5 | 几十年前，计算机体系结构这个词一般只指指令集设计。计算机设计的其他方面被称为实现，这往往暗示着实现是无趣的或不那么有挑战性的。 6 | 7 | 我们认为这种观点是不正确的。架构师或设计师的工作远不止指令集设计，项目其他方面的技术障碍很可能比指令集设计中遇到的障碍更具挑战性。在描述计算机架构师面临的这些更大的挑战之前，我们将快速回顾一下指令集架构。 8 | -------------------------------------------------------------------------------- /qian-yan/an-li-yan-jiu-yu-xi-ti.md: -------------------------------------------------------------------------------- 1 | # 案例研究与习题 2 | 3 | 每章最后都有案例研究和配套习题。案例研究由工业界和学术界的专家撰写，探讨了关键章节的概念，并通过越来越有挑战性的练习来验证理解。教授这门课程的老师们应该发现这些案例研究足够详细和有力，使他们能够创建自己的额外练习。 4 | 5 | 每个练习的括号（< chapter.section >）表示与完成该练习主要相关的文字部分。我们希望这能帮助读者避免他们没有读过相应章节的练习，此外还能提供复习的来源。练习是分级的，以使读者了解完成一项练习所需的时间： 6 | 7 | * \[10] 不到5分钟（阅读和理解）。 8 | * \[15] 5-15分钟可以答完。 9 | * \[20] 15-20分钟可以答完。 10 | * \[25] 完整的书面答案需要1小时。 11 | * \[30] 短期编程项目：少于1天的编程时间。 12 | * \[40] 重要的编程项目：2周的时间。 13 | * \[讨论] 与他人讨论的主题。 14 | 15 | 案例研究和习题答案可供在textbooks.elsevier.com注册的教师使用。 16 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.2-ji-suan-ji-de-lei-bie/README.md: -------------------------------------------------------------------------------- 1 | # 1.2 计算机的类别 2 | 3 | 这些变化为我们在这个新世纪如何看待计算、计算的应用和计算机市场的巨大变化创造了条件。自个人计算机诞生以来，我们从未见过计算机的出现方式和使用方式发生如此惊人的变化。计算机使用方面的这些变化导致了五个不同的计算市场，每个市场都有不同的应用、要求和计算技术的特点。图1.2总结了这些主流类别的计算环境及其重要特征。 4 | 5 | ![图1.2 五种主流计算类别及其系统特点的总结。 2015年的销售量包括约16亿台PMD（90%为手机），2.75亿台台式电脑，以及1500万台服务器。所销售的嵌入式处理器总数接近190亿。2015年，基于ARM技术的芯片总出货量为148亿。请注意服务器和嵌入式系统的系统价格差异很大，从USB钥匙到网络路由器。对于服务器来说，这一价格差异产生于对高端交易处理的非常大规模的多处理器系统的需求。](../../.gitbook/assets/NeatReader-1655971846641.png) 6 | 7 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/zhai-yao.md: -------------------------------------------------------------------------------- 1 | # 摘要 2 | 3 | 这一章介绍了一些概念，并提供了一个定量框架，在全书中得到了扩展。它解释了能效（ energy efficiency）是如何成为性能的新伙伴的，并包括能效、静态功率、动态功率、集成电路成本、可靠性和可用性的公式。 4 | 5 | ### 关键词 6 | 7 | Availability; Cluster; Computer architecture; Computer organization; Embedded computer; Energy efficiency; Graphics processing unit (GPU); Integrated circuit; Moore's law; Parallelism; Performance analysis; Price-quantitative analysis; Real-time performance; Reliability; Scalability; Soft real-time; Supercomputer; Throughput; Vector architecture; Warehouse-scale computers (WSCs) 8 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.9-ji-suan-ji-liang-hua-she-ji-yuan-ze/guan-zhu-chang-jian-qing-kuang.md: -------------------------------------------------------------------------------- 1 | # 关注常见情况 2 | 3 | 也许计算机设计中最重要和最普遍的原则是关注常见的情况：在进行设计权衡时，要偏向于经常发生的情况而不是不经常发生的情况。这个原则适用于决定如何花费资源，因为如果发生的情况很普遍，那么改进的影响就会更大。 4 | 5 | 注重常见情况对能耗以及资源分配和性能都是有利的。一个处理器的指令获取和解码单元的使用频率可能比乘法器高得多，所以要先优化它。它在可靠性方面也是有效的。如果一个数据库服务器每个处理器有50个存储设备，那么存储的可靠性将主导系统的可靠性。 6 | 7 | 此外，常见的情况往往比不常见的情况更简单，可以更快完成。例如，当在处理器中添加两个数字时，我们可以预期溢出是一种罕见的情况，因此可以通过优化更常见的无溢出的情况来提高性能。这种强调可能会减慢溢出发生的情况，但如果那是罕见的，那么通过对正常情况的优化，整体性能会得到提高。 8 | 9 | 在本文中，我们会看到很多这个原则的案例。在应用这个简单的原则时，我们必须决定什么是频繁的情况，以及通过使这种情况更快，可以提高多少性能。有一条基本定律，叫做阿姆达尔定律，可以用来量化这个原则。 10 | -------------------------------------------------------------------------------- /fu-lubnei-cun-ceng-ci-jie-gou-de-hui-gu/zhai-yao.md: -------------------------------------------------------------------------------- 1 | # 摘要 2 | 3 | 本附录是对内存层次结构的快速复习，包括缓存和虚拟内存的基础知识、性能方程和简单优化。 4 | 5 | ### 关键词 6 | 7 | Address trace; Average memory access time; Block; Block address; Block offset; Cache; Cache hit; Cache miss; Data cache; Direct mapped; Dirty bit; Fully associative; Hit time; Index field; Instruction cache; Least-recently used; Locality; Memory stall cycles; Miss penalty; Miss rate; Misses per instruction; No-write allocate; _n_-Way set associative; Page; Page fault; Random replacement; Set; Tag field; Unified cache; Valid bit; Virtual memory; Write allocate; Write back; Write buffer; Write stall; Write through 8 | -------------------------------------------------------------------------------- /qian-yan/wo-men-wei-shi-mo-xie-zhe-ben-shu.md: -------------------------------------------------------------------------------- 1 | # 我们为什么写这本书 2 | 3 | 在本书的六个版本中，我们的目标一直是描述未来技术发展的基本原则。我们对计算机体系结构中的存在的新机遇的兴奋没有减弱，我们重复我们在第一版中对该领域的评价。"这不是一门沉闷的毫无作用的纸上谈兵的学科。不是！它是一门具有敏锐洞察力的学科。它是一门具有浓厚智力兴趣的学科，需要市场力量对成本-性能-功率的平衡，导致光荣的失败和一些显著的成功"。 4 | 5 | 我们写第一本书的主要目的是改变人们学习和思考计算机架构的方式。我们觉得这个目标仍然有效和重要。这个领域每天都在变化，必须用真实的例子和在真实的计算机上的评测方式来研究，而不是简单地把它作为一个永远不需要实现的定义和设计的集合。我们对过去和我们一起走过的人以及现在加入我们的人表示热烈的欢迎。无论哪种方式，我们都可以承诺对真实系统采取同样的定量方法，并对其进行分析。 6 | 7 | 与以前的版本一样，我们努力使新版本继续面向专业工程师和架构师，就像它与那些参与高级计算机体系结构与设计课程的人一样。与第一版一样，本版重点关注新的平台--个人移动设备（PMD）和数据仓库规模的计算机--以及新的架构--具体而言，特定领域架构（DSA，Domain-Specific Architectures）。与前几版一样，本版旨在通过强调成本-性能-能耗的权衡和良好的工程设计来揭开计算机架构的神秘面纱。我们相信，该领域已经持续成熟，并朝着长期以来建立的科学和工程学科的严格定量基础发展。 8 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.2-ji-suan-ji-de-lei-bie/fu-wu-qi.md: -------------------------------------------------------------------------------- 1 | # 服务器 2 | 3 | 随着1980年代向桌面计算的转变，服务器的作用越来越大，以提供更大规模和更可靠的文件和计算服务。这样的服务器已经成为大规模企业计算的骨干，取代了传统的大型机。 4 | 5 | 对于服务器来说，不同的特性是很重要的。首先，可靠性是关键。(我们在第1.7节讨论可用性。)考虑一下运行银行ATM机或航空公司预订系统的服务器。这种服务器系统的故障远比单个台式机的故障更具灾难性，因为这些服务器必须每周7天，每天24小时运行。图1.3估计了服务器应用的停机时间的成本。 6 | 7 | ![图1.3 一个不可用的系统的成本四舍五入到100,000美元，是通过分析停机时间的成本（以立即损失的收入计算）来显示的，假设有三种不同的可用性水平，并且停机时间是均匀分布的。 这些数据来自Landstrom（2014），由应急计划研究公司收集和分析。](../../.gitbook/assets/NeatReader-1655973062512.png) 8 | 9 | 服务器系统的第二个关键特征是可扩展性。服务器系统经常随着对其支持的服务需求的增加或功能需求的扩大而增长。因此，扩大服务器的计算能力、内存、存储和I/O带宽的能力是至关重要的。 10 | 11 | 最后，服务器被设计成有效的吞吐量。也就是说，服务器的整体性能--以每分钟的交易量或每秒钟的网页服务量计算--才是关键所在。对单个请求的响应仍然很重要，但整体效率和成本效益，即在单位时间内可以处理多少个请求，是大多数服务器的关键指标。我们将在第1.8节回到评估不同类型的计算环境的性能问题。 12 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.2-ji-suan-ji-de-lei-bie/wu-lian-wang-qian-ru-shi-ji-suan-ji.md: -------------------------------------------------------------------------------- 1 | # 物联网/嵌入式计算机 2 | 3 | 嵌入式计算机存在于日常机器中：微波炉、洗衣机、大多数打印机、网络交换机和所有汽车。物联网（IoT）这一短语指的是通常以无线方式连接到互联网的嵌入式计算机。当与传感器和执行器（actuators，_译者注：或者翻译为功能部件更合适？_）结合在一起时，物联网设备收集有用的数据并与物理世界互动，从而产生了各种各样的 "智能 "应用，如智能手表、智能恒温器、智能扬声器、智能汽车、智能家居、智能电网和智能城市。 4 | 5 | 嵌入式计算机具有最广泛的处理能力和成本分布。它们包括可能只花一分钱的8位到32位处理器，以及用于汽车和网络交换机的高端64位处理器，价格为100美元。虽然嵌入式计算市场的计算能力范围非常大，但价格是该领域计算机设计的一个关键因素。当然，性能要求确实存在，但主要目标往往是以最低的价格满足性能需求，而不是以更高的价格实现更多的性能。对2020年物联网设备数量的预测从200亿到500亿不等。 6 | 7 | 本书的大部分内容适用于嵌入式处理器的设计、使用和性能，无论它们是现成的微处理器还是将与其他特殊用途硬件组装的微处理器内核。 8 | 9 | 不幸的是，驱动其他类别计算机的定量设计和评估的数据还没有成功地扩展到嵌入式计算（例如，见第1.8节中EEMBC的挑战）。因此，我们现在只剩下定性的描述，这与本书的其他部分并不相称。因此，嵌入式材料集中在[附录E](../../fu-lueqian-ru-shi-xi-tong.md)中。我们相信，单独的附录可以改善文中的思路，同时让读者看到不同的要求如何影响嵌入式计算。 10 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.2-ji-suan-ji-de-lei-bie/ge-ren-yi-dong-zhong-duan.md: -------------------------------------------------------------------------------- 1 | # 个人移动终端 2 | 3 | 个人移动终端（PMD）是我们适用于具有多媒体用户界面的无线设备的集合，如手机、平板电脑等。鉴于整个产品的消费价格为几百美元，成本是一个首要关注点。尽管对能效的强调经常是由电池的使用所驱动的，但需要使用较便宜的包装--塑料相对于陶瓷--以及没有冷却用的风扇也限制了总的电力消耗。我们在第1.5节中更详细地研究了能耗和功率的问题。在PMD上的应用通常是基于网络和面向媒体的，就像前面提到的谷歌翻译的例子。能耗和体积的要求导致使用闪存来存储（第2章），而不是使用磁盘。 4 | 5 | PMD中的处理器通常被认为是嵌入式计算机，但我们把它们作为一个单独的类别，因为PMD是可以运行外部开发的软件的平台，而且它们具有台式计算机的许多特征。其他的嵌入式设备在硬件和软件的复杂程度上都比较有限。我们用运行第三方软件的能力作为非嵌入式和嵌入式计算机的分界线。 6 | 7 | 高响应性和可预测性是媒体应用的关键特征。实时性能要求意味着应用程序的一个部分有一个绝对的最大执行时间。例如，在PMD上播放视频时，处理每一帧视频的时间是有限的，因为处理器必须接受并很快处理下一帧。在一些应用中，存在一个更细微的要求：一个特定任务的平均时间以及超过某个最大时间的实例数量都受到限制。这种方法--有时被称为软实时--出现在有可能偶尔错过一个事件的时间约束，只要不错过太多。实时性能往往是高度依赖应用的。 8 | 9 | 多PMD应用中的其他关键特征是需要尽量减少内存和需要有效地使用电源。能效问题是由电池电量和散热两方面驱动的。内存可能是系统成本的一个重要部分，在这种情况下，优化内存大小很重要。内存大小的重要性转化为对代码大小的重视，因为数据大小是由应用决定的。 10 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.9-ji-suan-ji-liang-hua-she-ji-yuan-ze/li-yong-bing-hang-hua-de-you-shi.md: -------------------------------------------------------------------------------- 1 | # 利用并行化的优势 2 | 3 | 利用并行性是提高性能的最重要方法之一。本书的每一章都有一个关于如何通过利用并行性来提高性能的例子。我们在这里举了三个简单的例子，在后面的章节中会对这些例子进行阐述。 4 | 5 | 我们的第一个例子是在系统层面上使用并行性。为了提高典型的服务器基准的吞吐性能，如SPECSFS或TPC-C，可以使用多个处理器和多个存储设备。然后，处理请求的工作量可以在处理器和存储设备之间分摊，从而提高吞吐量。能够扩大内存以及处理器和存储设备的数量被称为可扩展性，它是服务器的一项宝贵特性。将数据分散到许多存储设备上进行并行读写，可以实现数据级的并行性。SPECSFS也依靠请求级的并行性来使用许多处理器，而TPC-C则使用线程级的并行性来快速处理数据库查询。 6 | 7 | 在单个处理器的层面上，利用指令间的并行性是实现高性能的关键。做到这一点的最简单的方法之一是通过流水线。(流水线化在[附录C](../../fu-lucliu-shui-xian-chu-ji-he-zhong-ji-gai-nian.md)中有更详细的解释，也是[第三章](../../di-san-zhang-zhi-ling-ji-bing-hang-ji-qi-ying-yong.md)的一个重点）。流水线的基本思想是重叠执行指令，以减少完成一个指令序列的总时间。对流水线的一个重要认识是，并不是每条指令都依赖于它的直接前驱，所以完全或部分地并行执行指令是可能的。流水线是ILP的最著名的例子。 8 | 9 | 并行性也可以在详细的数字设计层面上被利用。例如，集合关联（set-associative）缓存使用多个内存banks，这些banks通常被并行搜索以找到所需的目标。算术逻辑单元使用carry-lookahead，它利用并行性来加快计算每个操作数之和的过程。加速的复杂度从线性级（N）下降到了对数级（logN）。还有更多关于数据级并行的例子。 10 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.4-ji-shu-qu-shi/jing-ti-guan-xing-neng-he-dao-xian-de-kuo-da.md: -------------------------------------------------------------------------------- 1 | # 晶体管性能和导线的扩大 2 | 3 | 集成电路工艺的特点是特征尺寸（feature size），即一个晶体管或线路在X或Y维度上的最小尺寸。特征尺寸从1971年的10微米下降到2017年的0.016微米；事实上，我们已经转换了单位，所以2017年的生产被称为 "16纳米"，而7纳米芯片正在进行中。由于每平方毫米硅的晶体管数量是由晶体管的表面积决定的，晶体管的密度随着特征尺寸的线性减少而呈平方增加。 4 | 5 | 然而，晶体管性能的提高则更为复杂。随着特征尺寸的缩小，器件在水平方向和纵向方向上都会变小。其中，水平方向呈平方倍率缩小。纵向尺寸的缩小需要降低工作电压，以保持晶体管的正确操作和可靠性。这种缩放因素的组合导致了晶体管性能和工艺特征尺寸之间复杂的相互关系。从第一个近似值来看，在过去，晶体管的性能是随着特征尺寸的减小而线性提高的。 6 | 7 | 晶体管数量随着晶体管性能的线性提高而呈平方级增加，这既是挑战，也是机遇，计算机架构设计者就是为之而生的! 在微处理器的早期，较高的密度改进率被用来快速从4位到8位，到16位，到32位，到64位微处理器。最近，密度的提高支持了每块芯片上多个处理器的引入，更广泛的SIMD单元，以及第2-5章中发现的许多推测执行和缓存方面的创新。 8 | 9 | 尽管晶体管的性能通常随着特征尺寸的减小而提高，但集成电路中的导线却没有。特别是，一根导线的信号延迟与它的电阻和电容的乘积成正比。当然，随着特征尺寸的缩小，导线变得更短，但每单位长度的电阻和电容却变得更糟。这种关系很复杂，因为电阻和电容都取决于工艺的细节方面、导线的几何形状、导线上的负载，甚至与其他结构的毗邻关系。偶尔会有一些工艺上的改进，如铜的引入，可以一次性改善导线的延迟。 10 | 11 | 然而，一般来说，与晶体管的性能相比，导线延迟（wire delay）的扩展性很差，给设计者带来额外的挑战。除了功率耗散的限制外，导线延迟已成为大型集成电路的主要设计障碍，而且往往比晶体管开关延迟更为关键。时钟周期中越来越大的部分已经被信号在导线上的传播延迟所消耗，但现在功率所起的作用甚至比导线延迟还要大。 12 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.4-ji-shu-qu-shi/xing-neng-qu-shi-dai-kuan-de-ti-sheng-da-yu-yan-chi.md: -------------------------------------------------------------------------------- 1 | # 性能趋势：带宽的提升大于延迟 2 | 3 | 正如我们将在第1.8节中看到的，带宽或吞吐量是在一定时间内完成的工作总量，如磁盘传输的MB/s。相比之下，延迟或响应时间是事件开始和完成之间的时间，比如磁盘访问的毫秒。图1.9显示了微处理器、内存、网络和磁盘的技术里程碑在带宽和延迟方面的相对改进。图1.10更详细地描述了这些例子和里程碑。 4 | 5 | ![图1.9 图1.10中带宽和延迟的里程碑相对于第一个里程碑的对数图。 请注意，延迟提高了8-91倍，而带宽提高了约400-32,000倍。除了网络，我们注意到，自上一版以来的六年中，其他三种技术的延迟和带宽都有适度的改善。延迟为0%-23%，带宽为23%-70%。更新自Patterson, D., 2004. 延迟落后于带宽。【引用自ACM通讯 47 (10), 71-75。】](../../.gitbook/assets/NeatReader-1656042175346.png) 6 | 7 | ![微处理器、内存、网络和磁盘在25-40年内的性能里程碑。 微处理器的里程碑是几代IA-32处理器，从16位总线、微编码80286到64位总线、多核、乱序执行、超流水线（superpipelined）的Core i7。内存模块的里程碑，从16位宽的普通DRAM到64位宽的双数据率第三版同步DRAM。以太网从10 Mbits/s推进到400 Gbits/s。磁盘的里程碑是基于旋转速度，从3600转/分提高到15000转/分。每种情况都是最佳的带宽，而延迟是假设没有竞争的简单操作的时间。更新自Patterson, D., 2004. 延迟落后于带宽。](../../.gitbook/assets/NeatReader-1656042513762.png) 8 | 9 | 性能是微处理器和网络的主要区别因素，因此它们的收益最大。带宽提高了32,000-40,000倍，延迟提高了50-90倍。对于内存和磁盘来说，容量通常比性能更重要，所以容量的提高更多，但400-2400倍的带宽进步仍然比8-9倍的延迟进步大得多。 10 | 11 | 显然，在这些技术中，带宽已经超过了延迟，而且可能会继续这样做。一个简单的经验法则是，带宽的增长至少是延时改进的平方。计算机设计者应该据此制定计划。 12 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.6-cheng-ben-de-fa-zhan-qu-shi/shi-jian-shu-liang-he-shang-pin-hua-de-ying-xiang.md: -------------------------------------------------------------------------------- 1 | # 时间、数量和商品化的影响 2 | 3 | 即使在基本实现技术（译者注：大规模集成电路的生产工艺和技术）没有重大改进的情况下，计算机部件的制造成本也会随着时间的推移而降低。促使成本下降的基本原则是学习曲线--制造成本随着时间的推移而降低。学习曲线本身最好用产量的变化来衡量--在测试过程中幸存下来的制造的器件百分比。无论是芯片、电路板还是系统，具有两倍产量的设计将具有一半的成本。 4 | 5 | 了解学习曲线是如何提高良品率的，对于预测产品生命周期的成本至关重要。一个例子是，每兆字节的DRAM价格长期以来一直在下降。由于DRAM的价格往往与成本密切相关--除非在短缺或供应过剩的时期，DRAM的价格和成本密切相关。 6 | 7 | 微处理器的价格也随着时间的推移而下降，但由于它们的标准化程度不如DRAM，价格和成本之间的关系更加复杂。在竞争激烈的时期，价格往往密切跟踪成本，尽管微处理器供应商可能很少亏本销售。 8 | 9 | 数量是决定成本的第二个关键因素。数量的增加在几个方面影响成本。首先，它们减少了通过学习曲线所需的时间，这部分地与生产的系统（或芯片）数量成正比。第二，数量的增加降低了成本，因为它提高了采购和制造效率。作为一个经验法则，一些设计者估计，数量每增加一倍，成本就会降低10%左右。此外，数量减少了每台计算机必须摊销的开发成本，从而使成本和销售价格更接近，并仍然有利润。 10 | 11 | 商品是由多个供应商大量销售的产品，而且基本上是相同的。几乎所有在杂货店货架上出售的产品都是商品，标准DRAM、闪存、显示器和键盘也是如此。在过去的30年里，个人电脑行业的大部分产品已经成为一种商品，集中在制造运行微软Windows台式电脑和笔记本电脑。 12 | 13 | 由于许多供应商提供几乎相同的产品，市场竞争非常激烈。当然，这种竞争减少了成本和销售价格之间的差距，但它同时也减少了成本。削减的发生是因为商品市场既有数量，又有明确的产品定义，这使得多个供应商在为商品产品制造部件方面进行竞争。因此，由于部件供应商之间的竞争和供应商可以实现的数量效率，整体产品成本降低。这种竞争导致计算机业务的低端产品能够实现比其他部门更好的性价比，并在低端产品中产生更大的增长，尽管利润非常有限（正如任何商品业务的典型情况）。 14 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.5-ji-cheng-dian-lu-zhong-gong-shuai-he-neng-hao-de-fa-zhan-qu-shi/you-yu-neng-hao-de-xian-zhi-ji-suan-ji-jia-gou-de-zhuan-bian.md: -------------------------------------------------------------------------------- 1 | # 由于能耗的限制，计算机架构的转变 2 | 3 | 随着晶体管改进速度的减慢，计算机设计师必须从其他地方寻找改进的能源效率。事实上，考虑到能源预算，今天很容易设计出具有如此多晶体管的微处理器，以至于它们无法同时开启。这种现象被称为 "暗硅"，即由于热限制，芯片的大部分在任何时候都不能被使用（"暗"）。这一观察促使建筑师们重新审视处理器设计的基本原理，以寻求更高的能源成本性能。 4 | 5 | 图1.13列出了现代计算机构件的能量成本和面积成本，显示了令人惊讶的大比率。例如，32位浮点加法的能耗是8位整数加法的30倍。面积差异甚至更大，为60倍。然而，最大的差异是在内存方面；32位DRAM访问所需的能量是8位加法的2万倍。一个小型的SRAM比DRAM的能量效率高125倍，这表明谨慎使用缓存和内存缓冲器的重要性。 6 | 7 | ![图 1.13 Comparison of the energy and die area of arithmetic operations and energy cost of accesses to SRAM and DRAM. 8 | \[Azizi\]\[Dally\]. Area is for TSMC 45 nm technology node.](../../.gitbook/assets/NeatReader-1656054748201.png) 9 | 10 | 每个任务能量最小化的新设计原则与图1.13中的相对能量和面积成本相结合，激发了计算机体系结构的新方向，我们将在[第七章](../../di-qi-zhang-ling-yu-te-ding-jia-gou-dsa.md)介绍。特定领域的处理器通过减少宽泛的浮点运算和部署特殊用途的存储器以减少对DRAM的访问来节省能量。它们利用这些节省的能量来提供比传统处理器多10-100个（更窄的）整数运算单元。虽然这种处理器只执行有限的任务，但它们执行这些任务的速度明显比通用处理器快，而且更节能。 11 | 12 | 就像医院里有普通医生和医疗专家一样，在这个能源意识的世界里，计算机很可能是可以执行任何任务的通用内核和能极好地完成少数事情甚至更便宜的特殊用途内核的组合。 13 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.2-ji-suan-ji-de-lei-bie/ji-qun-shu-ju-cang-ku-gui-mo-de-ji-suan-ji.md: -------------------------------------------------------------------------------- 1 | # 集群/数据仓库规模的计算机 2 | 3 | 用于搜索、社交网络、视频观看和分享、多人游戏、在线购物等应用的软件即服务（SaaS）的增长，导致了一类被称为集群的计算机的增长。集群是台式电脑或服务器的集合，通过局域网连接，作为一个单一的大型计算机。每个节点都运行自己的操作系统，各节点使用网络协议进行通信。WSCs是最大的集群，因为它们的设计使数以万计的服务器可以作为一个整体行动。[第六章](../../di-liu-zhang-da-gui-mo-shu-ju-zhong-xin-ji-ji-suan-ji-de-bing-hang-xing-qing-qiu-ji-bing-hang-rlp-he.md)介绍了这一类超大型计算机。 4 | 5 | 由于WSCs如此之大，其性价比和功耗对它们来说至关重要。正如第6章所解释的，仓库的大部分成本都与仓库内的计算机的电力和冷却有关。一个世界服务中心每年摊销的计算机本身和网络设备的成本是4000万美元，因为它们通常每隔几年就会被更换。当你购买这么多的计算设备时，你需要明智地购买，因为性价比提高10%意味着每个WSC每年可以节省400万美元（4000万美元的10%）；像亚马逊这样的公司可能有100个WSCs! 6 | 7 | WSCs与服务器有关，因为可靠性很关键。例如，Amazon.com在2016年有1360亿美元的销售额。由于一年中大约有8800个小时，每小时的平均收入约为1500万美元。在圣诞购物的高峰时段，潜在的损失会高出许多倍。正如[第6章](../../di-liu-zhang-da-gui-mo-shu-ju-zhong-xin-ji-ji-suan-ji-de-bing-hang-xing-qing-qiu-ji-bing-hang-rlp-he.md)所解释的，WSCs和服务器之间的区别在于，WSCs使用冗余的、廉价的组件作为构建模块，依靠软件层来捕捉和隔离这种规模的计算会发生的许多故障，以提供这种应用所需的可用性。请注意，WSC的可扩展性是由连接计算机的局域网处理的，而不是像服务器那样由集成的计算机硬件处理。 8 | 9 | 超级计算机与WSCs有关，因为它们同样昂贵，耗资数亿美元，但超级计算机的不同之处在于强调浮点性能和运行大型的、通信密集型的批处理程序，可以一次运行数周。相比之下，WSCs强调交互式应用、大规模存储、可靠性和高互联网带宽。 10 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.8-ping-ce-bao-gao-he-zong-jie-xing-neng/README.md: -------------------------------------------------------------------------------- 1 | # 1.8 评测、报告和总结性能 2 | 3 | 当我们说一台电脑比另一台电脑快时，我们是什么意思？手机用户可能会说，当程序运行的时间更短时，电脑就更快，而亚马逊网站的管理员可能会说，当电脑每小时完成更多的交易时，电脑就更快。手机用户希望减少响应时间，即事件开始和完成之间的时间，也被称为执行时间。WSC的操作员希望增加吞吐量--在一定时间内完成的工作总量。 4 | 5 | 在比较设计方案时，我们经常想把两台不同的计算机的性能联系起来，比如说X和Y。"X比Y快 "这句话在这里的意思是，对于给定的任务，X上的响应时间或执行时间比Y上低。特别是，"X比Y快n倍 "将意味着： 6 | 7 | ![](../../.gitbook/assets/NeatReader-1656324054606.png) 8 | 9 | 由于执行时间是性能的倒数，以下关系成立： 10 | 11 | ![](../../.gitbook/assets/NeatReader-1656324098695.png) 12 | 13 | "X的吞吐量是Y的1.3倍 "这句话在这里表示，在计算机X上每单位时间完成的任务数是Y上完成的1.3倍。 14 | 15 | 不幸的是，在比较计算机的性能时，时间并不总是被引用的指标。我们的立场是，衡量性能的唯一一致和可靠的标准是真实程序的执行时间，所有提议的替代时间作为衡量标准，或替代真实程序作为衡量项目的方法，最终都导致了误导性的决策，是计算机设计中的错误。 16 | 17 | 即使是执行时间也可以用不同的方式来定义，这取决于我们计算的内容。最直接的时间定义被称为壁钟时间（wall-clock time）、响应时间（response time）或耗时（elapsed time），它是完成一项任务的延迟，包括存储访问、内存访问、输入/输出活动、操作系统开销等等。在多程序（multiprogramming）执行中，处理器在等待I/O的同时还在另一个程序上工作，不一定能将一个程序的耗时降到最低。因此，我们需要一个术语来考虑这种活动。**CPU时间**体现了这一区别，它表示处理器正在计算的时间，不包括等待I/O或运行其他程序的时间。(显然，用户看到的响应时间是程序的耗费时间，而不是CPU时间）。 18 | 19 | 经常运行相同程序的计算机用户将是评估一台新计算机的最佳人选。为了评估一个新的系统，这些用户将简单地比较他们的工作负载（workloads）的执行时间--用户在计算机上运行的程序和操作系统命令的集合。然而，很少有人处于这种幸福的境地。大多数人必须依靠其他方法来评估计算机，而且往往是这些人，希望这些方法能够预测他们使用新计算机的性能。一种方法是基准程序（benchmark programs），这是许多公司用来建立其计算机的相对性能的程序。 20 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.5-ji-cheng-dian-lu-zhong-gong-shuai-he-neng-hao-de-fa-zhan-qu-shi/dian-yuan-he-neng-hao-yi-ge-xi-tong-de-shi-jiao.md: -------------------------------------------------------------------------------- 1 | # 电源和能耗，一个系统的视角 2 | 3 | 系统架构师或用户应该如何考虑性能、功率和能源问题？从一个系统设计者的角度来看，有三个主要的关注点。 4 | 5 | 首先，一个处理器需要的最大功率是多少？满足这一需求对确保正确的操作是很重要的。例如，如果一个处理器试图吸取超过电源系统所能提供的功率（通过吸取超过系统所能提供的电流），其结果通常是电压下降，这可能导致设备发生故障。现代处理器在峰值电流较高的情况下，功耗会有很大的变化；因此，它们提供了电压指数方法（voltage indexing methods），允许处理器放慢速度并在较宽的范围内并调节电压。很明显，这样做会降低性能。 6 | 7 | 第二，什么是持续功耗？这个指标被广泛称为热设计功率（Thermal Design Power ，TDP），因为它决定了冷却要求。TDP既不是峰值功率，它通常是1.5倍，也不是在某次计算中实际消耗的平均功率，它可能更低。一个系统的典型电源的尺寸通常要超过TDP，而冷却系统的设计通常要符合或超过TDP。如果不能提供足够的冷却，将使处理器的结温超过其最大值，导致设备故障，并可能造成永久性损坏。因为最高功率（因此热量和温升）可能超过TDP规定的长期平均值，现代处理器提供了两个功能来协助管理过热：首先，当热温度接近极限时，电路会降低时钟速率，从而降低功率。如果这种技术不成功，第二个热过载陷阱（trap）就会被激活，使芯片断电。 8 | 9 | 设计师和用户需要考虑的第三个因素是能耗和能效。回顾一下，功率只是每单位时间的能量：1瓦=1焦耳/秒。哪一个指标是比较处理器的正确指标：能量还是功率？一般来说，能量总是一个更好的指标，因为它与特定的任务和该任务所需的时间相联系。特别是，完成一项工作负载的能量等于平均功率乘以工作负载的执行时间。 10 | 11 | 因此，如果我们想知道两个处理器中哪一个对给定的任务更有效，我们需要比较执行任务的能量消耗（而不是功率）。例如，处理器A的平均功耗可能比处理器B高20%，但如果A执行任务的时间仅为B所需时间的70%，其能耗将是1.2×0.7=0.84，这显然是更好。 12 | 13 | 有人可能会说，在大型服务器或云中，考虑平均功率就足够了，因为工作负载通常被假定为无限大，但这是一种误导。如果我们的云端都是处理器B，而不是A，那么在消耗相同能量的情况下，云所做的工作会更少。使用能量来比较替代方案可以避免这个陷阱。只要我们有一个固定的工作负载，无论是仓库规模的云还是智能手机，比较能量将是比较计算机替代品的正确方式，因为云的电费和智能手机的电池寿命都是由消耗的能量决定的。 14 | 15 | 什么时候耗电量是一个有用的衡量标准？主要的合法用途是作为一种约束：例如，一个依靠空气散热的芯片可能被限制在100W。如果工作负载是固定的，它可以作为一个指标，但那时它只是每个任务的能量的真正指标变化。 16 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.8-ping-ce-bao-gao-he-zong-jie-xing-neng/ji-zhun-ping-ce/fu-wu-qi-ying-yong-ji-zhun.md: -------------------------------------------------------------------------------- 1 | # 服务器应用基准 2 | 3 | 就像服务器有多种功能一样，基准也有多种类型。最简单的基准可能是面向处理器吞吐量的基准。SPEC CPU2017使用SPEC CPU基准来构建一个简单的吞吐量基准，通过运行每个SPEC CPU基准的多个副本（通常有多少个处理器就有多少个）并将CPU时间转换为速率，可以测量多处理器的处理率。这被称为SPECRate度量。它是第1.2节中对请求级并行性的测量。为了评估线程级的并行性，SPEC提供了他们所谓的围绕OpenMP和MPI以及GPU等加速器的高性能计算基准（见图1.18）。 4 | 5 | 除了SPECrate之外，大多数服务器应用和基准都有大量的I/O活动，这些活动来自于存储或网络流量，包括文件服务器系统、网络服务器以及数据库和交易处理系统的基准。SPEC提供了一个文件服务器基准（SPECSFS）和一个Java服务器基准。([附录D](../../../fu-ludcun-chu-xi-tong.md)详细讨论了一些文件和I/O系统的基准。) SPECvirt\_Sc2013评估了虚拟化数据中心服务器的端到端性能。另一个SPEC基准测量功率，我们在第1.10节中研究。 6 | 7 | 交易处理（TP）基准衡量系统处理由数据库访问和更新组成的交易的能力。航空预订系统和银行ATM系统是典型的简单的TP例子；更复杂的TP系统涉及复杂的数据库和决策。在20世纪80年代中期，一群相关的工程师组成了独立于供应商的交易处理委员会（TPC），试图为TP创建现实和公平的基准。TPC的基准描述在http://www.tpc.org。 8 | 9 | 第一个TPC基准，TPC-A，发表于1985年，此后被几个不同的基准所取代和加强。TPC-C，最初创建于1992年，模拟了一个复杂的查询环境。TPC-H模拟临时决策支持--查询是不相关的，过去的查询知识不能用于优化未来的查询。TPC-DI基准是一项新的数据集成（DI）任务，也被称为ETL，是数据仓库的一个重要组成部分。TPC-E是一个在线交易处理（OLTP）的工作负载，模拟了一个经纪公司的客户账户。 10 | 11 | 认识到传统关系型数据库和 "无SQL "存储解决方案之间的争议，TPCx-HS测量使用Hadoop文件系统运行MapReduce程序的系统，而TPC-DS测量使用关系型数据库或基于Hadoop系统的决策支持系统。TPC-VMS和TPCx-V测量虚拟化系统的数据库性能，而TPC-Energy为所有现有的TPC基准增加了能耗指标。 12 | 13 | 所有的TPC基准都是以每秒的交易量来衡量性能。此外，它们还包括一个响应时间要求。只有在满足响应时间限制的情况下才会测量吞吐量性能。为了模拟真实世界的系统，较高的交易率也与较大的系统有关，在用户和应用交易的数据库方面都是如此。最后，基准系统的系统成本也必须包括在内，以便对性价比进行准确比较。TPC修改了它的定价政策，使所有的TPC基准都有一个统一的规范，并允许对TPC公布的价格进行核查。 14 | -------------------------------------------------------------------------------- /qian-yan/yue-du-dao-lan.md: -------------------------------------------------------------------------------- 1 | # 阅读导览 2 | 3 | 在阅读这些章节和附录时，没有单一的最佳顺序，只是所有读者都应该从第一章开始。如果你不想全部读完，这里有一些建议的顺序： 4 | 5 | * 内存层次结构：[附录B](../fu-lubnei-cun-ceng-ci-jie-gou-de-hui-gu/)，[第二章](../di-er-zhang-nei-cun-ceng-ci-jie-gou-she-ji.md)，[附录D](../fu-ludcun-chu-xi-tong.md)和[M](../fu-lumli-shi-guan-dian-he-can-kao-wen-xian.md)。 6 | * 指令级并行：[附录C](../fu-lucliu-shui-xian-chu-ji-he-zhong-ji-gai-nian.md)，[第三章](../di-san-zhang-zhi-ling-ji-bing-hang-ji-qi-ying-yong.md)和[附录H](../fu-lu-hvliw-he-epic-de-ying-jian-he-ruan-jian.md)。 7 | * 数据级并行：[第四](../di-si-zhang-shi-liang-simd-he-gpu-jia-gou-zhong-de-shu-ju-ji-bing-hang-xing.md)，[六](../di-liu-zhang-da-gui-mo-shu-ju-zhong-xin-ji-ji-suan-ji-de-bing-hang-xing-qing-qiu-ji-bing-hang-rlp-he.md)，[七章](../di-qi-zhang-ling-yu-te-ding-jia-gou-dsa.md)，[附录G](../fu-lugshen-ru-xiang-liang-chu-li-qi.md)。 8 | * 线程级并行：[第五章](../di-wu-zhang-xian-cheng-ji-bing-hang.md)，[附录F](../fu-lufduo-ji-hu-lian.md)和[I](../fu-luida-gui-mo-duo-chu-li-qi-he-ke-xue-ji-suan-de-ying-yong.md)。 9 | * 请求级并行（RLP）:[第六章](../di-liu-zhang-da-gui-mo-shu-ju-zhong-xin-ji-ji-suan-ji-de-bing-hang-xing-qing-qiu-ji-bing-hang-rlp-he.md)。 10 | * ISA：[附录A](../fu-luazhi-ling-ji-she-ji-yuan-ze.md)和[K](../fu-lukzhi-ling-ji-jia-gou-de-hui-gu.md)。 11 | 12 | [附录E](../fu-lueqian-ru-shi-xi-tong.md)可以在任何时候阅读，但如果在ISA和缓存序列之后阅读可能效果最好。如果你对计算机算术感兴趣，可以阅读[附录J](../fu-lujji-suan-ji-suan-shu-arithmetic-xiang-guan.md)。你应该在完成每一章后阅读[附录M](../fu-lumli-shi-guan-dian-he-can-kao-wen-xian.md)的相应部分。 13 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.3-ji-suan-ji-ti-xi-jie-gou-de-ding-yi/ming-fu-qi-shi-de-ji-suan-ji-ti-xi-jie-gou-she-ji-zu-zhi-organization-he-ying-jian-yi-man-zu-she-ji.md: -------------------------------------------------------------------------------- 1 | # 名副其实的计算机体系结构：设计组织（Organization）和硬件以满足设计指标和功能需求 2 | 3 | 计算机的实现有两个组成部分：组织和硬件。组织（organization）一词包括计算机设计的高层次方面，如内存系统、内存之间的互联方式，以及内部处理器或CPU（中央处理单元--实现算术、逻辑、分支和数据传输的地方）的设计。微架构（microarchitecture）这一术语也被用来代替组织结构。例如，两个具有相同指令集架构但不同组织的处理器是AMD Opteron和Intel Core i7。两种处理器都实现了80 x 86指令集，但它们的流水线和高速缓存组织非常不同。 4 | 5 | 每个微处理器包含多个处理器后，导致核心（core）一词也被用于处理器。与其说多处理器微处理器（multiprocessor microprocessor）这样拗口的词，不如使用多核（multicore），这使得这个词流行起来。鉴于几乎所有的芯片都有多个处理器，中央处理器（CPU）这一术语正在逐渐消失。 6 | 7 | 硬件是指计算机的具体细节，包括计算机的详细逻辑设计和包装技术。通常一个计算机系列包含具有相同指令集架构和非常相似组织的计算机，但它们在详细的硬件实现方面有所不同。例如，Intel Core i7（见[第三章](../../di-san-zhang-zhi-ling-ji-bing-hang-ji-qi-ying-yong.md)）和Intel Xeon E7（见[第五章](../../di-wu-zhang-xian-cheng-ji-bing-hang.md)）几乎相同，但提供了不同的时钟速率和不同的内存系统，使得Intel Xeon E7对服务器计算机更有效。 8 | 9 | 在本书中，架构（architecture）一词涵盖了计算机设计的所有三个方面--指令集架构（ISA）、组织或微架构，以及硬件。 10 | 11 | 计算机架构的设计者必须设计一台计算机来满足功能要求以及价格、功耗、性能和可用性目标。图1.8总结了在设计一台新计算机时需要考虑的要求。通常，架构设计者还必须确定什么是功能需求，这可能是一项重要的任务。这些要求可能是由市场激发的具体功能。应用软件通常通过确定计算机的使用方式来推动对某些功能需求的选择。如果一个特定的指令集结构存在大量的软件，设计者可能会决定新的计算机应该实现一个现有的（译者注：广泛部署的）指令集。如果某一类应用存在一个巨大的市场，可能会鼓励设计者加入一些要求，使计算机在该市场上具有竞争力。后面的章节将深入研究这些要求和功能。 12 | 13 | ![图1.8 设计者面临的一些最重要的功能需求的总结。 左栏描述了需求的类别，而右栏给出了具体的例子。右边一栏还包含了对处理具体问题的章节和附录的参考。](../../.gitbook/assets/NeatReader-1656038704682.png) 14 | 15 | 设计者还必须了解技术和计算机使用方面的重要趋势，因为这种趋势不仅影响到未来的成本，而且还影响到设计的架构的寿命。 16 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.8-ping-ce-bao-gao-he-zong-jie-xing-neng/ji-zhun-ping-ce/README.md: -------------------------------------------------------------------------------- 1 | # 基准评测 2 | 3 | 衡量性能的最佳基准选择是真实的应用程序，例如第1.1节中提到的谷歌翻译。试图运行比实际应用简单得多的程序已经导致了性能上的缺陷。这方面的例子包括 4 | 5 | * 内核，它是实际应用中的小的、关键的部分。 6 | * 玩具程序，这是初级编程作业中的100行程序，例如Quicksort。 7 | * 合成基准，这是发明的假程序，试图与真实应用程序的运行情况和行为相匹配，如Dhrystone。 8 | 9 | 今天，这三种方法都是不可靠的，通常是因为编译器作者和架构师可以合谋使计算机在这些替身程序上显得比在真实的应用程序上更快。遗憾的是，你们的作者--在本书第四版中放弃了关于使用合成基准来描述性能的谬论，因为我们认为所有的计算机架构师都认为这是不可靠的--合成程序Dhrystone在2017年仍然是嵌入式处理器最广泛引用的基准! 10 | 11 | 另一个问题是基准测试的运行条件。提高基准性能的一种方法是使用特定于基准的编译器标志；这些标志往往会引起在许多程序上不合法的转换，或者会减慢其他程序的性能。为了限制这一过程并提高结果的重要性，基准开发人员通常要求供应商对同一语言（如C++或C）的所有程序使用一个编译器和一组标志。除了编译器标志的问题外，另一个问题是是否允许修改源代码。有三种不同的方法来回答这个问题： 12 | 13 | 1. 不允许修改源代码。 14 | 2. 允许修改源代码，但基本上是不可能的。例如，数据库基准依赖于标准的数据库程序，这些程序有数千万行的代码。数据库公司极不可能为提高一台特定计算机的性能而进行修改。 15 | 3. 允许修改源代码，只要修改后的版本产生相同的输出。 16 | 17 | 基准设计者在决定允许修改源代码时面临的关键问题是，这种修改是否会反映真实的实践并为用户提供有用的观察（insight），或者这些修改是否只是降低了基准作为真实性能预测器的准确性。正如我们将在第7章中看到的那样，特定领域架构的设计师在为定义明确的任务创建处理器时，常常遵循第三种选择。 18 | 19 | 为了克服把太多的鸡蛋放在一个篮子里的危险，基准应用程序的集合，称为基准套件，是衡量具有各种应用的处理器的性能的流行方法。当然，这样的集合只会和它的组成部分——单个基准一样好。尽管如此，这种套件的一个关键优势是，任何一个基准的弱点都会因为其他基准的存在而有所缓解。基准套件的目标是，它将描述两台计算机的实际相对性能，特别是对于客户可能运行的不在套件中的程序。 20 | 21 | 一个值得警惕的例子是《电子设计新闻》的嵌入式微处理器基准联盟（Electronic Design News Embedded Microprocessor Benchmark Consortium，EEMBC，发音为 "大使馆"）的基准。 22 | 23 | 它是一套拥有41个内核（kernel）测试的基准，用于预测不同的嵌入式应用的性能：汽车/工业、消费、网络、办公自动化和电信。EEMBC报告了未经修改的性能和 "full fury "的性能，在这种情况下几乎什么（修改）都能做。由于这些基准使用小内核，并且由于报告选项，EEMBC并不具有很好的预测现场不同嵌入式计算机的相对性能的声誉。这种不成功是EEMBC试图取代的Dhrystone仍然被使用的原因，令人遗憾。 24 | 25 | 创建标准化基准应用套件的最成功的尝试之一是SPEC（标准性能评估公司），它起源于20世纪80年代末为工作站提供更好的基准的努力。正如计算机行业随着时间的推移而发展一样，对不同的基准套件的需求也是如此，现在有SPEC基准来覆盖许多应用类别。所有的SPEC基准套件和它们的报告结果都可以在http://www.spec.org。 26 | 27 | 尽管我们在下面的许多章节中集中讨论了SPEC基准，但许多基准也是为运行Windows操作系统的PC开发的。 28 | 29 | 30 | 31 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.8-ping-ce-bao-gao-he-zong-jie-xing-neng/zong-jie-xing-neng-jie-guo.md: -------------------------------------------------------------------------------- 1 | # 总结性能结果 2 | 3 | 在实际的计算机设计中，人们必须评估无数的设计选择，以确定它们在一系列被认为是相关的基准中的相对的量化测试结果的收益。同样地，试图选择计算机的消费者将依赖于来自基准的性能评测，这些基准最好与用户的应用相似。在这两种情况下，拥有一套基准的测量结果是很有用的，这样重要的应用程序的性能就会与这套基准中的一个或多个基准相似，这样就可以理解性能的变化。在最好的情况下，该套件类似于应用空间的一个统计学上的有效样本，但这样的样本需要比大多数套件中通常发现的更多的基准，并且需要随机抽样，而基本上没有基准套件使用这种方法。 4 | 5 | 一旦我们选择用一个基准套件来测量性能，我们希望能够用一个独特的数字来总结该套件的性能结果。计算总结结果的一个简单方法是比较套件中程序的执行时间的算术平均值。另一种方法是给每个基准添加一个加权因子，并使用加权算术平均值作为总结性能的单一数字。一种方法是使用权重，使所有程序在某些参考计算机上的执行时间相等，但这使结果偏向于参考计算机的性能特征。 6 | 7 | 与其选择权重，我们可以通过将参考计算机上的时间除以被评测计算机上的时间来使执行时间规范化（normalization），从而产生一个与性能成正比的比率。SPEC采用了这种方法，将该比率称为SPECRatio。它有一个特别有用的属性，与我们在本文中对计算机性能进行基准测试的方式相匹配，即比较性能比率。例如，假设计算机A在一项基准测试中的SPECRatio是计算机B的1.25倍；那么我们知道： 8 | 9 | ![](../../.gitbook/assets/NeatReader-1656383901164.png) 10 | 11 | 请注意，参考计算机上的执行时间下降了，当以比率进行比较时，参考计算机的选择是不相关的，这也是我们一贯使用的方法。图1.19给出了一个例子： 12 | 13 | ![图1.19 Sun Ultra 5--SPEC2006的参考计算机的SPEC2006Cint执行时间（秒）以及AMD A10和Intel Xeon E5-2690的执行时间和SPEC比率。 最后两栏显示了执行时间和SPECRate的比率。该图显示了参考计算机在相对性能方面的无关性。执行时间的比率与SPECRate的比率相同，几何平均值的比率（63.7231.91/20.86=2.00）与比率的几何平均值（2.00）相同。第1.11节讨论了libquantum，其性能比其他SPEC基准高几个数量级。](../../.gitbook/assets/NeatReader-1656383984531.png) 14 | 15 | 因为SPECRatio是一个比率，而不是一个绝对的执行时间，所以必须使用几何平均数来计算平均值。(因为SPECRatios没有单位，用算术方法比较SPECRatios是没有意义的）。该公式为： 16 | 17 | ![](../../.gitbook/assets/NeatReader-1656384759539.png) 18 | 19 | 在SPEC的情况下，$$sample_i$$是程序i的SPECRatio。使用几何平均数可以确保两个重要的特性： 20 | 21 | 1. 比率的几何平均值与几何平均值的比率相同。 22 | 2. 几何平均数的比率等于性能比率的几何平均数，这意味着参考计算机的选择是不相关的。 因此，使用几何平均数的动机是很大的，特别是当我们使用性能比来进行比较时。 23 | 24 | **示例**：证明几何平均值的比率等于性能比率的几何平均值，并说明SPECRatio的参考计算机并不重要。 25 | 26 | **答案**：假设有两台计算机A和B，每台都有一组SPECRatios： 27 | 28 | ![](../../.gitbook/assets/NeatReader-1656385548291.png) 29 | 30 | 也就是说，A和B的SPECRatios的几何平均值的比率是套件中所有基准的A对B的性能比率的几何平均值。图1.19用SPEC的例子证明了这种有效性。 31 | 32 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.2-ji-suan-ji-de-lei-bie/bing-hang-xing-he-bing-hang-jia-gou-de-lei-bie.md: -------------------------------------------------------------------------------- 1 | # 并行性和并行架构的类别 2 | 3 | 多层次的并行性现在是所有四类计算机设计的驱动力，能源和成本是主要的制约因素。应用中基本上有两种并行性： 4 | 5 | 1. 数据级并行（Data-Level Parallelism_,_ DLP）的产生是因为有许多数据项可以同时被操作。 6 | 2. 任务级并行（Task-Level Parallelism_,_ TLP）的产生是因为工作任务的产生，这些任务可以独立运行，而且基本上是并行的。 7 | 8 | 计算机硬件又可以通过四种主要方式利用这两种应用并行性： 9 | 10 | 1. 指令级并行（Instruction-Level Parallelism，ILP ）在编译器的帮助下，利用流水线等思想在适度水平上利用数据级并行，在中等水平上利用投机执行等思想（speculative execution）。 11 | 2. 矢量架构（vector architectures）、图形处理器单元（GPU）和多媒体指令集（multimedia instruction sets）通过将一条指令应用于并行的数据集合来利用数据级并行性。 12 | 3. 线程级的并行性（Thread-Level Parallelism ）利用了数据级的并行性或任务级的并行性，在一个紧密耦合的硬件模型中，允许并行线程之间进行交互。 13 | 4. 请求级并行（Request-Level Parallelism）利用了由程序员或操作系统指定的基本解耦的任务之间的并行性。 14 | 15 | 当Flynn（1966）研究了60年代的并行计算工作时，他发现了一个简单的分类，其缩写我们至今仍在使用。他们的目标是数据级并行和任务级并行。他考察了多处理器中最受限制的部件的指令所要求的指令流和数据流的并行性，并将所有计算机归入四类中的一类： 16 | 17 | 1. 单指令流，单数据流（SISD）--这一类是单处理器。程序员认为它是标准的顺序计算机，但它可以利用ILP。[第三章](../../di-san-zhang-zhi-ling-ji-bing-hang-ji-qi-ying-yong.md)介绍了使用ILP技术的SISD架构，如超标量和投机执行。 18 | 2. 单指令流，多数据流（SIMD）--同一指令由多个处理器使用不同数据流执行。SIMD计算机通过对多个数据项并行应用相同的操作来利用数据级的并行性。每个处理器都有自己的数据存储器，但有一个单一的指令存储器和控制处理器，负责获取和分配指令。[第四章](../../di-si-zhang-shi-liang-simd-he-gpu-jia-gou-zhong-de-shu-ju-ji-bing-hang-xing.md)涉及DLP和利用它的三种不同的架构：矢量架构、标准指令集的多媒体扩展和GPU。 19 | 3. 多指令流，单数据流（MISD）--迄今为止，还没有建立这种类型的商用多处理器，但它完善了这种简单的分类。 20 | 4. 多指令流，多数据流（MIMD）--每个处理器获取自己的指令并对自己的数据进行操作，它的目标是任务级并行。一般来说，MIMD比SIMD更灵活，因此更普遍适用，但它本质上比SIMD更昂贵。例如，MIMD计算机也可以利用数据级的并行性，尽管其开销可能比在SIMD计算机中看到的要高。这种开销意味着颗粒大小必须足够大，才能有效地利用并行性。[第五章](../../di-wu-zhang-xian-cheng-ji-bing-hang.md)介绍了紧密耦合的MIMD架构，它利用了线程级的并行性，因为多个合作的线程是并行运行的。[第六章](../../di-liu-zhang-da-gui-mo-shu-ju-zhong-xin-ji-ji-suan-ji-de-bing-hang-xing-qing-qiu-ji-bing-hang-rlp-he.md)涵盖了松散耦合的MIMD架构--特别是集群和仓库级计算机--利用了请求级并行性，许多独立的任务可以自然地并行进行，几乎不需要通信或同步。 21 | 22 | 这个分类法是一个粗略的模型，因为许多并行处理器是SISD、SIMD和MIMD类别的混合体。尽管如此，它对于为我们在本书中看到的计算机的设计空间提供一个框架是很有用的。 23 | 24 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.4-ji-shu-qu-shi/README.md: -------------------------------------------------------------------------------- 1 | # 1.4 技术趋势 2 | 3 | 如果一个指令集架构要占上风，它必须被设计成能在计算机技术的快速变化中生存。毕竟，一个成功的新指令集架构可能会持续几十年--例如，IBM大型机的处理器已经持续使用了50多年。设计者必须对技术的变化进行规划，这些变化可以增加一台计算机的寿命。 4 | 5 | 为了规划计算机的发展，设计者必须意识到实施技术的快速变化。有五种实施技术，它们的变化速度非常快，对现代的实施工作至关重要： 6 | 7 | 1. 集成逻辑电路--从历史上看，晶体管密度每年增加约35%，在四年内翻了几番。芯片尺寸的增加不太容易预测，而且速度较慢，每年10%至20%不等。综合效果是芯片上晶体管数量的传统增长率为每年约40%-55%，或每18-24个月翻一番。这一趋势被通俗地称为摩尔定律。正如我们在下面讨论的那样，器件速度的扩展更为缓慢。令人震惊的是，摩尔定律已经不复存在。每个芯片的器件数量仍在增加，但速度在下降。与摩尔定律时代不同，我们预计每一代新技术的翻倍时间都会被拉长。 8 | 2. 半导体DRAM（dynamic random-access memory， 动态随机访问存储器）--这项技术是主存储器的基础，我们将在[第二章](../../di-er-zhang-nei-cun-ceng-ci-jie-gou-she-ji.md)中讨论它。DRAM的增长已经急剧放缓，从过去的每三年翻两番。8Gb的DRAM在2014年出货，但是16Gb的DRAM要到2019年才能达到这个状态，而且看起来不会有32Gb的DRAM（Kim，2005）。[第二章](../../di-er-zhang-nei-cun-ceng-ci-jie-gou-she-ji.md)提到了其他几种技术，当DRAM遇到容量墙时，它们可能会取代DRAM。 9 | 3. 半导体闪存（electrically erasable programmable read-only memory，电可擦除可编程只读存储器）--这种非易失性半导体存储器是PMD的标准存储设备，它的迅速普及助长了其容量的快速增长。近年来，每个闪存芯片的容量每年增加约50%-60%，大约每2年翻一番。目前，闪存的每比特价格比DRAM便宜8-10倍。[第二章](../../di-er-zhang-nei-cun-ceng-ci-jie-gou-she-ji.md)介绍了闪存。 10 | 4. 磁盘-在1990年之前，密度每年增加约30%，三年内翻了一番。此后，它上升到每年60%，并在1996年增加到每年100%。在2004年和2011年之间，它回落到每年约40%，或每两年翻一番。最近，磁盘的改进已经放缓到每年不到5%。增加磁盘容量的一个方法是在相同的面积密度下增加更多的盘片，但在3.5英寸规格的磁盘的一英寸深度内已经有七个盘片。最多可以增加一到两个盘片。真正提高密度的最后一个希望是在每个磁盘读写头上使用一个小型激光器，将一个30纳米的点加热到400℃，以便在它冷却之前可以用磁力写入（温度辅助的磁力写入，Heat Assisted Magnetic Recording，HAMR）。虽然希捷公司宣布计划在2018年有限地生产HAMR，但目前还不清楚热辅助磁记录是否能够经济和可靠地制造。HAMR是继续提高硬盘面积密度的最后机会，现在每比特比闪存便宜8-10倍，每比特比DRAM便宜200-300倍。这项技术是服务器和仓库规模存储的核心，我们在[附录D](../../fu-ludcun-chu-xi-tong.md)中详细讨论了这一趋势。 11 | 5. 网络-网络性能既取决于交换机的性能，也取决于传输系统的性能。我们在[附录F](../../fu-lufduo-ji-hu-lian.md)中讨论了网络的发展趋势。 12 | 13 | 这些快速变化的技术塑造了计算机的设计，在速度和技术提升的加持下，其设计寿命可能为3-5年。像Flash这样的关键技术的变化非常大，设计者必须为这些变化做出计划。事实上，设计者经常为下一个技术进行设计，因为他们知道，当产品开始批量出货时，下一个技术可能是最具成本效益的，或者可能具有性能优势。传统上，成本下降的速度与（译者注：器件的）密度增加的速度差不多。 14 | 15 | 尽管技术在不断改进，但这些改进的影响可能是不连续的飞跃，因为达到了一个允许新能力的瓶颈。例如，当MOS技术在20世纪80年代初达到一个点，即25,000到50,000个晶体管可以装在一个芯片上时，建立一个单芯片的32位微处理器成为可能。到20世纪80年代末，一级缓存可以放在一个芯片上。通过消除处理器内部和处理器与高速缓存之间的芯片交叉，成本-性能和能耗-性能的大幅改善成为可能。在技术发展到一定程度之前，这种设计是根本不可行的。随着多核微处理器和每一代内核数量的增加，即使是服务器计算机也越来越趋向于所有处理器都使用单一芯片。这样的技术瓶颈并不罕见，而且对各种设计决策都有重大影响。 16 | 17 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.10-ba-ta-men-fang-zai-yi-qi-xing-neng-jia-ge-he-gong-hao.md: -------------------------------------------------------------------------------- 1 | # 1.10 把它们放在一起：性能、价格和功耗 2 | 3 | 在每一章结尾处的 "把它放在一起 "部分，我们提供了使用该章原则的真实例子。在本节中，我们使用SPECpower基准测试来衡量小型服务器的功耗-性能对比。 4 | 5 | 图1.20显示了我们评估的三种多处理器服务器及其价格。为了保持价格比较的公平性，都是戴尔PowerEdge服务器。第一个是PowerEdge R710，它基于Intel Xeon ×85670微处理器，时钟频率为2.93GHz。与第[2](../di-er-zhang-nei-cun-ceng-ci-jie-gou-she-ji.md)-[5](../di-wu-zhang-xian-cheng-ji-bing-hang.md)章中的英特尔Core i7-6700 不同，它有20个核和40MB的L3缓存，Xeon ×85670有22个内核和55MB的L3缓存，尽管核本身是相同的。对于服务器，我们选择了一个双插槽系统--所以总共有44个核心--有128GB的ECC保护的2400MHz DDR4 DRAM。下一台服务器是PowerEdge C630，具有相同的处理器、插座数量和DRAM。主要的区别是采用了更小的机架式封装：730的 "2U "高（3.5英寸），而630的 "1U"（1.75英寸）。第三台服务器是一个由16台PowerEdge 630组成的集群，用一个1Gbit/s以太网交换机连接在一起。所有服务器都运行Oracle Java HotSpot 1.7版Java虚拟机（JVM）和微软Windows Server 2012 R2 Datacenter 6.3版操作系统。 6 | 7 | ![图1.20 评测的的三台戴尔PowerEdge服务器及其截至2016年7月的价格。我们通过减去第二个处理器的成本来计算处理器的成本。同样地，我们通过查看额外内存的成本来计算内存的整体成本。因此，服务器的基本成本是通过去除默认处理器和内存的估计成本来调整的。第5章描述了这些多插槽系统是如何连接在一起的，第6章描述了集群是如何连接在一起的。](../.gitbook/assets/NeatReader-1656406108658.png) 8 | 9 | 请注意，由于只需要跑基准测试（见第1.11节），这些是不太常见的服务器配置。图1.20中的系统相对于计算量来说内存很少，只有一个很小的120GB固态硬盘。如果你不需要增加相应的内存和存储空间，那么增加CPU核的成本是很低的。 10 | 11 | SPECpower不是运行SPEC CPU的静态链接C程序，而是使用一个用Java编写的更现代的软件栈。它以SPECjbb为基础，代表商业应用的服务器端，性能以每秒的交易数来衡量，称为ssj\_ops，代表服务器端每秒的Java操作。它不仅测验了服务器的处理器，就像SPEC CPU一样，还测验了缓存、内存系统，甚至是多处理器的互连系统。此外，它还也测验了JVM，包括JIT运行时编译器和垃圾收集器，以及底层操作系统的部分。 12 | 13 | 如图1.20的最后两行所示，性能上的赢家是16台R630的集群，这并不令人惊讶，因为它是最昂贵的。价格-性能的赢家是PowerEdge R630，但它勉强击败了集群，价格是213比211 ssj-ops每美元。令人惊讶的是，16个节点的集群尽管是单节点的16倍大，但其价格-性能比却在1%以内。 14 | 15 | 虽然大多数基准（和大多数计算机架构设计者）只关心系统在峰值负载下的性能，但计算机很少在峰值负载下运行。事实上，第6章中的图6.2显示了谷歌公司6个月来对数万台服务器的利用率进行测量的结果，只有不到1%的服务器在平均利用率为100%的情况下运行。大多数服务器的平均利用率在10%到50%之间。因此，SPECpower基准捕捉到了目标工作负载从10%的峰值一直到0%的功率变化，这被称为主动闲置。 16 | 17 | 18 | 19 | 图1.21描绘了每瓦特的ssj\_ops（SSJ操作/秒）以及目标负载从100%到0%变化时的平均功率。英特尔R730总是有最低的功率，而单节点R630在每个目标工作负载水平上都有最好的每瓦特ssj\_ops。由于瓦特=焦耳/秒，这个指标与每焦耳的SSJ操作成正比：​ 20 | 21 | ![](../.gitbook/assets/NeatReader-1656406935362.png) 22 | 23 | ![图1.21 图1.20中三台服务器的功率性能。 Ssj\_ops/watt值在左轴上，与之相关的是三列，瓦特在右轴上，与之相关的是三条线。横轴显示的是目标工作负载，因为它从100%到Active Idle变化。单个节点R630在每个工作负载水平上都有最好的ssj\_ops/watt，但是R730在每个水平上消耗的功率最低。](../.gitbook/assets/NeatReader-1656407418363.png) 24 | 25 | SPECpower使用一个单一的值，用于比较系统的功率性能比： 26 | 27 | ![](../.gitbook/assets/NeatReader-1656407607705.png) 28 | 29 | 三台服务器的总体ssj\_ops/watt为：R730为10,802，R630为11,157，16台R630组成的集群为10,062。因此，单节点的R630具有最佳的功率性能比。除以服务器的价格，ssj\_ops/watt/$1,000，R730为879，R630为899，16个节点的R630集群为789（每个节点）。因此，在增加功率后，单节点的R630在性能/价格方面仍然排在第一位，但现在单节点的R730的效率明显高于16节点的集群。 30 | -------------------------------------------------------------------------------- /fu-lubnei-cun-ceng-ci-jie-gou-de-hui-gu/b.1-jie-shao/README.md: -------------------------------------------------------------------------------- 1 | # B.1 介绍 2 | 3 | 本附录是对内存层次结构的快速复习，包括缓存和虚拟内存的基础知识、性能方程和简单优化。第一节回顾以下36个术语： 4 | 5 | 6 | 7 | | _缓存（cache）_ | _全相连（fully associative）_ | _写分配（write allocate）_ | 8 | | ---------------------------- | ------------------------ | ------------------------ | 9 | | _虚拟内存（virual memory）_ | _脏位（dirty bit）_ | _统一缓冲区（unified cache）_ | 10 | | _内存滞怠周期 memory stall cycles_ | _block offset_ | _misses per instruction_ | 11 | | _direct mapped_ | _write back_ | _块（block）_ | 12 | | _valid bit_ | _data cache_ | _locality_ | 13 | | _block address_ | _hit time_ | _address trace_ | 14 | | _write through_ | 缓存未命中（_cache miss）_ | _set_ | 15 | | _instruction cache_ | _page fault_ | _random replacement_ | 16 | | _average memory access time_ | _miss rate_ | _index field_ | 17 | | _缓存命中（cache hit）_ | _n-way set associative_ | _no-write allocate_ | 18 | | _page_ | _least recently used_ | _write buffer_ | 19 | | _miss penalty_ | _tag field_ | _write stall_ | 20 | 21 | 如果这篇回顾说得太快，你可能想看看《计算机组织与设计》中的第7章，那是我们为经验不足的读者写的。 22 | 23 | 缓存是对地址离开处理器后遇到的内存层次结构的最高或第一层的称呼。由于局部性原则适用于许多层次，而且利用局部性来提高性能是很流行的，所以现在只要采用缓冲来重用经常出现的项目，就会用到缓存这个词。这方面的例子包括文件缓存、名称缓存等等。 24 | 25 | 当处理器在缓冲区中找到一个请求的数据项时，它被称为缓存命中（cache hit）。当处理器在高速缓存中没有找到它所需要的数据项目时，就会发生缓存未命中（cache miss）。一个固定大小的包含所要求的字（word）的数据集合，被称为块（block）或行运行（line run），从主存储器中检索出来并放入高速缓存。时间局部性告诉我们，我们很可能在不久的将来再次需要这个字，所以把它放在高速缓存中是很有用的，因为它可以被快速访问。由于空间局部性，该块中的其他数据很有可能很快就会被需要。 26 | 27 | 缓存未命中所需的时间取决于内存的延迟和带宽两个因素。延迟决定了检索该块的第一个字的时间，而带宽决定了检索该块的其余部分的时间。缓存未命中由硬件处理，并导致使用顺序执行的处理器暂停，或停顿，直到数据可用。在非顺序执行中，使用该结果的指令仍然必须等待，其他指令可以未命中期间执行。 28 | 29 | 同样，并不是所有被程序引用的对象都需要驻留在主存储器中。虚拟内存意味着一些对象可能驻留在磁盘上。地址空间通常被分割成固定大小的块，称为页（pages）。在任何时候，每个页都驻留在主存或磁盘上。当处理器引用一个不在缓存或主存中的页内的目标时，就会发生页面故障（page fault），整个页面会从磁盘移到主存。由于页面故障需要很长时间，它们在软件中被处理，处理器不会停滞。在磁盘访问发生时，处理器通常会切换到其他任务。从高层次的角度来看，对引用局部性的依赖，以及缓存与主存的相对大小和每比特的相对成本，与主存与磁盘的关系相似。 30 | 31 | 图B.1显示了从高端台式机到低端服务器的计算机在内存层次结构中每一级的大小和访问时间的范围。 32 | 33 | ![图B.1 当我们远离大型工作站或小型服务器的处理器时，层次结构中的典型级别就会变慢和变大。 嵌入式计算机可能没有磁盘存储，内存和缓存小得多。对于第一层的文件存储而言，越来越多的FLASH正在取代磁盘。当我们移动到较低的层次时，访问时间会增加，这使得管理传输的响应速度降低是可行的。实现技术（ implementation technology）显示了用于这些功能的典型技术。访问时间以纳秒为单位给出了2017年的典型值；这些时间将随着时间的推移而减少。带宽是以内存层次结构中各层之间的兆字节/秒为单位给出的。磁盘/FLASH存储的带宽包括介质和缓冲接口。](../../.gitbook/assets/NeatReader-1656492913257.png) 34 | 35 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.9-ji-suan-ji-liang-hua-she-ji-yuan-ze/a-mu-da-er-ding-lv.md: -------------------------------------------------------------------------------- 1 | # 阿姆达尔定律 2 | 3 | 通过改进计算机的某些部分可以获得的性能增益可以用阿姆达尔定律来计算。阿姆达尔定律指出，通过使用某种更快的执行模式所获得的性能改进，受到可以使用这个更快模式的时间长度的限制。 4 | 5 | 阿姆达尔定律定义了通过使用一个特定的功能可以获得的速度提升。什么是速度提升？假设我们可以对计算机做一个改进，当它被使用时，会提高性能。加速具体指一种比率： 6 | 7 | ![](../../.gitbook/assets/NeatReader-1656387657963.png) 8 | 9 | 或者： 10 | 11 | ![](../../.gitbook/assets/NeatReader-1656387700011.png) 12 | 13 | 加速比告诉我们，与原来的计算机相比，使用带有增强功能的计算机，一项任务的运行速度将提高多少。 14 | 15 | 阿姆达尔定律给了我们一个快速的方法来找到一些增强的速度，这取决于两个因素： 16 | 17 | 1. 原有计算机的计算时间中可以转换为利用增强的部分--例如，如果一个总共需要100秒的程序的执行时间中有40秒可以利用增强，那么这个分数就是40/100。这个值，我们称之为$$Fraction_{enhanced}$$，总是小于或等于1。 18 | 2. 增强的执行模式获得的改进，也就是说，如果在整个程序中使用增强的模式，任务的运行速度会快多少--这个值是原始模式的时间超过增强模式的时间。如果增强模式在部分程序中需要4秒，而在原始模式中需要40秒，那么改进就是40/4或10。我们把这个总是大于1的值称为 $$speed_{enhanced}$$。 19 | 20 | 使用具有增强模式的原始计算机的执行时间将是使用计算机未增强部分的时间加上使用增强部分的时间： 21 | 22 | ![](../../.gitbook/assets/NeatReader-1656387980419.png) 23 | 24 | 25 | 26 | 总体速度的提高是执行时间的比率：​ 27 | 28 | ![](../../.gitbook/assets/NeatReader-1656388027819.png) 29 | 30 | **示例**：假设我们想加强用于网络服务的处理器。新的处理器在网络服务应用中的计算速度是旧处理器的10倍。假设原来的处理器40%的时间在忙于计算，60%的时间在等待I/O，那么加入改进后获得的整体速度是多少？ 31 | 32 | **答案**： 33 | 34 | ![](../../.gitbook/assets/NeatReader-1656395507026.png) 35 | 36 | 阿姆达尔定律蕴含了收益递减的规律。只对一部分计算进行改进所获得的提升会随着改进的增加而减少。阿姆达尔定律的一个重要推论是，如果某个改进只适用于任务的一部分，那么我们对该任务的加速不能超过某个值，这个值是1减去这个部分百分比的倒数。 37 | 38 | 在应用阿姆达尔定律时，一个常见的错误是混淆了 "转换为使用增强功能的时间百分比 "和 "增强功能使用后的时间的百分比"。如果我们不测量在计算中可以使用增强功能的时间，而是测量增强功能使用后的时间，那么结果将是不正确的! 39 | 40 | 阿姆达尔定律可以作为一个指南，指导一个增强功能会在多大程度上提高性能，以及如何分配资源以提高成本效益。显然，我们的目标是将资源的使用与时间的使用成正比。阿姆达尔定律对于比较两个备选方案的整体系统性能特别有用，但它也可以应用于比较两个处理器设计方案，正如下面的例子所示。 41 | 42 | **示例**：图形处理器中需要的一个常见转换是平方根。浮点（FP）平方根的实现在性能上差异很大，特别是在为图形设计的处理器中。假设FP平方根（FSQRT）在一个关键图形基准的执行时间中占了20%。一种建议是增强FSQRT硬件，将该操作的速度提高10倍。另一个方案只是试图使图形处理器中的所有FP指令的运行速度提高1.6倍；FP指令负责该应用的一半执行时间。设计团队认为，他们可以用与快速平方根相同的努力使所有FP指令运行快1.6倍。比较这两种设计方案。 43 | 44 | **答案**：我们可以通过比较加速比来对这两种选择进行比较： 45 | 46 | ![](../../.gitbook/assets/NeatReader-1656396161147.png) 47 | 48 | ![](../../.gitbook/assets/NeatReader-1656396164885.png) 49 | 50 | 由于FP指令出现的频率高，提高FP指令的性能总体上稍好。 51 | 52 | 阿姆达尔定律在性能之外也是适用的。让我们重做[1.7节](../1.7-ke-kao-xing.md)可靠性例子，在通过冗余提高电源的可靠性后，从200,000小时提高到830,000,000小时的MTTF，或4150倍的改善。 53 | 54 | **示例**：磁盘子系统的故障率的计算是： 55 | 56 | ![](../../.gitbook/assets/NeatReader-1656396418163.png) 57 | 58 | 可以改进的故障率基本上是每百万小时5，总时间为23，那么比率为0.22。 59 | 60 | 答案：可靠性的提高将是： 61 | 62 | ![](../../.gitbook/assets/NeatReader-1656396777907.png) 63 | 64 | 尽管一个模块的可靠性有了令人印象深刻的4150×的提高，但从系统的角度来看，这种变化的好处是可衡量的，但很小。 65 | 66 | 在前面的例子中，我们需要新版本和改进版本的某一项所占的百分比；通常情况下，很难直接测量这些时间。在下一节中，我们将看到另一种进行这种比较的方法，它是基于使用一个将CPU执行时间分解为三个独立部分的方程式。如果我们知道一个替代方案如何影响这三个部分，我们就可以确定其整体性能。此外，在实际设计硬件之前，通常有可能建立模拟器来测量这些部分。 67 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.7-ke-kao-xing.md: -------------------------------------------------------------------------------- 1 | # 1.7 可靠性 2 | 3 | 历史上，集成电路是计算机中最可靠的部件之一。尽管它们的引脚可能是脆弱的，而且故障可能发生在通信通道上，但芯片内部的故障率是非常低的。随着我们走向16纳米和更小的特征尺寸，这种传统认知正在发生变化，因为瞬时故障和永久故障都变得越来越普遍，所以设计者必须设计系统来应对这些挑战。本节对可靠性方面的问题进行了快速的概述，把术语和方法的正式定义留给附录D中的D.3节。 4 | 5 | 计算机是在不同的抽象层次上设计和构造的。我们可以通过计算机系统不断地“递归的”往下看，看到组件将自己放大到完整的子系统，直到我们放大到单个晶体管。虽然有些故障是广泛的，如断电，但许多故障可以限制在一个模块中的单一组件。因此，在某一个层次上的模块的全方位的错误可能被认为只是一个更高层次模块的组件错误。这种不同层级的错误分类，对于试图找到建立可靠计算机的方法是很有帮助的。 6 | 7 | 一个困难的问题是决定一个系统何时能够正常运行。随着互联网服务的普及，这一理论观点变得具体起来。基础设施供应商开始提供服务水平协议（ _S_ervice Level Agreements_，_SLA）或服务水平目标（Service Level Objectives_，_SLO）来保证他们的网络或电力服务是可靠的。例如，如果客户的设备没有达到协议中每月多少小时的无故障运行，他们会向客户支付赔偿金。因此，SLA可以用来确定系统运行或停机的频率。 8 | 9 | 对于SLA，系统在两种服务状态之间交替进行： 10 | 11 | 1. 服务完成，即按协议正常提供服务。 12 | 2. 服务中断，即交付的服务与SLA不同。 13 | 14 | 这两种状态之间的转换是由**故障**（failures）（从状态1到状态2）或**恢复**（restorations ）（2到1）引起的。对这些转换进行量化，可以得出两个主要的可依赖性衡量标准： 15 | 16 | **模块的可信度（reliability），**这是对从一个参考的初始瞬间开始的连续服务成就（或者说，等同于故障时间）的衡量。因此，平均故障时间（Mean Time To Failure_，_MTTF）是一种可靠性测量。MTTF的倒数是故障率，一般报告为每十亿小时的故障率，或FIT（failures in time）。因此，1,000,000小时的MTTF等于$$10^9$$除以$$10^6$$，即1000 FIT。服务中断是以平均修复时间（mean time to repair_，_MTTR）来衡量。平均故障间隔时间（Mean time between failures_，_MTBF）是简单的MTTF+MTTR之和。虽然MTBF被广泛使用，但MTTF往往是更合适的术语。如果一个模块的集合具有指数分布的寿命--这意味着一个模块的寿命在故障概率中并不重要，那么这个集合的总故障率就是各模块的故障率之和。 17 | 18 | **模块可用度（availability ）**，这是对完成和中断两种状态交替的服务成就的衡量。对于有维修的非冗余系统，模块可用性为： 19 | 20 | ![](../.gitbook/assets/NeatReader-1656061094113.png) 21 | 22 | 请注意，可信度和可用度现在是可量化的指标，而不是可靠度的同义词。从这些定义中，如果我们对部件的可靠性做一些假设，并认为故障是独立的，我们就可以定量地估计系统的可靠性。 23 | 24 | **示例**：假设一个磁盘子系统有以下组件和MTTF： 25 | 26 | * 10块磁盘，每块的MTTF值为1,000,000小时 27 | * 1个ATA控制器，500,000小时的MTTF 28 | * 1个电源，200,000小时MTTF 29 | * 1条ATA电缆，1,000,000小时MTTF 30 | 31 | 使用简化的假设，即寿命是指数分布的，故障是独立的，计算整个系统的MTTF。 32 | 33 | **答案**：故障率之和为： 34 | 35 | ![](../.gitbook/assets/NeatReader-1656322656983.png) 36 | 37 | 即23000FIT。系统的MTTF是FIT的倒数： 38 | 39 | ![](../.gitbook/assets/NeatReader-1656322715023.png) 40 | 41 | 即少于五年。 42 | 43 | 应对故障的主要方法是冗余，要么是时间上的冗余（重复操作，看是否仍有错误），要么是资源上的冗余（有其他组件来接替发生故障的组件）。一旦组件被替换，系统被完全修复，系统的可靠性就会被假定为和新的一样好。让我们用一个例子来量化冗余的好处。 44 | 45 | **示例**：磁盘子系统通常有冗余的电源来提高可靠性。假设一个电源足以运行磁盘子系统，并且我们要增加一个冗余电源。使用前面的组件和MTTFs，计算冗余电源的MTTF。 46 | 47 | **答案**：我们需要一个公式来表明，当我们可以容忍一个故障而仍能提供服务时，应该怎样做。为了简化计算，我们假设组件的寿命是指数分布的，并且组件故障之间没有依赖关系。我们的冗余电源的MTTF是直到一个电源发生故障的平均时间除以另一个电源在第一个电源被替换之前发生故障的机会。因此，如果在维修前发生第二次故障的机会很小，那么这对电源的MTTF就很大。 48 | 49 | 由于我们有两个电源和独立的故障，直到一个电源故障的平均时间是$${MTTF}_{power supply}/2$$。第二个故障的概率的一个很好的近似值是MTTR超过另一个电源故障前的平均时间。因此，一对冗余电源的一个合理近似值是: 50 | 51 | ![](../.gitbook/assets/NeatReader-1656323421583.png) 52 | 53 | 结合上一个示例的电源MTTF值，并且我们假设人类操作者平均需要24小时才能注意到一个电源发生故障并进行更换。将这两个数值带入上式，那么这对容错电源的可靠性为： 54 | 55 | ![](../.gitbook/assets/NeatReader-1656323586591.png) 56 | 57 | 这个可信度是单电源的4150倍。 58 | 59 | 在量化了计算机技术的成本、功率和可靠性之后，我们准备对性能进行量化。 60 | -------------------------------------------------------------------------------- /fu-lubnei-cun-ceng-ci-jie-gou-de-hui-gu/b.1-jie-shao/huan-cun-xing-neng-hui-gu.md: -------------------------------------------------------------------------------- 1 | # 缓存性能回顾 2 | 3 | 由于局部性和较小存储器的速度较高，存储器的层次结构可以大幅度提高性能。评估高速缓存性能的一个方法是扩展第一章中的处理器执行时间方程。我们现在考虑到处理器在等待内存访问时停滞的周期数，我们称之为内存停滞周期（memory stall cycles）。那么，性能就是时钟周期时间与处理器周期和内存停滞周期之和的乘积： 4 | 5 | ![](../../.gitbook/assets/NeatReader-1656493288625.png) 6 | 7 | 这个等式假设CPU的时钟周期包括处理高速缓存命中的时间，并且处理器在高速缓存缺失期间是停滞的。B.2节重新审视了这个简化的假设。 8 | 9 | 内存停滞周期的数量取决于失误的数量和每次失误的成本，这被称为未命中惩罚（miss penalty）: 10 | 11 | ![](../../.gitbook/assets/NeatReader-1656493705674.png) 12 | 13 | 最后一种形式的优点是，可以很容易地测量各个部分。我们已经知道如何测量指令数（IC）。（ 对于推测性处理器，我们只计算提交的指令）测量每条指令的内存引用数量也可以用同样的方式完成；每条指令都需要一个指令访问，而且很容易决定它是否也需要一个数据访问。 14 | 15 | 请注意，我们计算未命中惩罚是一个平均值，但在这里我们将把它当作一个常数来使用。由于先前的内存请求或内存刷新，高速缓存后面的内存在未命中的时候可能很忙。在处理器、总线和内存的不同时钟之间的接口处，时钟周期的数量也会有所不同。因此，请记住，用一个单一的数字来表示失误惩罚是一种简化。 16 | 17 | 在上面的式子中，未命中率部分是导致未命中的高速缓存访问的一部分（即，未命中的访问数除以总访问数）。未命中率可以用高速缓存模拟器来测量，该模拟器获取指令和数据引用的地址轨迹，模拟高速缓存行为以确定哪些引用命中，哪些引用缺失，然后报告命中和未命中总数。今天，许多微处理器提供了硬件来计算失误和内存引用的数量，这是一个更容易和更快的方法来测量未命中率。 18 | 19 | 前面的公式是一个近似值，因为读和写的未命中率和未命中惩罚往往是不同的。可以用每条指令的内存访问次数、读和写的未命中惩罚（以时钟周期为单位）以及读和写的未命中率来定义内存滞后时钟周期： 20 | 21 | ![](../../.gitbook/assets/NeatReader-1656494474009.png) 22 | 23 | 我们通常通过合并读和写，找到读和写的平均未命中率和未命中惩罚来简化完整的公式： 24 | 25 | ![](<../../.gitbook/assets/NeatReader-1656494595169 (1).png>) 26 | 27 | 未命中率是缓存设计中最重要的衡量标准之一，但是，正如我们在后面的章节中所看到的，它并不是唯一的衡量标准。 28 | 29 | 示例：假设我们有一台计算机，当所有的内存访问都在高速缓存中时，每条指令的周期（CPI）是1.0。唯一的数据访问是加载和存储，而这些访问占指令总数的50%。如果未命中惩罚是50个时钟周期，未命中率是1%，如果所有的指令都在高速缓存中命中，那么计算机的速度会快多少？ 30 | 31 | 答案：首先计算一下全都命中的计算机的性能： 32 | 33 | ![](../../.gitbook/assets/NeatReader-1656574241439.png) 34 | 35 | 现在对于有真正缓存的计算机，首先我们计算内存滞留周期： 36 | 37 | ![](../../.gitbook/assets/NeatReader-1656574280092.png) 38 | 39 | 其中中间项（1+0.5）代表每条指令的1个指令访问和0.5个数据访问。因此，总的性能是： 40 | 41 | ![](../../.gitbook/assets/NeatReader-1656574355157.png) 42 | 43 | 性能比是执行时间的倒数： 44 | 45 | ![](../../.gitbook/assets/NeatReader-1656574378708.png) 46 | 47 | 也就是说，速度是存在未命中计算机的1.75倍。 48 | 49 | 一些设计者喜欢用每条指令的未命中率来衡量整体的未命中率，而不是每条内存引用的未命中率。这两者是相关的： 50 | 51 | ![](../../.gitbook/assets/NeatReader-1656574934509.png) 52 | 53 | 当你知道每条指令的平均内存访问次数时，后一个公式很有用，因为它允许你将未命中率转换成每条指令的未命中，反之亦然。例如，我们可以把前面例子中每个内存引用的未命中率转化为每个指令的未命中率： 54 | 55 | ![](../../.gitbook/assets/NeatReader-1656575156094.png) 56 | 57 | 顺便说一下，每条指令的未命中率通常被报告为每1000条指令的未命中率，以显示整数而不是分数。因此，前面的答案也可以表示为每1000条指令30次未命中。 58 | 59 | 使用“每条指令未命中”来表述的优点是它与硬件实现无关。例如，推测性处理器（speculative processors）获取的指令数量是实际提交的指令数量的两倍，如果用每条内存引用未命中而不是每条指令未命中来衡量，会人为地降低未命中率。缺点是每条指令的未命中与架构有关；例如，每条指令的平均内存访问次数对于80x86和RISC V来说可能是非常不同的。因此，每条指令未命中率在只为某一种计算机架构进行设计的架构师中最为受欢迎，尽管RISC架构的相似性允许人们对其他架构提出见解。 60 | 61 | 示例：为了显示这两个未命中率公式之间的等价性，让我们重做前面的例子，这次假设每1000条指令的未命中数量为30。以指令数计算的内存滞留时间是多少？ 62 | 63 | 答案：重新计算内存滞留周期： 64 | 65 | ![](../../.gitbook/assets/NeatReader-1656576186629.png) 66 | 67 | 我们得到的答案与上一个示例相同，显示出两个方程的等效性。 68 | 69 | 70 | 71 | -------------------------------------------------------------------------------- /fu-lubnei-cun-ceng-ci-jie-gou-de-hui-gu/b.1-jie-shao/yi-ge-li-zi-opteron-de-shu-ju-huan-cun.md: -------------------------------------------------------------------------------- 1 | # 一个例子：Opteron的数据缓存 2 | 3 | 图B.5显示了AMD Opteron微处理器的数据缓存的组织结构。缓存包含65,536(64K)字节的数据，分为64字节的块，具有双路组相联，LRU替换，write-back，以及写未命中时的write allocate 。 4 | 5 | ![图B.5 Opteron微处理器中的数据高速缓存组织。 64KiB高速缓存是由64字节的块组成的双路组相联。9位索引在512组中进行选择。读取命中的四个步骤，按发生的顺序用圆圈表示，标明了这个组织顺序。块偏移量的3位与索引相连，以提供RAM地址来选择适当的8个字节。因此，高速缓存拥有两组4096个64位的字，每组包含512组的一半。虽然在这个例子中没有行使，但从低级别的内存到高速缓存的线路在未命中时被用来加载高速缓存。离开处理器的地址大小为40位，因为它是一个物理地址而不是一个虚拟地址。图B.24解释了Opteron是如何从虚拟地址映射到物理地址进行高速缓存访问的。](../../.gitbook/assets/NeatReader-1656833433564.png) 6 | 7 | 让我们通过图B.5中标注的步骤来追踪一个缓存的命中情况（四个步骤用圈起来的数字表示）。 如B.5节所述，Opteron向缓存提交了一个48位的虚拟地址用于标记比较，同时被转换为一个40位的物理地址。 8 | 9 | Opteron没有使用全部64位的虚拟地址的原因是它的设计者认为还没有人需要那么多的虚拟地址空间，而且较小的尺寸可以简化Opteron的虚拟地址映射。设计者计划在未来的微处理器中增加虚拟地址。 10 | 11 | 进入缓存的物理地址分为两个字段：34位块地址和6位块偏移量（64=26，34+6=40）。块地址又被分为地址标签和缓冲区索引。步骤1显示了这种划分。 12 | 13 | 缓存索引选择要测试的标签，看所需的块是否在缓存中。索引的大小取决于缓冲区的大小，块的大小和集合关联性。对于Opteron高速缓存来说，集合关联性被设置为2，我们计算索引的方法如下。 14 | 15 | ![](../../.gitbook/assets/NeatReader-1656834718438.png) 16 | 17 | 因此，索引是9位宽，而标签是25（34位减9位）位宽。尽管这是选择合适的块所需要的索引，但64字节的容量远远超过了处理器想要一次性消耗的容量。因此，将缓存内存的数据部分组织成8字节宽更有意义，这也是64位Opteron处理器的自然数据字。因此，除了用9位来索引适当的缓存块外，还有3位来自块偏移量的索引，用于索引适当的8字节。索引选择是图B.5中的第2步。 18 | 19 | 从高速缓存中读取两个标签（tag）后，将它们与来自处理器的块地址的标签部分进行比较。这种比较是图中的第3步。为了确保标签包含有效信息，有效位必须被设置，否则比较的结果会被忽略。 20 | 21 | 假设有一个标签确实被匹配上了，最后一步是向处理器发出信号，通过使用2:1多路复用器的获胜输入从高速缓存中加载适当的数据。Opteron允许2个时钟周期来完成这四个步骤，因此，如果接下来的2个时钟周期的指令试图使用加载的结果，它们就会等待。 22 | 23 | 在Opteron中，处理写比处理读更复杂，在任何缓存中都是如此。如果要写的字在高速缓存中，前三个步骤是一样的。因为Opteron是不按顺序执行的，只有在它发出指令已提交的信号，并且缓存标签比较表明命中后，数据才被写入缓存。 24 | 25 | 到目前为止，我们已经描述了高速缓存命中的常见情况。在未命中的情况下会发生什么？在读取未命中的情况下，高速缓存向处理器发送一个信号，告诉它数据还不可用，并从下一级的层次结构中读取64字节。读取数据块的前8个字节的延迟是7个时钟周期，其余部分每8个字节的延迟是2个时钟周期。因为数据缓存是设置关联的，所以可以选择替换哪个块。Opteron使用LRU，它选择最久之前被引用的块，所以每次访问必须更新LRU位。替换一个块意味着更新数据、地址标签、有效位和LRU位。 26 | 27 | 因为Opteron使用write back，旧的数据块可能已经被修改了，因此不能简单地丢弃它。Opteron为每个块保留1个脏位（dirty），以记录该块是否被写入。如果 "受害者 （victim）"被修改了，它的数据和地址将被发送到victim缓冲区。(这个结构类似于其他计算机中的写缓冲区。）Opteron有八个victim块的空间。在与其他缓存动作并行的情况下，它将victim块写到层次结构的下一级。如果victim缓冲区满了，高速缓存必须等待。 28 | 29 | 写未命中与读未命中非常相似，因为Opteron在读或写失误时都会分配一个块。 30 | 31 | 我们已经看到了它的工作原理，但是数据缓存不能满足处理器的所有内存需求：处理器也需要指令缓存。尽管一个单一的高速缓存可以尝试提供这两方面的需求，但它可能是一个瓶颈。例如，当一个加载或存储指令被执行时，流水线上的处理器将同时请求一个数据字和一个指令字。因此，单一的高速缓存会给加载和存储带来结构上的危险，导致停滞。征服这个问题的一个简单方法是将其分割：一个缓存专门用于指令，另一个用于数据。在最近的大多数处理器中都有独立的缓存，包括Opteron。因此，它有一个64 KiB的指令缓存以及64 KiB的数据缓存。 32 | 33 | 处理器知道它发出的是指令地址还是数据地址，因此可以为这两者设置单独的端口，从而使内存层次结构和处理器之间的带宽增加一倍。独立的高速缓存还提供了单独优化每个高速缓存的机会：不同的容量、块大小和关联性可能导致更好的性能。(与Opteron的指令高速缓存和数据高速缓存相比，统一的或混合的术语适用于可以包含指令或数据的高速缓存）。 34 | 35 | 图B.6显示，指令高速缓存比数据高速缓存的未命中率低。分离指令和数据可以消除由于指令块和数据块之间的冲突而导致的未命中，但是这种分离也固定了用于每种类型的缓存空间。哪个对未命中率更重要？将独立的指令和数据缓冲区与统一的缓冲区进行公平的比较，需要缓冲区的总大小相同。例如，一个独立的16KiB指令缓存和16KiB数据缓存应该和一个32KiB的统一缓存进行比较。计算独立的指令和数据缓冲区的平均未命中率需要知道每个缓冲区的内存引用比例。从附录A的数据中，我们发现分割是100%/(100%+26%+10%)，即74%的指令引用和(26%+10%)/(100%+26%+10%)，大约26%的数据引用。分割对性能的影响超出了未命中率变化所显示的范围，我们很快就会看到这一点。 36 | 37 | ![对于不同大小的指令、数据和统一缓存，每1000条指令的未命中率。 指令引用的百分比约为74%。这些数据是针对具有64字节块的双路组相联高速缓存，与图B.4相同的计算机和基准。](../../.gitbook/assets/NeatReader-1657449430083.png) 38 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.9-ji-suan-ji-liang-hua-she-ji-yuan-ze/chu-li-qi-xing-neng-fang-cheng.md: -------------------------------------------------------------------------------- 1 | # 处理器性能方程 2 | 3 | 基本上所有的计算机都是使用一个以恒定速率运行的时钟构造的。这些离散的时间事件被称为时钟周期、时钟、周期或时钟循环。计算机设计者用持续时间（如1ns）或速率（如1GHz）来指代一个时钟周期的时间。那么一个程序的CPU时间可以用两种方式表示： 4 | 5 | ![](../../.gitbook/assets/NeatReader-1656397108003.png) 6 | 7 | 或者： 8 | 9 | ![](../../.gitbook/assets/NeatReader-1656397161075.png) 10 | 11 | 除了执行程序所需的时钟周期数之外，我们还需要计算执行的指令数--指令路径长度（instruction path length）或指令数（instruction count，IC）。如果我们知道时钟周期数和指令数，我们就可以计算出每条指令的平均时钟周期数（clock cycles per instruction，CPI）。因为它更容易操作，而且在本章中我们只分析简单的处理器，所以我们使用CPI。设计者有时也使用每时钟指令数（instructions per clock，IPC），它是CPI的倒数。 12 | 13 | CPI的计算方式为： 14 | 15 | ![](../../.gitbook/assets/NeatReader-1656397448347.png) 16 | 17 | 这个处理器指数的优点是：提供了对不同风格的指令集和实现的观察方式，我们将在接下来的四章中广泛使用它。 18 | 19 | 通过将前述公式中的指令数换位，时钟周期可以定义为IC×CPI。这使得我们可以在执行时间公式中使用CPI： 20 | 21 | ![](../../.gitbook/assets/NeatReader-1656397645547.png) 22 | 23 | 将第一个公式扩展到测量单位中，可以看出这些部分是如何结合在一起的： 24 | 25 | ![](../../.gitbook/assets/NeatReader-1656397682499.png) 26 | 27 | 正如这个公式所显示的，处理器的性能取决于三个特性：时钟周期（或速率）、每条指令的时钟周期和指令数。此外，CPU时间也同样取决于这三个特性；例如，其中任何一个特性的10%的改进都会导致CPU时间的10%的改进。 28 | 29 | 不幸的是，很难完全孤立地改变一个参数，因为改变每个特性所涉及的基本技术是相互依赖的： 30 | 31 | * 时钟周期时间-硬件技术和组织 32 | * CPI-组织和指令集架构 33 | * 指令数-指令集架构和编译器技术 34 | 35 | 幸运的是，许多潜在的性能改进技术主要是增强处理器性能某一个组成部分，而对其他两个组成部分的影响很小或可以预测。 36 | 37 | 在设计处理器时，有时计算总的处理器时钟周期的数量是很有用的，即： 38 | 39 | ![](../../.gitbook/assets/NeatReader-1656398200347.png) 40 | 41 | 其中$$IC_i$$指令表示指令i在程序中被执行的次数，CPIi代表指令i每条指令的平均时钟数。 这种形式可以用来表示CPU时间为： 42 | 43 | ![](../../.gitbook/assets/NeatReader-1656398331171.png) 44 | 45 | 总体的CPI为： 46 | 47 | ![](../../.gitbook/assets/NeatReader-1656398369483.png) 48 | 49 | 后一种形式的CPI计算使用每个单独的CPIi和该指令在程序中出现的比例（即ICi÷指令数）。因为它必须包括流水线效应、高速缓存缺失和任何其他内存系统的低效率，$$CPI_i$$该被测量，而不是仅仅从参考手册后面的表格中计算出来。 50 | 51 | 考虑一下我们在[上一节](a-mu-da-er-ding-lv.md)的性能例子，在此修改为使用指令频率和指令CPI值的测量，在实践中，这些测量是通过模拟或硬件仪器获得的。 52 | 53 | **示例**：假设我们做了以下测量。 54 | 55 | * FP操作的频率=25% 56 | * FP操作的平均CPI=4.0 57 | * 其他指令的平均CPI = 1.33 58 | * FSQRT的频率=2% 59 | * FSQRT的CPI=20 60 | 61 | 假设两个设计方案是将FSQRT的CPI降低到2或将所有FP操作的平均CPI降低到2.5。使用处理器性能方程比较这两种设计方案。 62 | 63 | **答案**：首先，观察一下，只有CPI发生了变化；时钟频率和指令数仍然是相同的。我们首先找到两个都没有增强的原始CPI： 64 | 65 | ![](../../.gitbook/assets/NeatReader-1656404177994.png) 66 | 67 | 我们可以通过从原始CPI中减去节省的周期来计算增强型FSQRT的CPI： 68 | 69 | ![](../../.gitbook/assets/NeatReader-1656404273820.png) 70 | 71 | 我们可以用同样的方法计算所有FP指令的增强的CPI，或者通过FP和非FP的CPI相加来计算。使用后者，我们可以得到： 72 | 73 | ![](../../.gitbook/assets/NeatReader-1656404361034.png) 74 | 75 | 由于整体FP增强的CPI略低，其性能将略微好一些。具体来说，整体FP增强的速度提升为： 76 | 77 | ![](../../.gitbook/assets/NeatReader-1656404493858.png) 78 | 79 | 令人高兴的是，我们使用[上一节](a-mu-da-er-ding-lv.md)的阿姆达尔定律也得到了这个比率。 80 | 81 | 通常可以测量处理器性能方程的构成部分。这种单独的测量是使用处理器性能方程与前面例子中的阿姆达尔定律相比的一个关键优势。但有些具体的问题：可能很难测量诸如一组指令所占的执行时间的比例。在实践中，这可能是通过计算指令数和指令集中每个指令的CPI的乘积来实现的。由于起点通常是单个指令数和CPI的测量，处理器性能方程非常有用。 82 | 83 | 为了使用处理器性能方程作为设计工具，我们需要能够测量各种因素。对于一个现有的处理器，通过测量很容易获得执行时间，而且我们知道默认的时钟速度。挑战在于统计指令数或CPI。大多数处理器包括执行指令和时钟周期的计数器。通过定期监测这些计数器，或者将执行时间和指令数附加到代码段上，这对试图了解和调整应用程序性能的程序员是有帮助的。通常情况下，设计者或程序员希望在比硬件计数器更细的层次上了解性能。例如，他们可能想知道为什么CPI是这样的。在这种情况下，可以利用仿真技术来指导设计处理器。 84 | 85 | 有助于提供能效的技术，如动态电压频率缩放和超频（见第1.5节），使这个方程更难使用，因为在我们测量程序时，时钟速度可能会变化。一个简单的方法是关闭这些功能，使结果具有可重复性。幸运的是，由于性能和能效通常是高度相关的--花更少的时间来运行一个程序通常会节省能源--所以考虑性能可能是安全的，而不必担心DVFS或超频对结果的影响。 86 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.12-jie-lun.md: -------------------------------------------------------------------------------- 1 | # 1.12 结论 2 | 3 | 本章介绍了一些概念，并提供了一个量化分析框架，我们将在全书中展开。从上一版开始，能效是性能的永恒伴侣。 4 | 5 | 在[第二章](../di-er-zhang-nei-cun-ceng-ci-jie-gou-she-ji.md)中，我们从内存系统设计这个最重要的领域开始。我们将研究一系列的技术，这些技术的综合应用使得内存看起来无限大，同时又尽可能地快。([附录B](../fu-lubnei-cun-ceng-ci-jie-gou-de-hui-gu/)为没有太多经验和背景的读者提供了关于缓存的介绍性材料）。在后面的章节中，我们将看到硬件和软件的合作已经成为高性能内存系统的关键，就像它对高性能流水线一样。本章还包括虚拟机，这是一种越来越重要的保护技术。 6 | 7 | 在[第三章](../di-san-zhang-zhi-ling-ji-bing-hang-ji-qi-ying-yong.md)中，我们研究ILP，其中流水线是最简单和最常见的形式。利用ILP是构建高速单处理器的最重要技术之一。[第三章](../di-san-zhang-zhi-ling-ji-bing-hang-ji-qi-ying-yong.md)首先对基本概念进行了广泛的讨论，使你为这两章所研究的广泛思想做好准备。[第三章](../di-san-zhang-zhi-ling-ji-bing-hang-ji-qi-ying-yong.md)使用的例子横跨约40年，从最早的超级计算机之一（IBM 360/91）到2017年市场上最快的处理器。它强调了所谓的利用ILP的动态或运行时方法。它还谈到了ILP思想的局限性，并介绍了多线程，这在[第四章](../di-si-zhang-shi-liang-simd-he-gpu-jia-gou-zhong-de-shu-ju-ji-bing-hang-xing.md)和[第五章](../di-wu-zhang-xian-cheng-ji-bing-hang.md)都有进一步的展开。[附录C](../fu-lucliu-shui-xian-chu-ji-he-zhong-ji-gai-nian.md)为没有很多流水线经验和背景的读者提供了关于流水线的介绍性材料。(我们希望它能成为许多读者的复习资料，包括那些我们的介绍性课本《计算机组织与设计：硬件/软件接口》的读者）。 8 | 9 | [第四章](../di-si-zhang-shi-liang-simd-he-gpu-jia-gou-zhong-de-shu-ju-ji-bing-hang-xing.md)解释了利用数据级并行的三种方法。最经典和历史悠久的方法是矢量结构，我们从这里开始，奠定SIMD设计的原则。([附录G](../fu-lugshen-ru-xiang-liang-chu-li-qi.md)对矢量结构进行了更深入的研究。)接下来我们将解释当今大多数台式微处理器中的SIMD指令集扩展。第三部分是对现代图形处理单元（GPU）如何工作的深入解释。大多数GPU的描述都是从程序员的角度写的，这通常掩盖了计算机的真正工作原理。这一部分从内部人士的角度解释GPU，包括GPU术语和更传统的架构术语之间的对应关系。 10 | 11 | [第五章](../di-wu-zhang-xian-cheng-ji-bing-hang.md)重点讨论了使用多处理器（multiprocessors）实现更高的性能问题。多处理器不是使用并行性来重叠单个指令，而是使用并行性来允许多个指令流在不同处理器上同时执行。我们的重点是多处理器的主要形式，即共享内存多处理器（shared-memory multiprocessors）。尽管我们也介绍其他类型，并讨论了多处理器中出现的广泛问题。这里我们将再次探讨各种技术，重点是 20 世纪 80 年代和 90 年代首次提出的重要观点。 12 | 13 | [第六章](../di-liu-zhang-da-gui-mo-shu-ju-zhong-xin-ji-ji-suan-ji-de-bing-hang-xing-qing-qiu-ji-bing-hang-rlp-he.md)介绍了集群，然后深入探讨了计算机架构设计者帮助设计的WSCs。WSCs的设计者是超级计算机先驱的继任者，如Seymour Cray，因为他们正在设计这样的特殊计算机：包含数以万计的服务器，设备和容纳它们的建筑耗资近2亿美元。前面几章所关注的性价比和能源效率问题适用于WSCs，量化的决策方法也适用于WSCs。 14 | 15 | [第七章](../di-qi-zhang-ling-yu-te-ding-jia-gou-dsa.md)是本版的新内容。它介绍了特定领域的架构，鉴于摩尔定律和Dennard定律的结束，这是提高性能和能源效率的唯一途径。它提供了如何构建有效的特定领域架构的指南，介绍了令人兴奋的深度神经网络领域，描述了最近的四个例子，它们采取了非常不同的方法来加速神经网络，并比较了它们的性价比。 16 | 17 | 本书在网上附带了大量的材料（详见前言），既是为了降低成本，也是为了向读者介绍各种高级课题。图1.25显示了它们的全部内容。书中出现的[附录A](../fu-luazhi-ling-ji-she-ji-yuan-ze.md)-[C](../fu-lucliu-shui-xian-chu-ji-he-zhong-ji-gai-nian.md)将成为许多读者的回顾。 18 | 19 | ![图1.25 附录列表。](../.gitbook/assets/NeatReader-1656480822434.png) 20 | 21 | 在[附录D](../fu-ludcun-chu-xi-tong.md)中，我们将讨论重点从处理器转移到存储系统的问题。我们采用了一种类似的量化分析方法，但这种方法是基于对系统行为的观察，并使用端到端的方法进行性能分析。本附录讨论了如何利用成本较低的磁性存储技术有效地存储和检索数据这一重要问题。我们的重点是研究典型的I/O密集型工作负载的磁盘存储系统的性能，例如本章中提到的OLTP基准测试。我们广泛地探讨了基于RAID的系统的高级主题，该系统使用冗余磁盘来实现高性能和高可用性。最后，[附录D](../fu-ludcun-chu-xi-tong.md)介绍了排队理论，它为权衡可用和延迟提供了基础。 22 | 23 | [附录E](../fu-lueqian-ru-shi-xi-tong.md)将嵌入式计算的观点应用于各章和前述附录。 24 | 25 | [附录F](../fu-lufduo-ji-hu-lian.md)广泛探讨了系统互连的主题，包括广域网（wide area networks）和系统域网络（system area）中的计算机互联。 26 | 27 | [附录H](../fu-lu-hvliw-he-epic-de-ying-jian-he-ruan-jian.md)回顾了VLIW硬件和软件，相比之下，与EPIC在上一版前出现时相比，VLIW硬件和软件已经不那么流行了。 28 | 29 | [附录I](../fu-luida-gui-mo-duo-chu-li-qi-he-ke-xue-ji-suan-de-ying-yong.md)介绍了用于高性能计算的大规模多处理器。 30 | 31 | [附录J](../fu-lujji-suan-ji-suan-shu-arithmetic-xiang-guan.md)是第一版中唯一保留的附录，它涵盖了计算机算术。 32 | 33 | [附录K](../fu-lukzhi-ling-ji-jia-gou-de-hui-gu.md)提供了指令架构的总结，包括80x86、IBM 360、VAX，以及许多RISC架构，包括ARM、MIPS、Power、RISC-V和SPARC。附录L是新的，讨论了内存管理的高级技术，重点是对虚拟机的支持和对非常大的地址空间的地址转换设计。随着云处理器的增长，这些架构上的改进变得更加重要。 34 | 35 | 我们接下来介绍[附录M](../fu-lumli-shi-guan-dian-he-can-kao-wen-xian.md)。 36 | 37 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.5-ji-cheng-dian-lu-zhong-gong-shuai-he-neng-hao-de-fa-zhan-qu-shi/wei-chu-li-qi-nei-de-neng-hao-he-gong-shuai.md: -------------------------------------------------------------------------------- 1 | # 微处理器内的能耗和功率 2 | 3 | 对于CMOS芯片来说，传统的主要能源消耗是在开关晶体管上，也称为动态能源。每个晶体管所需的能量与晶体管所驱动的电容负载（capacitive load）和电压（voltage）的平方的乘积成正比： 4 | 5 | ![](../../.gitbook/assets/NeatReader-1656051642636.png) 6 | 7 | 这个方程式是0→1→0或1→0→1的逻辑转换的脉冲能量。那么单次转换（0→1或1→0）的能量为： 8 | 9 | ![](../../.gitbook/assets/NeatReader-1656051872089.png) 10 | 11 | 每个晶体管所需的功率只是一个转换的能量乘以转换的频率的乘积: 12 | 13 | ![](../../.gitbook/assets/NeatReader-1656051959385.png) 14 | 15 | 对于一个固定的任务，放慢时钟频率可以降低功率，但不能降低能量。 16 | 17 | 显然，动态功率和能量通过降低电压而大大减少，所以电压在20年内从5V降到了1V以下。电容负载是连接到一个输出的晶体管数量和技术的函数，它决定了导线和晶体管的电容。 18 | 19 | **示例：**当今的一些微处理器被设计成电压可调，因此电压降低15%可能会导致频率降低15%。对动态能量和动态功率的影响会怎样呢？ 20 | 21 | **答案：**因为电容没有变化，所以能量的答案是电压的比率： 22 | 23 | ![](../../.gitbook/assets/NeatReader-1656052563666.png) 24 | 25 | 这使得能量减少到原来的72%左右。对于功率，我们加上频率的比率： 26 | 27 | ![](../../.gitbook/assets/NeatReader-1656052640777.png) 28 | 29 | 可以看到，减少到了原来的61%。 30 | 31 | 随着我们从一个工艺到下一个工艺，晶体管开关数量的增加和它们频率的提高主导了负载电容和电压的减少，（译者注：但是增大的幅度过大，）导致了功耗和能量的全面增长。第一批微处理器的功耗不到一瓦，第一批32位微处理器（如英特尔80386）的功耗约为2瓦，而4.0GHz的Intel Core i7-6700K的功耗为95瓦。鉴于这些热量必须从边长约1.5厘米的芯片中散出，我们已接近空气冷却的极限，而这正是我们近十年来一直停留的地方。 32 | 33 | 考虑到前面的等式，如果我们不能降低电压，不然增加每个芯片的功率，你只能希望时钟频率的增长放缓。图 1.11 显示，自 2003 年以来，情况确实如此，即使是图 1.1 中每年表现最好的微处理器也是如此。请注意，这段较平坦的时钟速率时期与图1.1中性能改善范围缓慢的时期相对应。 34 | 35 | ![图1.11 图1.1中微处理器的时钟速率的增长。 1978 至 1986 年间，时钟速率每年提高不到 15%，而性能每年提高 22%。在1986年至2003年性能每年提高52%的 "文艺复兴时期"，时钟速率每年激增近40%。自那时起，时钟速率几乎持平，每年增长不到2%，而单处理器的性能最近每年仅提高3.5%。](../../.gitbook/assets/NeatReader-1656053294194.png) 36 | 37 | 分散功率、消除热量和防止热点已成为越来越困难的挑战。能耗现在是使用晶体管的主要制约因素；在过去，它是原始硅面积。然而现在只能在保持时钟速率持平，电源电压恒定的情况下提高能效。为此，现代微处理器发展了很多技术： 38 | 39 | 1. **什么都不做的好。**今天，大多数微处理器关闭不活动模块的时钟，以节省能源和动态功率。例如，如果没有浮点指令在执行，浮点单元的时钟就被禁用。如果一些内核处于空闲状态，它们的时钟就会停止。 40 | 2. **动态电压-频率缩放（DVFS）。**第二项技术直接来自前面的公式。PMD、笔记本电脑、甚至服务器都有低活动期，不需要在最高的时钟频率和电压下运行。现代微处理器通常提供一些时钟频率和电压，在这些频率和电压下工作，使用的功率和能量较低。图1.12显示了服务器在三种不同的时钟频率下，随着工作负荷的减少，通过DVFS可能节省的功率。2.4、1.8和1GHz。在两个步骤中的每一个步骤中，服务器的总体功率节省约为10%-15%。 41 | 3. **对症下药。**鉴于PMD和笔记本电脑经常处于闲置状态，内存和存储提供低功率模式以节省能源。例如，DRAM有一系列越来越低的功率模式，以延长PMD和笔记本电脑的电池寿命，还有人提议磁盘有一种模式，在未使用时旋转得更慢，以节省能源。然而，你不能在这些模式下访问DRAM或磁盘，所以你必须返回到完全激活的模式来进行读写，无论访问率有多低。如前所述，个人电脑的微处理器是为在高工作温度下大量使用而设计的，依靠片上温度传感器来检测何时应自动减少活动以避免过热。这种 "紧急减速 "使制造商能够为更典型的情况进行设计，然后在有人真的运行比通常情况下消耗更多电力的程序时依靠这种安全机制。 42 | 4. **超频。**英特尔在2008年开始提供Turbo模式，芯片决定在短时间内以更高的时钟速率运行是安全的，可能只是在几个核心上，直到温度开始上升。例如，3.3 GHz的Core i7可以在短时间内运行3.6 GHz。事实上，自2008年以来，图1.1所示的每年性能最高的微处理器都提供临时超频，比标称的时钟速率高出约10%。对于单线程代码，这些微处理器可以关闭除一个内核外的所有内核，运行速度更快。请注意，尽管操作系统可以关闭Turbo模式，但一旦启用就不会有任何通知，所以程序员可能会惊讶地看到他们的程序因室温而出现性能差异。 43 | 44 | ![图1.12 使用AMD Opteron微处理器、8GB DRAM和一个ATA磁盘的服务器的能源节约情况。 在1.8GHz时，服务器最多可以处理三分之二的工作负荷而不会造成服务级别的错误，在1GHz时，它只能安全地处理三分之一的工作负荷（Barroso和Hölzle, 2009中的图5.11）。](../../.gitbook/assets/NeatReader-1656054072377.png) 45 | 46 | 尽管传统上认为动态功率是CMOS中功率耗散的主要来源，但静态功率正成为一个重要的问题，因为即使在晶体管关闭时也有漏电电流流动： 47 | 48 | ![](../../.gitbook/assets/NeatReader-1656054202769.png) 49 | 50 | 也就是说，静态功率与器件的数量成正比。 51 | 52 | 因此，增加晶体管的数量会增加功率，即使它们是空闲的，而且在晶体管尺寸较小的处理器中，电流泄漏也会增加。因此，非常低功耗的系统甚至关闭不活动模块的电源（电源门控），以控制因漏电造成的损失。2011年，漏电的目标是总功耗的25%，高性能设计中的漏电有时远远超过这一目标。这类芯片的漏电率可能高达50%，部分原因是大型SRAM缓存需要电源来维持存储值。(SRAM中的S代表静态。)停止泄漏的唯一希望是关闭芯片子集的电源。 53 | 54 | 最后，由于处理器只是系统整个能源成本的一部分，使用一个更快的、能源效率较低的处理器来让系统的其他部分进入睡眠模式是有意义的。这种策略被称为 "竞速"。 55 | 56 | 功率和能耗的重要性增加了对创新效率的审查，因此现在的主要评估是每焦耳的任务或每瓦特的性能，而不是像过去那样每平方毫米的硅的性能。正如我们在[第四章](../../di-si-zhang-shi-liang-simd-he-gpu-jia-gou-zhong-de-shu-ju-ji-bing-hang-xing.md)和[第五章](../../di-wu-zhang-xian-cheng-ji-bing-hang.md)中所看到的，这种新的衡量标准影响了并行化的方法。 57 | 58 | 59 | 60 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.3-ji-suan-ji-ti-xi-jie-gou-de-ding-yi/zhi-ling-ji-jia-gou-ji-suan-ji-ti-xi-jie-gou-de-xia-ai-guan-dian.md: -------------------------------------------------------------------------------- 1 | # 指令集架构：计算机体系结构的“狭隘”观点 2 | 3 | 在本书中，我们用指令集架构（ISA）这个术语来指代实际的程序员可见的指令集。ISA是软件和硬件之间的界限。本书对ISA的快速回顾将使用80x86、ARMv8和RISC-V的例子来说明ISA的七个方面。最流行的RISC处理器来自ARM（Advanced RISC Machine），在2015年出货的148亿颗芯片中，大约是80x86处理器出货量的50倍。附录A和K给出了关于这三种ISA的更多细节。 4 | 5 | RISC-V（"RISC-5"）是加州大学伯克利分校开发的现代RISC指令集，应工业界的要求，它被免费公开采用。除了完整的软件栈（编译器、操作系统和模拟器），还有几个RISC-V的实现版本可供免费使用，用于定制芯片或现场可编程门阵列中。在第一个RISC指令集开发30年后，RISC-V继承了其前任的好的设计思想--一组大的寄存器、易于流水线排布的指令和一套精简的操作，同时避免了他们的遗漏或错误。它是前面提到的RISC架构的一个自由、开放、优雅的例子，这就是为什么有60多家公司加入了RISC-V基金会，包括AMD、谷歌、惠普、IBM、微软、Nvidia、高通、三星和西部数据。我们在本书中使用RISC-V的整数核心ISA作为示例ISA。 6 | 7 | 1. **ISA的类别**-今天几乎所有的ISA都被归类为通用寄存器架构，其中操作数是寄存器或内存位置。80x86有16个通用寄存器和16个可以保存浮点数据的寄存器，而RISC-V有32个通用寄存器和32个浮点寄存器（见图1.4）。这一类的两个流行版本是寄存器-内存式（register-memory）ISA，如80x86，它的一部分指令可以直接访问内存（译者注：比如加法指令，这类ISA可以将内存地址作为操作数放在指令中进行加载，而不需要经过寄存器）；以及加载-存储式（ load-store）ISA，如ARMv8和RISC-V，它只能通过加载或存储指令访问内存。自1985年以来公布的所有ISA都是加载-存储类型的。 8 | 2. **内存访问**-几乎所有的桌面和服务器计算机，包括80x86、ARMv8和RISC-V，都使用字节寻址来访问内存操作数。一些架构，如ARMv8，要求对象必须是对齐的。即A mod s = 0：对字节地址A处大小为s字节的对象的访问是对齐的。（见A-8页的图A.5）80x86和RISC-V不要求对齐，但如果操作数是对齐的，访问通常会更快。 9 | 3. **寻址方式**--除了指定寄存器和常数操作数外，寻址模式还指定内存对象的地址。RISC-V的寻址模式是a）寄存器、b）立即数和c）位移。对于c），立即数将作为偏移量被添加到寄存器中以形成内存地址。80x86支持上述这三种模式，还额外加上另外三种不同的形式的位移寻址：立即数偏移量寻址；依赖两个寄存器的基于索引的位移寻址；以及同样依赖两个寄存器，其中一个寄存器乘以操作数的字节大小来实现基于缩放索引和位移的寻址。此外，80x86还有更多类似于后三种模式的东西，减去位移字段，加上寄存器间接、索引和基于按比例索引。ARMv8除了有三种RISC-V寻址模式外，还附带加上PC（程序计数器寄存器）相对寻址、两个寄存器之和以及它的变体：其中一个寄存器乘以操作数的存放值。它还具有自动递增和自动递减寻址，其中计算出的地址取代了用于形成地址的一个寄存器的内容。 10 | 4. **操作数的类型和大小**-与大多数ISA一样，80x86、ARMv8和RISC-V支持8位（ASCII字符）、16位（Unicode字符或半字）、32位（整数或字）、64位（双字或长整数）的操作数，以及32位（单精度）和64位（双精度）的IEEE 754浮点。80x86还支持80位浮点（扩展双精度）。 11 | 5. **操作（Operations）**-操作的一般类别是数据传输、算术逻辑、控制（接下来讨论）和浮点。RISC-V是一个简单的、易于排布的指令集架构，它是2017年正在使用的RISC架构的代表。图1.5总结了整数RISC-V ISA，图1.6列出了浮点ISA。80x86有更丰富、更大的操作集（见[附录K](../../fu-lukzhi-ling-ji-jia-gou-de-hui-gu.md)）。 12 | 6. **控制流指令**-几乎所有的ISA，包括这三种（RISC-V，80X86，ARMv8），都支持有条件的分支、无条件的跳转、过程调用和返回。所有这三种指令都使用PC相对寻址，其中分支地址是由添加到PC上的地址域指定的。有一些小的区别。RISC-V条件性分支（BE、BNE等）测试寄存器的内容，而80x86和ARMv8分支测试作为算术/逻辑操操作的附带来设置的条件代码位。ARMv8和RISC-V程序调用将返回地址放在寄存器中，而80x86调用（CALLF）将返回地址放在内存的堆栈中。 13 | 7. **ISA的编码方式**-在编码方面有两种基本选择：固定长度和可变长度。所有ARMv8和RISC-V指令的长度为32位，这简化了指令解码。图1.7显示了RISC-V指令的格式。80x86的编码是可变长度的，范围从1到18字节。可变长度的指令可以比固定长度的指令占用更少的空间，所以为80x86编译的程序通常比为RISC-V编译的相同程序要小。请注意，前面提到的选择将影响指令如何被编码成二进制表示。例如，寄存器的数量和寻址模式的数量都对指令的大小有很大影响，因为寄存器字段和寻址模式字段可以在一条指令中出现很多次。(请注意，ARMv8和RISC-V后来提供了扩展，称为Thumb-2和RV64IC，它们分别提供了16位和32位长度的混合指令，以减少程序大小。这些紧凑版本的RISC架构的代码大小比80x86的小。见[附录K](../../fu-lukzhi-ling-ji-jia-gou-de-hui-gu.md))。 14 | 15 | ![图1.4 RISC-V的寄存器、名称、用法和调用约定。 除了32个通用寄存器（x0-x31）外，RISC-V还有32个浮点寄存器（f0-f31），可以保存32位单精度数或64位双精度数。在过程调用中保留的寄存器被标记为 "被调用者 "保存。](../../.gitbook/assets/NeatReader-1656036294746.png) 16 | 17 | ![图1.5 RISC-V中指令的子集。 RISC-V有一个基本指令集（R64I），并提供可选的扩展：乘除法（RVM）、单精度浮点（RVF）、双精度浮点（RVD）。这张图包括RVM，下一张图是RVF和RVD。附录A给出了关于RISC-V的更多细节。](../../.gitbook/assets/NeatReader-1656036763291.png) 18 | 19 | ![图1.6 RISC-V的浮点指令。 RISC-V有一个基本指令集（R64I），并为单精度浮点（RVF）和双精度浮点（RVD）提供可选的扩展。SP=单精度；DP=双精度。](../../.gitbook/assets/NeatReader-1656036839026.png) 20 | 21 | ![图1.7 基本的RISC-V指令集架构格式。 所有指令的长度为32位。R格式用于整数寄存器到寄存器的操作，如ADD、SUB等。I格式用于加载和add立即数操作，如LD和ADDI。B格式用于分支，J格式用于跳转和链接。S格式是用于存储。有一个单独的存储格式的好处是：可以使三个寄存器的指定符（rd, rs1, rs2）在所有格式中总是在同一个位置。U格式是用于宽即时指令（LUI, AUIPC）。](../../.gitbook/assets/NeatReader-1656036932626.png) 22 | 23 | 在ISA设计之外，计算机架构的设计者所面临的其他挑战在目前尤其突出，因为指令集之间的差异很小，而且有不同的应用领域。因此，从本书的第四版开始，除了这个快速回顾之外，大部分的指令集材料都可以在附录中找到（见[附录A](../../fu-luazhi-ling-ji-she-ji-yuan-ze.md)和[K](../../fu-lukzhi-ling-ji-jia-gou-de-hui-gu.md)）。 24 | 25 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.6-cheng-ben-de-fa-zhan-qu-shi/ji-cheng-dian-lu-de-cheng-ben.md: -------------------------------------------------------------------------------- 1 | # 集成电路的成本 2 | 3 | 为什么一本计算机结构的书会有一个关于集成电路成本的章节？在竞争日益激烈的计算机市场上，标准件--磁盘、闪存、DRAM等等--正在成为任何系统成本的重要组成部分，集成电路成本正在成为不同计算机成本的更大一部分，特别是在高容量、对成本敏感的市场部分。事实上，随着PMD越来越依赖整个芯片上的系统（SOC），集成电路的成本占PMD成本的大部分。因此，计算机设计师必须了解芯片的成本，以了解目前计算机的成本。 4 | 5 | 尽管集成电路的成本已经成倍下降，但硅制造的基本过程没有改变。晶圆（wafer）仍然要经过测试，然后切成晶片（dies），再进行封装（见图1.14-1.16）。因此，一个封装的集成电路的成本是： 6 | 7 | ![](../../.gitbook/assets/NeatReader-1656056146809.png) 8 | 9 | ![图1.14 英特尔Skylake微处理器芯片的照片，第四章中对其进行了评估。](../../.gitbook/assets/NeatReader-1656056159337.png) 10 | 11 | ![图1.15 在图1.14中的微处理器芯片的部件上标有其功能。](../../.gitbook/assets/NeatReader-1656056559161.png) 12 | 13 | ![图1.16 这个直径为200毫米的RISC-V芯片晶圆是由SiFive公司设计的。 它有两种类型的RISC-V芯片，使用较早的、较大的生产线生产。一个FE310芯片是2.65毫米×2.72毫米，另一个SiFive测试芯片是2.89毫米×2.72毫米。该晶圆包含1846个前者和1866个后者，共计3712个芯片。](../../.gitbook/assets/NeatReader-1656056564441.png) 14 | 15 | 在这一节中，我们主要讨论芯片的成本，最后总结一下测试和封装的关键问题。 16 | 17 | 学习如何预测每个晶圆上的好芯片的数量，首先需要学习晶圆上适合多少芯片，然后学习如何预测这些芯片中能工作的百分比。预测成本为： 18 | 19 | ![](../../.gitbook/assets/NeatReader-1656056805913.png) 20 | 21 | 芯片成本方程式的这个初始项最有趣的特点是它对芯片尺寸的敏感性，如下图所示。 22 | 23 | 每块晶圆的芯片数量大约是晶圆的面积除以芯片的面积。它可以通过以下方式更准确地估计： 24 | 25 | ![](../../.gitbook/assets/NeatReader-1656056957721.png) 26 | 27 | 第一个项是晶圆面积（πr2）与芯片面积的比率。第二项是对 "方枘圆凿 "问题的补偿--圆形晶圆外围附近的矩形芯片。用圆周率（πd）除以正方形晶粒的对角线，大约就是沿边缘的晶粒数量。 28 | 29 | **示例：**找出每块300毫米（30厘米）晶圆中边长为1.5厘米的晶片和边长为1.0厘米的晶片的数量。 30 | 31 | **答案：**当晶片面积为2.25厘米时： 32 | 33 | ![](../../.gitbook/assets/NeatReader-1656057376561.png) 34 | 35 | 因为大晶片的面积是小晶片的2.25倍，所以每块晶圆上大晶片的数量比小晶片的数量小2.25倍： 36 | 37 | ![](../../.gitbook/assets/NeatReader-1656057506513.png) 38 | 39 | 然而，这个公式只给出了每个晶圆上的最大晶片数。关键的问题是：一个晶圆上好的晶片的比例是多少，或者说是晶片产量？一个简单的集成电路良品率模型，假设缺陷是随机分布在晶圆上的，并且良品率与制造工艺的复杂性成反比，可以得出以下结果： 40 | 41 | ![](../../.gitbook/assets/NeatReader-1656057859481.png) 42 | 43 | 这个Bose-Einstein公式是通过观察许多生产线的产量而建立的经验模型（Sydow，2006），它今天仍然适用。晶圆成品率（wafer yield）用于说明完全坏的晶圆不需要进入测试环节。为简单起见，我们只假设晶圆成品率为100%，即没有完全坏掉的晶圆。每单位面积的缺陷是对发生的随机制造缺陷的一种衡量。在2017年，该值对于28纳米节点来说通常是每平方英寸0.08-0.10个缺陷，对于较新的16纳米节点来说是0.10-0.30个，因为它取决于工艺的成熟度（回顾前面提到的学习曲线）。公制版本是28纳米的每平方厘米0.012-0.016个缺陷，16纳米的0.016-0.047。最后，N是一个被称为工艺复杂度系数的参数，是对制造难度的衡量。对于2017年的28纳米工艺，N是7.5-9.5。对于16纳米工艺，N在10至14之间。 44 | 45 | 示例：假设缺陷密度为0.047/cm2，N为12，求边长为1.5cm和1.0cm的晶片产量。 46 | 47 | 答案：晶片面积分别为2.25和1.00平方厘米。对于较大的晶片，产量为： 48 | 49 | ![](../../.gitbook/assets/NeatReader-1656058409761.png) 50 | 51 | 较小的晶片，产量为： 52 | 53 | ![](../../.gitbook/assets/NeatReader-1656058472393.png) 54 | 55 | 尽管许多微处理器在1.00至2.25平方厘米之间，但低端的嵌入式32位处理器有时小到0.05平方厘米，用于嵌入式控制的处理器（用于廉价的物联网设备）通常小于0.01平方厘米，而高端服务器和GPU芯片可以大到8平方厘米。 56 | 57 | 鉴于DRAM和SRAM等商品的巨大价格压力，设计者将冗余作为提高产量的一种方式。若干年来，DRAM经常包括一些冗余的存储单元，以便可以容纳一定数量的缺陷。设计师在标准SRAM和用于微处理器内缓存的大型SRAM阵列中都使用了类似的技术。出于同样的原因，GPU在84个处理器中设有4个冗余处理器。很明显，冗余项的存在可以用来大幅提升产量。 58 | 59 | 2017年，用28纳米技术加工一个直径300毫米（12英寸）的晶圆，成本在4000至5000美元之间，16纳米晶圆的成本约为7000美元。假设加工的晶圆成本为7000美元，1.00平方厘米的芯片的成本约为16美元，但2.25平方厘米的芯片的每个芯片成本约为58美元，或几乎是小两倍多一点面积的芯片成本的四倍。 60 | 61 | 关于芯片成本，计算机设计师应该记住什么？制造工艺决定了晶圆成本、晶圆产量和单位面积的缺陷，所以设计者唯一能控制的是芯片面积。在实践中，由于每单位面积的缺陷数量较少，每个晶圆上的好芯片的数量，以及因此每个芯片的成本，大致上随着芯片面积的平方而增长。计算机设计者通过在芯片上包含或排除哪些功能以及I/O引脚的数量来影响芯片的尺寸，从而影响成本。 62 | 63 | 在我们拥有一个可以在计算机中使用的部件之前，芯片必须经过测试（以区分好的芯片和坏的芯片）、包装，并在包装后再次测试。这些步骤都会增加大量的成本，使总成本增加一半。 64 | 65 | 前面的分析集中在生产功能性芯片的可变成本上，这对大批量的集成电路来说是合适的。然而，在固定成本中，有一个非常重要的部分会大大影响小批量（少于100万个零件）的集成电路的成本，即掩模组的成本。集成电路工艺中的每一步都需要一个单独的掩模。因此，对于具有多达10个金属层的现代高密度制造工艺，16纳米的掩膜成本约为400万美元，28纳米的掩膜成本为150万美元。 66 | 67 | 好消息是，半导体公司提供 "穿梭运行"（shuttle runs），以大幅降低微小测试芯片的成本。他们通过将许多小设计放在一个晶片上以摊销掩模成本来降低成本，然后再将晶片分成小块用于每个项目。因此，台积电在2017年以30,000美元的价格提供了80-100个未经测试的晶片，这些晶片在28纳米工艺中是1.57 × 1.57毫米。虽然这些晶片很小，但它们为设计师提供了数百万个晶体管供其发挥。例如，几个RISC-V处理器将适合在这样的晶片上。 68 | 69 | 尽管穿梭运行有助于原型设计和调试运行，但它们不能解决几万到几十万个零件的小批量生产。由于掩模成本可能会继续增加，一些设计者正在加入可重构逻辑，以提高零件的灵活性，从而减少掩模的成本影响。 70 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 关于翻译 2 | 3 | ### 动机 4 | 5 | Q: 人民邮电出版社已经有了中文第六版的[出版计划](https://www.ituring.com.cn/book/2632/)，为什么还要翻译一遍？ 6 | 7 | A: 翻译的过程能帮助我们集中注意力，去理解作者表达的意图。能够更深入地掌握书中的技术要点。 8 | 9 | ### 如何翻译 10 | 11 | 这本书被称为计算机体系结构领域的“圣经”。作为考研的时候半路跨考的CS从业人员，翻译这样一本煌煌巨著难度可想而知。好在由于近几年机器翻译技术在大数据和深度学习的驱动下实现了突破性的进展，我们可以借助机器翻译来做一次粗粒度的翻译。然后由人工进行润色：调整语序，替换专业术语和修改汉语表达不通顺的语句等。本文翻译使用了 [deepl.com](https://www.deepl.com/) 提供的在线翻译服务。经测试，它在简单的语句翻译上能够做到基本通畅。 12 | 13 | ### 进度 14 | 15 |
16 | 17 | 前言 18 | 19 | * [x] [我们为什么要写这本书](qian-yan/wo-men-wei-shi-mo-xie-zhe-ben-shu.md) 20 | * [ ] [当前版本](qian-yan/dang-qian-ban-ben.md) 21 | * [ ] [选材与组织](qian-yan/xuan-cai-yu-zu-zhi.md) 22 | * [x] [内容概述](qian-yan/nei-rong-gai-shu.md) 23 | * [x] [阅读导览](qian-yan/yue-du-dao-lan.md) 24 | * [x] [章节结构](qian-yan/zhang-jie-jie-gou.md) 25 | * [x] [案例研究和习题](qian-yan/an-li-yan-jiu-yu-xi-ti.md) 26 | * [ ] [补充材料](qian-yan/bu-chong-cai-liao.md) 27 | * [ ] [帮助改进这本书](qian-yan/bang-zhu-gai-jin-zhe-ben-shu.md) 28 | * [x] [结语](qian-yan/jie-yu.md) 29 | 30 |
31 | 32 |
33 | 34 | 第一章 量化设计和分析的基础知识 35 | 36 | * [x] [摘要](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/zhai-yao.md) 37 | * [x] [1.1 介绍](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.1-jie-shao.md) 38 | * [x] [1.2 计算机的类别](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.2-ji-suan-ji-de-lei-bie/) 39 | * [x] [1.3 计算机体系结构的定义](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.3-ji-suan-ji-ti-xi-jie-gou-de-ding-yi/) 40 | * [x] [1.4 技术趋势](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.4-ji-shu-qu-shi/) 41 | * [x] [1.5 集成电路中功率和能耗的关系](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.5-ji-cheng-dian-lu-zhong-gong-shuai-he-neng-hao-de-fa-zhan-qu-shi/) 42 | * [x] [1.6 成本的发展趋势](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.6-cheng-ben-de-fa-zhan-qu-shi/) 43 | * [x] [1.7 可靠性](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.7-ke-kao-xing.md) 44 | * [x] 1[.8 评测、报告和总结性能](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.8-ping-ce-bao-gao-he-zong-jie-xing-neng/) 45 | * [x] [1.9 计算机量化设计原则](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.9-ji-suan-ji-liang-hua-she-ji-yuan-ze/) 46 | * [x] [1.10 把它们放在一起：性能、价格和功耗](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.10-ba-ta-men-fang-zai-yi-qi-xing-neng-jia-ge-he-gong-hao.md) 47 | * [x] [1.11 谬误和陷阱](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.11-miu-wu-he-xian-jing.md) 48 | * [x] [1.12 结论](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.12-jie-lun.md) 49 | * [x] [1.13 历史观点和引用](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.13-li-shi-guan-dian-he-yin-yong.md) 50 | * [ ] [案例研究和习题](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/an-li-yan-jiu-he-xi-ti.md) 51 | 52 |
53 | 54 |
55 | 56 | 第二章 内存层次结构设计 57 | 58 | 59 | 60 |
61 | 62 |
63 | 64 | 第三章 指令级并行及其应用 65 | 66 | 67 | 68 |
69 | 70 |
71 | 72 | 第四章 矢量、SIMD和GPU架构中的数据并行性 73 | 74 | 75 | 76 |
77 | 78 |
79 | 80 | 第五章 线程级并行 81 | 82 | 83 | 84 |
85 | 86 |
87 | 88 | 第六章 大规模数据中心级计算机的并行性：请求级并行（RLP）和数据级并行 89 | 90 | 91 | 92 |
93 | 94 |
95 | 96 | 第七章 领域特定架构（DSA） 97 | 98 | 99 | 100 |
101 | 102 |
103 | 104 | 附录B 内存层次结构的回顾 105 | 106 | * [x] [摘要](fu-lubnei-cun-ceng-ci-jie-gou-de-hui-gu/zhai-yao.md) 107 | * [ ] [B.1 介绍](fu-lubnei-cun-ceng-ci-jie-gou-de-hui-gu/b.1-jie-shao/) 108 | 109 |
110 | 111 | 译者：[mxlol233](https://github.com/TuringKi) 112 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.1-jie-shao.md: -------------------------------------------------------------------------------- 1 | # 1.1 介绍 2 | 3 | 自第一台通用电子计算机诞生以来的大约70年间，计算机技术取得了令人难以置信的进步。今天，不到500美元就能买到一部手机，其性能与1993年以5000万美元购买的世界上最快的计算机一样。这种快速的改进既来自于用于制造计算机的工艺技术的进步，也来自于计算机设计的创新。 4 | 5 | 尽管历史上的工艺技术改进是相当稳定的，但由更好的计算机架构带来的进步却不那么稳定。在电子计算机的前25年中，这两种力量都做出了重大贡献，每年提供大约25%的性能改进。20世纪70年代末，微处理器出现了。微处理器有能力驾驭集成电路技术的改进，导致了更高的性能改进率--大约每年增长35%。 6 | 7 | 这种增长速度，加上大规模生产的微处理器的成本优势，导致越来越多的计算机业务是基于微处理器的。此外，计算机市场的两个重大变化使新架构的商业成功比以往任何时候都容易。首先，汇编语言编程的实际取消（译者注：以c语言为代表的高级编程语言在大多数场合逐渐取代了汇编语言）减少了对目标代码兼容性的需求。其次，标准化的、与供应商无关的操作系统的建立，如UNIX及其衍生的Linux，降低了推出新架构的成本和风险。 8 | 9 | 这些变化使我们有可能在20世纪80年代初成功地开发出一套具有更简单指令的新架构，称为RISC（精简指令集计算机）架构。基于RISC的机器将设计者的注意力集中在两个关键的性能技术上，即利用指令级的并行性（最初通过流水线，后来通过多指令问题）和使用缓存（最初以简单的形式，后来使用更复杂的组织和优化）。 10 | 11 | 基于RISC的计算机提高了性能标准，迫使以前的架构跟上或消失。数字设备公司（Digital Equipment）的Vax无法做到，因此它被RISC架构所取代。英特尔迎接了这一挑战，主要是通过在内部将80x86指令翻译成类似RISC的指令，使其能够采用许多首先在RISC设计中开创的创新。随着90年代末晶体管数量的飙升，翻译更复杂的x86架构的硬件开销变得可以忽略不计。在低端设备中，如手机，x86转换开销的功率和硅面积成本劣势使得基于RISC架构的ARM成为主导。 12 | 13 | 图1.1显示，架构和组织改进的结合导致了 17 年来性能的持续增长，年增长率超过 50%，这在计算机行业是前所未有的。 14 | 15 | ![图1.1 该图描述了相对于VAX 11/780的程序性能，由SPEC整数基准测量（见1.8节）。在20世纪80年代中期之前，处理器性能的增长主要是由制造工艺驱动的，平均每年约22%，或者说每3.5年性能就翻一番。从1986年开始增长到约52%，或每两年翻一番，这要归功于RISC架构中典型的更先进的架构和组织思想。到2003年，这种增长导致了与继续以22%的速度增长时的性能相差约25倍。2003 年，由于 Dennard定律和可用的指令级并行化时代的结束，单处理器的性能在 2011 年之前放缓到每年 23%，或每 3.5 年翻一番。(自2007年以来，最快的SPECintbase性能已经开启了自动并行化，所以单核处理器的速度更难衡量）。这些结果仅限于单芯片系统，每个芯片通常有四个内核）。从2011年到2015年，每年的改进不到12%，或每8年翻一番，部分原因是阿姆达尔定律的并行性限制。自2015年以来，随着摩尔定律的结束，每年的改进仅为3.5%，或每20年翻一番 面向浮点计算的性能也遵循同样的趋势，但通常在每个阴影区域有1%到2%的高年增长率。图1.11显示了这些相同时代的时钟速率的改进。由于SPEC多年来发生了变化，较新机器的性能是通过一个比例系数来估计的，该系数与不同版本的SPEC的性能有关。SPEC89、SPEC92、SPEC95、SPEC2000和SPEC2006。SPEC2017的结果太少了，还无法绘制。](../.gitbook/assets/NeatReader-1655966534161.png) 16 | 17 | 在20世纪，这种急剧增长产生了四方面的影响。首先，它大大提高了计算机的算力。对于许多应用，最高性能的微处理器超过了不到20年前的超级计算机。 18 | 19 | 其次，这种性价比的大幅提高导致了新一类计算机的出现。个人电脑和工作站在20世纪80年代随着微处理器的出现而面世。过去十年，智能手机和平板电脑兴起，许多人将其作为主要的计算平台，而不是PC。这些移动客户端设备越来越多地使用互联网来访问包含10万台服务器的数据仓库，这些服务器被设计得就像一台单一的巨型计算机。 20 | 21 | 第三，正如摩尔定律所预测的那样，半导体制造的工艺改进导致了基于微处理器的计算机在整个计算机设计范围内的主导地位。传统上用现成的逻辑或门阵列制造的微型计算机，被使用微处理器制造的服务器所取代。甚至大型计算机和高性能超级计算机也都是微处理器的集合。 22 | 23 | 前面的硬件创新导致了计算机设计的复兴，它既强调架构创新又强调有效利用工艺技术改进。这种增长速度是复合型的，所以到2003年，高性能微处理器的速度是单纯依靠工艺技术（包括改进的电路设计）获得的7.5倍，即每年52%，对比单纯靠工艺技术的35%。 24 | 25 | 这种硬件的复兴导致了第四个影响，即对软件开发的影响。自1978年以来，这种50,000倍的性能改进（见图1.1）使现代程序员能够以性能换取生产力。取而代之的是C和C++这样面向性能的语言，今天更多的编程是用Java和Scala这样的管理型编程语言完成的。此外，像JavaScript和Python这样的脚本语言甚至更有生产力，与AngularJS和Django这样的编程框架一起越来越受欢迎。为了保持生产力并努力缩小性能差距，带有即时编译器和基于跟踪的编译的解释器正在取代过去的传统编译器和链接器。软件部署也在发生变化，通过互联网使用的软件即服务（SaaS）取代了必须在本地计算机上安装和运行的需要安装的软件。 26 | 27 | 应用程序的性质也在变化。语音（speech）、声音（sound）、图像和视频正变得越来越重要，还有对用户体验非常关键的可预测的响应时间。一个鼓舞人心的例子是谷歌翻译。这个应用程序让你举起你的手机，把它的摄像头对准一个物体，图像就会通过互联网无线发送到一个仓库级计算机（WSC），该计算机可以识别照片中的文字并将其翻译成你的母语。你也可以对它说话，它将把你说的话翻译成另一种语言的音频输出。它可以翻译90种语言的文字和15种语言的语音。 28 | 29 | 图1.1还显示，这17年的硬件复兴已经结束。根本原因是半导体工艺的维持了几十年的两个特征，现在已经不复存在。 30 | 31 | 1974年，罗伯特-丹纳德（Robert Dennard）观察到，由于每个晶体管的尺寸较小，即使你增加了晶体管的数量，对于一定面积的硅，功率密度也是恒定的。值得注意的是，晶体管可以工作的得更快，但使用更少的功率。Dennard定律在2004年左右结束，因为电流和电压不能持续下降而仍然保持集成电路的可靠性。 32 | 33 | 这一变化迫使微处理器行业使用多个高效处理器或内核，而不是单一的低效处理器。事实上，2004 年英特尔取消了其高性能单核处理器项目，并与其他公司一起宣布，通向更高性能的道路将是通过每个芯片的多个处理器，而不是通过更快的单核处理器。这一里程碑标志着从单纯依靠指令级并行（ILP）（本书前三版的主要关注点）向数据级并行（DLP）和线程级并行（TLP）的历史性转变，这在第四版中有所体现，在第五版中有所扩展。第五版还增加了WSC和请求级并行（RLP），这在本版中得到了扩展。编译器和硬件的协同利用ILP而不需要程序员的关注（译者注：对应用层的程序员来讲是透明的），而DLP、TLP和RLP是显式并行，需要对应用程序进行重组，使其能够利用显式并行。在少数情况下，这很容易；但在许多情况下，这对程序员来说是一个重大的新负担。 34 | 35 | 阿姆达尔定律（第1.9节）规定了每个芯片有用内核数量的实际限制。如果10%的任务是串行的，那么无论你在芯片上放多少个核，并行化的最大性能收益是10。 36 | 37 | 最近结束的第二个观察是摩尔定律。1965年，戈登-摩尔（Gordon Moore）著名地预言，每块芯片的晶体管数量将每年翻一番，1975年修正为每两年一次。这一预测持续了大约50年，但不再成立。例如，在本书的2010年版中，最新的英特尔微处理器有1,170,000,000个晶体管。如果摩尔定律继续下去，我们可以预计2016年的微处理器将有18,720,000,000个晶体管。相反，相当的英特尔微处理器只有1,750,000,000个晶体管，与摩尔定律所预测的有10倍的差距。 38 | 39 | 下述事项： 40 | 41 | * 由于摩尔定律的放缓和Dennard定律的结束，晶体管的性能不再有很大的提高。 42 | * 微处理器的功率设计不变。 43 | * 用几个高能效的处理器取代单个高能耗的处理器。 44 | * 阿姆达尔定律导致的多处理的限制。 45 | 46 | 的综合导致了处理器性能的提高将放缓，即每20年翻一番，而不是像1986年至2003年期间那样每1.5年翻一番（见图1.1）。 47 | 48 | 提高能效-性能-成本的唯一途径是专业化。未来的微处理器将包括几个特定领域的内核，这些内核仅能很好地完成一类计算，但它们比通用内核做得明显更好。本版新的[第七章](../di-qi-zhang-ling-yu-te-ding-jia-gou-dsa.md)介绍了特定领域的体系结构。 49 | 50 | 关于架构思想和伴随的编译器改进，使上个世纪令人难以置信的增长速度成为可能。本书也将介绍导致这些巨大变化的原因，以及21世纪的新的架构思想、编译器和解释器的挑战和初步有希望的方法。其核心是计算机设计和分析的定量方法，以程序的经验观察、实验和模拟作为其工具。本书反映的正是这种计算机设计的风格和方法。本章的目的是为下面的章节和附录奠定定量的基础。 51 | 52 | 写这本书不仅是为了解释这种设计风格，也是为了激励你为这一进步做出贡献。我们相信这种方法将为未来的计算机服务，就像它对过去的隐式并行计算机起作用一样。 53 | 54 | -------------------------------------------------------------------------------- /qian-yan/nei-rong-gai-shu.md: -------------------------------------------------------------------------------- 1 | # 内容概述 2 | 3 | [第一章](../di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/)包括能效、静态功率、动态功率、集成电路成本、可靠性和可用性的公式。(这些公式也可以在封面内页找到。)我们希望这些主题可以贯穿本书的其他部分。除了计算机设计和性能测量的经典定量原则外，本书还展示了通用微处理器性能改进的缓慢过程，这也是特定领域架构（DSA）的一个灵感来源。 4 | 5 | 我们的观点是，与1990年相比，今天的指令集结构所起的作用较小，因此我们将这一材料移到了[附录A](../fu-luazhi-ling-ji-she-ji-yuan-ze.md)。它现在使用RISC-V架构。(为了快速回顾，RISC-V ISA的摘要可以在封面内页找到)。对于ISA的爱好者来说，[附录K](../fu-lukzhi-ling-ji-jia-gou-de-hui-gu.md)为这个版本进行了修订，涵盖了8种RISC架构（5种用于桌面和服务器，3种用于嵌入式）、80×86、DEC VAX和IBM 360/370。 6 | 7 | 然后，我们在[第二章](../di-er-zhang-nei-cun-ceng-ci-jie-gou-she-ji.md)中转入内存的层次结构，因为很容易将成本-性能-功耗原则应用到这个问题中，而且内存是其余章节的关键资源。和过去的版本一样，[附录B](../fu-lubnei-cun-ceng-ci-jie-gou-de-hui-gu/)包含了对高速缓存原理的介绍性回顾，可以在你需要的时候使用。[第二章](../di-er-zhang-nei-cun-ceng-ci-jie-gou-she-ji.md)讨论了缓存的10个高级优化技术。本章也将介绍虚拟机，它在保护、软件管理和硬件管理方面具有优势，并在云计算中发挥着重要作用。除了涵盖SRAM和DRAM技术外，该章还包括关于闪存和使用堆叠式芯片封装来扩展内存层次的资料介绍。PIAT的例子是用于PMD的ARM Cortex A8和用于服务器的Intel Core i7。 8 | 9 | [第三章](../di-san-zhang-zhi-ling-ji-bing-hang-ji-qi-ying-yong.md)涉及高性能处理器中指令级并行的使用，包括超标量执行、分支预测（包括新的标记混合预测器）、推测、动态调度和同步多线程。如前所述，[附录C](../fu-lucliu-shui-xian-chu-ji-he-zhong-ji-gai-nian.md)是对流水线的回顾，以防你需要它。[第三章](../di-san-zhang-zhi-ling-ji-bing-hang-ji-qi-ying-yong.md)还探讨了ILP的局限性。和[第二章](../di-er-zhang-nei-cun-ceng-ci-jie-gou-she-ji.md)一样，PIAT的例子还是ARM Cortex A8和Intel Core i7。虽然第三版包含了大量关于Itanium和VLIW的内容，但这些材料现在在附录H中，表明我们认为这种架构没有达到早期的要求。 10 | 11 | 游戏和视频处理等多媒体应用的重要性日益增加，这也提高了能够利用数据级并行性的架构的重要性。特别是，人们对使用图形处理单元（GPU）进行计算的兴趣越来越大，但很少有架构师了解GPU的真正工作原理。我们决定写一个新的章节，在很大程度上是为了揭开这种新式计算机架构的面纱。[第四章](../di-si-zhang-shi-liang-simd-he-gpu-jia-gou-zhong-de-shu-ju-ji-bing-hang-xing.md)首先介绍了矢量架构，作为解释多媒体SIMD指令集扩展和GPU的基础。(本章介绍了Roofline性能模型，然后用它来比较英特尔酷睿i7和NVIDIA GTX 280和GTX 480 GPU。本章还介绍了用于PMD的Tegra 2 GPU。 12 | 13 | [第五章](../di-wu-zhang-xian-cheng-ji-bing-hang.md)介绍了多核处理器。它探讨了对称和分布式内存架构，研究了组织原则（organizational principles）和性能。本章的主要补充内容包括对多核组织的更多比较，包括多核多级缓存的组织、多核一致性方案和片上多核互连。接下来是同步和内存一致性模型方面的话题。例子是Intel Core i7。对互连网络更深入感兴趣的读者应阅读[附录F](../fu-lufduo-ji-hu-lian.md)，对更大规模的多核处理器和科学计算感兴趣的读者应阅读[附录I](../fu-luida-gui-mo-duo-chu-li-qi-he-ke-xue-ji-suan-de-ying-yong.md)。 14 | 15 | [第6章](../di-liu-zhang-da-gui-mo-shu-ju-zhong-xin-ji-ji-suan-ji-de-bing-hang-xing-qing-qiu-ji-bing-hang-rlp-he.md)介绍了数据仓库级计算机（Warehouse-Scale Computers, WSCs）。它在谷歌和亚马逊网络服务的工程师的帮助下进行了广泛的修订。本章整合了很少有架构师知道的关于WSCs的设计、成本和性能的细节。它从流行的MapReduce编程模型开始，然后描述了WSCs的架构和物理实现，包括成本。成本使我们能够解释云计算的出现，据此，在云中使用WSCs进行计算可能比在本地数据中心计算更便宜。PIAT的例子是对谷歌WSC的描述，其中包括本书中首次发布的信息。 16 | 17 | 新的[第七章](../di-qi-zhang-ling-yu-te-ding-jia-gou-dsa.md)激发了对特定领域架构（DSA）的需求。它在四个DSA实例的基础上得出了DSA的指导原则。每个DSA都对应于已经部署在商业环境中的芯片。我们还解释了为什么在通用微处理器的单线程性能停滞不前的情况下，我们期望通过DSA实现计算机架构的复兴。 18 | 19 | [附录A](../fu-luazhi-ling-ji-she-ji-yuan-ze.md)涵盖了ISA的原理，包括RISC-V，[附录K](../fu-lukzhi-ling-ji-jia-gou-de-hui-gu.md)描述了64位版本的RISC V、ARM、MIPS、Power和SPARC及其多媒体扩展。它还包括一些经典架构（80x86、VAX和IBM 360/370）和流行的嵌入式指令集（Thumb-2、microMIPS和RISCV C）。[附录H](../fu-lu-hvliw-he-epic-de-ying-jian-he-ruan-jian.md)是相关的，因为它涵盖了VLIW ISA的架构和编译器。 20 | 21 | 如前所述，[附录B](../fu-lubnei-cun-ceng-ci-jie-gou-de-hui-gu/)和[附录C](../fu-lucliu-shui-xian-chu-ji-he-zhong-ji-gai-nian.md)是关于基本缓存和流水线概念的教程。对缓存比较陌生的读者应该在[第二章](../di-er-zhang-nei-cun-ceng-ci-jie-gou-she-ji.md)之前阅读[附录B](../fu-lubnei-cun-ceng-ci-jie-gou-de-hui-gu/)，而对流水线比较陌生的读者应该在第三章之前阅读[附录C](../fu-lucliu-shui-xian-chu-ji-he-zhong-ji-gai-nian.md)。 22 | 23 | [附录D](../fu-ludcun-chu-xi-tong.md)，"存储系统"，扩充了如下内容：对可靠性和可用性的讨论，对RAID进行了指导性介绍，对RAID 6方案进行了描述，并对真实系统的故障统计数据进行了罕见的介绍。它继续提供了对排队理论和I/O性能基准的介绍。我们评估了一个真实集群的成本、性能和可靠性：互联网档案馆（Internet Archive）。“把它放在一起”的例子是NetApp FAS6000档案机。 24 | 25 | Thomas M. Conte 撰写的[附录E](../fu-lueqian-ru-shi-xi-tong.md)，将嵌入式相关的材料整合到一个地方。 26 | 27 | 关于多机互联的[附录F](../fu-lufduo-ji-hu-lian.md)，由Timothy M. Pinkston和José Duato修订。[附录G](../fu-lugshen-ru-xiang-liang-chu-li-qi.md)，最初由Krste Asanović撰写，包括对矢量处理器的描述。我们认为这两个附录是我们所知道的关于每个主题的一些最好的材料。 28 | 29 | [附录H](../fu-lu-hvliw-he-epic-de-ying-jian-he-ruan-jian.md)介绍了VLIW和EPIC，即Itanium的架构。 30 | 31 | [附录I](../fu-luida-gui-mo-duo-chu-li-qi-he-ke-xue-ji-suan-de-ying-yong.md)描述了并行处理的应用和更大规模的、共享内存多处理的一致性协议。[附录J](../fu-lujji-suan-ji-suan-shu-arithmetic-xiang-guan.md)，由David Goldberg撰写，描述了计算机算术。 32 | 33 | Abhishek Bhattacharjee撰写的[附录L](../fu-luldi-zhi-fan-yi-address-translation-de-gao-ji-gai-nian.md)是新的，讨论了内存管理的高级技术，重点是对虚拟机的支持和对超大地址空间的地址转换设计。随着云计算处理器的增长，这些架构上的改进正变得越来越重要。 34 | 35 | [附录M](../fu-lumli-shi-guan-dian-he-can-kao-wen-xian.md)将每一章的 "历史观点和参考文献 "收集到一个附录中。它试图对每一章中的想法给予适当的肯定，并对围绕这些发明的历史有所了解。我们喜欢把这看作是介绍计算机设计的戏剧。它还提供了计算机体系结构的学生可能想要追求的参考资料。如果你有时间，我们建议阅读这些章节中提到的该领域的一些经典论文。直接从创作者那里听到这些想法，既愉快又有教育意义。"历史透视 "是以前版本中最受欢迎的部分之一。 36 | 37 | 38 | 39 | -------------------------------------------------------------------------------- /fu-lubnei-cun-ceng-ci-jie-gou-de-hui-gu/b.1-jie-shao/si-ge-nei-cun-ceng-ci-de-wen-ti.md: -------------------------------------------------------------------------------- 1 | # 四个内存层次的问题 2 | 3 | 我们继续介绍缓存，回答关于内存层次结构第一层的四个常见问题： 4 | 5 | * Q1: 块可以放在上一级的什么地方？(块放置) 6 | * Q2: 如果一个块在上一级，如何找到它？(块识别) 7 | * Q3: 在未命中的情况下，应该替换哪个块？(块替换) 8 | * Q4: 写入时发生什么？(写策略) 9 | 10 | 对这些问题的回答有助于我们理解层次结构中不同层次内存的不同权衡；因此，我们对每一个例子都要问这四个问题。 11 | 12 | Q1:块可以放在上一级的什么地方？ 13 | 14 | 图B.2显示，对块放置位置的限制创造了三种类型的缓存组织： 15 | 16 | * 如果每个块在缓存中只有一个地方可以映射，那么缓存就被称为直接映射。这种映射通常是： 17 | 18 | (块地址) MOD (_缓存中块的个数_)，MOD是取模操作。 19 | * 如果一个块可以放在缓存的任何地方，那么这个缓存就可以说是全相联的。 20 | * 如果一个块可以被放置在缓存中的某个区域，那么缓存就是组相联的。一个组是缓存中块的集合。一个块首先被映射到一个集合上，然后该块可以被放置在该集合的任何地方。这个集合通常是通过位选择（bit selection）的，也就是说：(块地址) MOD (组的个数)。 21 | 22 | ![图B.2 这个例子的缓存有8个块帧（block frames），内存有32个块。 缓存的三个选项从左到右显示。在全相联的情况下，下层块12可以进入缓存的八个块帧中的任何一个。在直接映射的情况下，第12块只能被放入第4个块帧（12的模数为8）。组相联——具有这两种特性的一部分——允许块被放置在组0（12模4）的任何地方。每组有两个块，这意味着块12可以放在缓存的第0块或第1块中。真正的高速缓存包含成千上万的块帧，而真正的存储器包含数百万的块。组相联有四组，每组有两个块，称为双组相联。假设缓存中没有任何东西，有关的块地址标识的是低级块12。](../../.gitbook/assets/NeatReader-1656577525140.png) 23 | 24 | 如果一个集合中有n个块，那么这个缓存就被称为n路组相联（n-way set associative）。 25 | 26 | 从直接映射到全相联的缓存范围实际上是一个组相联的连续体。直接映射是单路组相联，而一个有m个块的全相联可以被称为 "m路组相联"。等价地，直接映射可以被认为是有m个集合，而全相联则是只有一个集合。 27 | 28 | 今天绝大多数的处理器缓存都是直接映射、双路组相联或四路组相联，原因我们很快就会看到。 29 | 30 | Q2: 如果一个块在上一级，如何找到它？ 31 | 32 | 缓存在每个块帧上都有一个地址标签（tag），用来表示块地址。每一个可能包含所需信息的缓存块的标签都会被检查，看它是否与来自处理器的块地址相匹配。通常情况下，所有可能的标签都是并行搜索的，因为速度是至关重要的。 33 | 34 | 必须有一种方法可以判断缓存块是否存在有效信息。最常见的方法是给标签添加一个有效位，以说明这个条目是否包含有效地址。如果该位没有被设置，那么这个地址上就不可能有匹配。 35 | 36 | 在进行下一个问题之前，让我们探讨一下处理器地址与缓存的关系。图B.3显示了一个地址是如何划分的。第一个划分是在块状地址和块状偏移之间。块帧地址可以进一步划分为标签（tag）字段和索引（index）字段。块偏移字段从块中选择所需的数据，索引字段选择集合，而标签字段则与之比较，以检查是否命中。尽管可以在用地址进行比较（译者注：bit位更多），但没有必要，因为有以下情况： 37 | 38 | * 偏移量不应被用于比较，因为整个块要么存在，要么不存在。因此，根据定义，所有块的偏移量都会导致匹配。 39 | * 检查索引是多余的，因为它被用来选择要检查的集合。例如，一个存储在集合0中的地址，其索引字段必须为0，否则就不能存储在集0中；集1必须有一个索引值为1；以此类推。这种优化通过减少缓存标签的bit位宽度来节省硬件和功耗。 40 | 41 | ![图B.3 在组相联或直接映射的缓存中，地址的三个部分。 标签用于检查该组中的所有块，索引用于选择该组。块的偏移量是该块中所需要的数据的地址。全相联的缓冲区没有索引字段。](../../.gitbook/assets/NeatReader-1656771737281.png) 42 | 43 | 如果缓存的总大小保持不变，增加关联性就会增加每组块的数量，从而减少索引的大小，增加标签的大小。也就是说，图B.3中的标签-索引边界随着关联性的增加而向右移动，全相联的缓存没有索引区域。 44 | 45 | 在未命中的情况下，应该替换哪个块？ 46 | 47 | 当未命中发生时，缓存控制器必须选择一个块来替换所需的数据。直接映射的一个好处是，硬件决策被简化了--事实上，简单到没有选择：只有一个块帧被检查为命中，并且只有那个区块可以被替换。在全相联或组相联放置的情况下，有许多块可以在未命中时选择。有三种主要的策略用于选择要替换的区块： 48 | 49 | * 随机--为了统一分配，候选块是随机选择的。一些系统生成伪随机块号以获得可重复的行为，这在调试硬件时特别有用。 50 | * 最近使用最少( Least Recently Used, LRU)--为了尽量避免扔掉即将需要的信息，可以对块的访问进行记录。依靠过去来预测未来，被替换的区块是未使用时间最长的。LRU依靠的是局部性的推论：如果最近使用的区块有可能被再次使用，那么一个很好的处理对象就是最近使用最少的区块。 51 | * 先入先出（_First In, First Out_, FIFO）--由于LRU的计算可能很复杂，可以通过确定最老的块而不是LRU来逼近LRU。 52 | 53 | 随机替换的一个优点是，它很容易在硬件中建立。随着需要跟踪的块数量增加，LRU实现将变得越来越难以负担，而且通常只是近似的。一个常见的近似方法（通常被称为伪LRU）是为缓存中的每一个块提供一组比特位，每一个比特对应于缓存中的一路（way)（在一个组相联缓存中，一路对应一个bank；在四路组相联缓存中就有四路）。当一个集合被访问时，与包含所需块的某路相对应的位被打开；如果与一个集合相关的所有位都被打开，那么除了最近被打开的位之外，它们被重置。当一个块必须被替换时，处理器从其位被关闭某路中选择一个区块，如果有多个选择，通常是随机的。这近似于LRU，因为被替换的块在最后一次访问集合中的所有区块后就没有被访问过。图B.4显示了LRU、随机和FIFO替换之间的失误率差异。 54 | 55 | ![图B.4 每1000条指令中的数据缓存未命中率，比较了LRU、随机的和FIFO几种方法在不同大小和关联度下的结果。 对于最大尺寸的缓存，LRU和随机之间的差别不大，LRU在较小的缓存中的表现优于其他的缓存。在较小的高速缓存中，FIFO通常优于随机。这些数据是使用10个SPEC2000基准为Alpha架构收集的64字节的块大小。五个来自SPECint2000（gap、gcc、gzip、mcf和perl），五个来自SPECfp2000（applu、art、equake、lucas和swim）。我们将在本附录的大多数数字中使用这台计算机和这些基准。](../../.gitbook/assets/NeatReader-1656775564259.png) 56 | 57 | Q4：写入时发生什么？ 58 | 59 | 读取主导了处理器的缓存访问。所有的指令访问都是读，并且大多数指令都不写到内存。附录A中的图A.32和A.33表明，RISC V程序的存储（store）量指令占10%，加载（load）指令占为26%，因此写入量为10%/(100% + 26% + 10%)，即占整个内存流量的7%。在数据缓存流量中，写入量为10%/(26%+10%)，即28%。要使普通情况下的速度变快意味着需要优化缓存的读取，特别是因为处理器传统上要等待读取完成，但不需要等待写入。然而，Amdahl定律（第1.9节）提醒我们，高性能的设计不能忽视写入的速度。 60 | 61 | 幸运的是，常见的情况也是容易实现快速的情况。在读取和比较标签的同时，可以从高速缓存中读取块，所以一旦有了块地址，就开始读取块。如果读取命中，块请求的部分会立即传递给处理器。如果是未命中，则没有任何好处--但也没有任何坏处，除了在台式机和服务器计算机中更多的功率；只是忽略了读取的值。 62 | 63 | 这种乐观的态度是不允许用于写的。在检查标签以确定地址是否命中之前，不能开始修改一个块。因为标签检查不能并行进行，所以写的时间通常比读的时间长。另一个复杂性是，处理器还指定了写的大小，通常在1到8字节之间；只有一个块的那部分可以被改变。相比之下，读可以毫无顾忌地访问更多的字节。 64 | 65 | 写入的策略往往能区分缓存的设计。在向高速缓存写入时，有两种基本的选择： 66 | 67 | * Write through-信息被写入缓存中的块_和下一_级内存中的块。 68 | * Write back-信息只写到缓存中的块。修改后的缓存块只有在被替换时才会被写入主内存。 69 | 70 | 为了减少替换时writing back的频率，通常使用一种叫做dirty bit的功能。这个状态位表示该块是脏的（在高速缓存中被修改过）还是干净的（没有被修改过）。如果它是干净的，那么这个区块就不会被写回，因为与缓存相同的信息会在低一级别内存中找到。 71 | 72 | write back和write through都有其优点。在write back的情况下，写入是以缓存的速度进行的，在一个块内的多次写入只需要向低级别的内存写一次。由于一些写操作不进入内存，write back使用较少的内存带宽，使其在多处理器中具有吸引力。由于write back对内存层次结构的其余部分和内存互连的使用比通写少，所以它还能节省功耗，使其对嵌入式应用也具有吸引力。 73 | 74 | Write through比回写更容易实现。缓存始终是干净的，所以与write back不同的是，读取未命中永远不会导致写到更低的层次。Write through还有一个优点，就是下一级有最新的数据拷贝，这就简化了数据的一致性。数据一致性对于多处理器和I/O来说是很重要的，我们在第四章和附录D中对此进行了研究。多级缓存使上层缓存的写入更加可行，因为写入只需要传播到下一级，而不是一直传播到主内存。 75 | 76 | 正如我们将看到的，I/O和多处理器是善变的：他们希望处理器缓存 write back，以减少内存流量，并通过write through来保持缓存与内存层次结构的低层一致。 77 | 78 | 当处理器在write through过程中必须等待写入完成时，处理器就被说成是写停滞（write stall）。一个常见的减少写停滞的优化是write buffer，它允许处理器在数据被写入缓冲区后立即继续，从而使处理器的执行与内存的更新重叠。我们很快就会看到，即使有写缓冲区，也会出现写停滞。 79 | 80 | 因为写的时候不需要数据，所以在写未命中的时候有两种选择： 81 | 82 | * Write allocate--块在写未命中时被分配，然后是前面的写入命中动作。在这个寻常的选项中，写未命中的行为与读未命中一样。 83 | * No-write allocate--这显然是不寻常的选择，写未命中不影响缓存。相反，该块只在低一级的内存中被修改。 84 | 85 | 因此，在无写分配的情况下，块会留在缓存之外，直到程序试图读取这些块。但即使是只写的区块，也会在写分配的情况下留在缓存中。我们来看看一个例子。 86 | 87 | **示例**：假设一个有许多缓存条目的全相联的write-back式缓存，开始时是空的。下面是五个内存操作的序列（地址在方括号中）。 88 | 89 | ``` 90 | Write Mem[100]; 91 | Write Mem[100]; 92 | Read Mem[200]; 93 | Write Mem[200]; 94 | Write Mem[100]. 95 | ``` 96 | 97 | 当使用no-write allocate与write allocate时，命中和未命中的数量是多少？ 98 | 99 | **答案**：对于no-write allocate，地址100不在缓存中，写的时候没有分配，所以前两次写的时候会导致未命中。地址200也不在高速缓存中，所以读也是一个未命中。随后对地址200的写是一个命中。最后一次对100的写仍然是一个未命中。no-write allocate的结果是四次未命中和一次命中。 100 | 101 | 对于write allocate，对100和200的第一次访问是未命中，其余的都是命中，因为100和200都在高速缓存中找到。因此，写分配的结果是两次未命中和三次命中。 102 | 103 | 无论哪种写未命中策略都可以使用write through或 write back。通常情况下，write-back 式缓存使用write allocate，希望随后对该块的写会被缓存捕获。Write-through写缓存通常使用no-write allocate。其理由是，即使有对该块的后续写操作，这些写操作仍然必须进入低级别的内存，那么有什么好处呢？ 104 | 105 | 106 | 107 | 108 | 109 | -------------------------------------------------------------------------------- /di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.11-miu-wu-he-xian-jing.md: -------------------------------------------------------------------------------- 1 | # 1.11 谬误和陷阱 2 | 3 | 本节将在每一章中出现，目的是解释一些你应该避免的普遍存在的错误观念或误解。我们把这种误信称为谬误。在讨论一个谬误时，我们试图给出一个反例。我们也讨论陷阱--容易犯的错误。通常情况下，陷阱是对原则的概括，而这些原则在有限的背景下是真实的。这些章节的目的是帮助你避免在你设计的计算机中犯这些错误。 4 | 5 | **陷阱** _所有的指数规律都将应验。_ 6 | 7 | 第一个被淘汰的是Dennard定律。Dennard在1974年的观察是，随着晶体管变小，功率密度是不变的。如果一个晶体管的线性区域缩小了2倍，那么电流和电压也减少了2倍，因此它使用的功率下降了4倍。Dennard定律在被观察到30年后结束了，不是因为晶体管没有继续变小，而是因为集成电路的可靠性限制了电流和电压可以下降的程度。阈值电压被驱动得如此之低，以至于静态功率成为总功率的一个重要部分。 8 | 9 | 下一个例子是硬盘驱动器。虽然磁盘没有规律可循，但在过去30年中，硬盘的最大面积密度--它决定了磁盘容量--每年提高30%-100%。在最近几年里，每年的增长率低于5%。每块硬盘密度的提高主要来自于在硬盘上增加更多的盘片。 10 | 11 | 接下来是古老的摩尔定律。自从每块芯片的晶体管数量每隔一到两年就翻一番以来，已经有一段时间了。例如，2014年推出的DRAM芯片包含80亿个晶体管，直到2019年我们才会有160亿个晶体管的DRAM芯片投入量产。但如果按照摩尔定律的预测，那将会有640亿个晶体管的DRAM芯片。 12 | 13 | 此外，平面逻辑晶体管数目的实际扩张的结束甚至被预测为到2021年。图1.22显示了两版《国际半导体技术路线图》（ITRS）对逻辑晶体管门长度的预测。与2013年报告预测到2028年栅极长度将达到5纳米不同，2015年报告预测到2021年长度停止在10纳米。此后的密度改进将不得不来自缩小晶体管尺寸以外的其他方式。这并不像ITRS建议的那样可怕，因为像英特尔和台积电这样的公司已经计划将逻辑门长度缩小到3纳米，但是变化的速度正在下降。 14 | 15 | ![图1.22 从两版ITRS报告中对逻辑晶体管尺寸的预测。 这些报告始于2001年，但2015年将是最后一版，因为该小组因兴趣减退而解散了。今天能够生产最先进的逻辑芯片的公司只有GlobalFoundaries、英特尔、三星和台积电，而在第一份ITRS报告发布时有19家。由于只剩下四家公司，分享计划太难维持。摘自IEEE Spectrum，2016年7月，"摩尔定律路线图预测，晶体管将在2021年停止缩小"，作者Rachel Courtland。](../.gitbook/assets/NeatReader-1656408465465.png) 16 | 17 | 图1.23显示了微处理器和DRAM--它们受到Dennard定律的结束和摩尔定律的影响--以及磁盘的带宽随时间增长的变化。技术改进的放缓在下降的曲线中很明显。网络的持续改进是由于光纤的进步和脉冲振幅调制（PAM-4）的计划改变，允许两比特编码，以便以400Gbit/s的速度传输信息。 18 | 19 | ![图1.23 根据图1.10中的数据，微处理器、网络、内存和磁盘在一段时间内的相对带宽提升。](../.gitbook/assets/NeatReader-1656408708450.png) 20 | 21 | **谬论** _多核处理器是银弹。_ 22 | 23 | 2005年左右转向每片多处理器并不是因为有什么突破，大大简化了并行编程或使建立多核计算机变得容易。发生这种变化是因为由于ILP墙和功率墙的存在，没有其他选择。每个芯片上的多个处理器并不能保证更低的功率；设计一个使用更高功率的多核芯片当然是可行的。潜力只是有可能通过用几个较低时钟频率的高效内核取代一个高时钟频率的低效内核来继续提高性能。随着缩小晶体管的技术改进，它可以将电容和电源电压都缩小一些，这样我们就可以在每一代的内核数量上得到适度的增加。例如，在过去的几年里，英特尔在他们的高端芯片中每一代都会增加两个内核。 正如我们将在第4章和第5章中看到的，性能提升现在是程序员的工作。程序员依靠硬件设计者来使他们的程序更快，而不用动一根手指的La-Z-Boy时代已经正式结束了。如果程序员希望他们的程序每一代都能更快，他们必须使他们的程序更加并行。 摩尔定律的流行版本--随着每一代技术的发展而提高性能--现在由程序员决定了。 24 | 25 | **陷阱** _沦为阿姆达尔“心碎”定律的牺牲品。_ 26 | 27 | 几乎每个从业的计算机架构设计者都知道阿姆达尔定律。尽管如此，我们几乎都会在测量其使用情况之前，偶尔花费巨大的精力来优化某些功能。只有当整体的速度提升令人失望时，我们才会想起，在我们花了这么多精力来提升它之前，我们应该先测量一下它！ 28 | 29 | **陷阱** _单点故障。_ 30 | 31 | [1.7节](1.7-ke-kao-xing.md)使用阿姆达尔定律进行的可靠性改进的计算表明，可靠性不会比链条中最弱的一环更强。无论我们如何提高电源的可靠性，正如我们在例子中所做的那样，单个风扇将限制磁盘子系统的可靠性。这个阿姆达尔定律的观察导致了一个容错系统的经验法则，即确保每一个组件都是冗余的，这样就没有一个组件的故障会使整个系统崩溃。[第六章](../di-liu-zhang-da-gui-mo-shu-ju-zhong-xin-ji-ji-suan-ji-de-bing-hang-xing-qing-qiu-ji-bing-hang-rlp-he.md)展示了软件层如何避免WSCs内部的单点故障。 32 | 33 | **谬论** _改进硬件的性能也会提高能效，或者在最坏的情况下是能耗不增加也不减少。_ 34 | 35 | Esmaeilzadeh等人（2011年）使用Turbo模式（第1.5节）在2.67GHz英特尔酷睿i7的一个核心上测量了SPEC2006。当时钟频率提高到2.94GHz时，性能提高了1.07倍（或1.10倍），但i7增加了1.37倍功耗和1.47倍的能耗！。 36 | 37 | **谬误** _基准永远有效_。 38 | 39 | 有几个因素影响了基准作为实际性能预测的有用性，而且有些因素会随着时间的推移而改变。一个重要的事实是，基准有用性本身与 "基准标准化 "或 "基准流行化 "的趋势相抵触。一旦一个基准变得标准和流行，就会有巨大的压力，使得设计者通过有针对性的优化或对运行基准的规则进行大量分析来提高性能。当设计小kernel或程序将时间花在一小段代码上时，这将对基准的有用性产生消极影响。 例如，尽管有最好的意图，最初的SPEC89基准套件包括一个小kernel，称为matrix300，它由8个不同的300×300矩阵乘法组成。在这个kernel，99%的执行时间都在一行中（见SPEC，1989）。当IBM的一个编译器对这个内循环进行优化时（使用一个叫做blocking的好策略，将在[第二章](../di-er-zhang-nei-cun-ceng-ci-jie-gou-she-ji.md)和[第四章](../di-si-zhang-shi-liang-simd-he-gpu-jia-gou-zhong-de-shu-ju-ji-bing-hang-xing.md)中讨论），性能比之前版本的编译器提高了9倍！这个基准测试的这个编译器优化，当然不是整体性能的良好表征，也不是这个特定优化的价值所在。 40 | 41 | 图1.19表明，如果我们忽视历史，我们可能会被迫重复它。SPEC Cint2006已经有十年没有更新了，这给了编译器编写者大量的时间来磨练他们的优化器以适应这个套件。请注意，除了libquantum之外，所有基准的SPECRate都在AMD计算机的16-52范围内，而英特尔则在22-78之间。Libquantum在AMD上的运行速度约为250倍，在英特尔上为7300倍! 这个 "奇迹 "是英特尔编译器优化的结果，该编译器自动将代码在22个核心上并行化，并通过使用比特打包（bit packing）优化内存，将多个短整型（narrow-range integers）打包在一起，以节省内存空间，从而节省内存带宽。如果我们放弃这个基准并重新计算几何平均值，AMD SPEC Cint2006从31.9下降到26.5，英特尔从63.7下降到41.4。现在英特尔计算机的速度大约是AMD计算机的1.5倍，而不是2.0倍，如果我们包括libquantum，这肯定更接近他们的真实相对性能。SPECCPU2017放弃了libquantum。 42 | 43 | 为了说明基准的短命，图1.17列出了各个SPEC版本中所有82个基准的状态；gcc是SPEC89中唯一的幸存者。令人惊讶的是，SPEC2000或更早的所有程序中，约有70%从下一个版本中被放弃。 44 | 45 | **谬误** _磁盘的额定平均故障时间为120万小时，即近140年，所以磁盘实际上从未发生故障。_ 46 | 47 | 目前磁盘制造商的市场营销会误导用户。MTTF是如何计算的呢？首先，制造商会把成千上万的磁盘放在一个房间里，运行几个月，然后统计故障磁盘的数量。MTTF由磁盘累计工作的总时长除以故障的数量得出。 48 | 49 | 一个问题是，这个数字远远超过了磁盘的使用寿命，通常假设为五年或43800小时。为了使这个大MTTF有一定的意义，磁盘制造商争辩说，这个统计模型可以这样解释：对应于一个购买磁盘的用户，然后按照计划寿命，每5年更换一次磁盘。他们声称，如果许多客户（以及他们的曾孙）在下个世纪都这样做的话，按照平均统计，他们会在发生故障前更换27次磁盘，或者大约140年。 50 | 51 | 一个更有用的衡量标准是磁盘故障的百分比，这被称为年故障率。假设1000个磁盘的MTTF为100万小时，并且这些磁盘每天使用24小时。如果你用具有相同可靠性特征的新磁盘替换失效的磁盘，一年内（8760小时）失效的数量为： 52 | 53 | ![](../.gitbook/assets/NeatReader-1656472554738.png) 54 | 55 | 换句话说，每年有0.9%的故障，或在5年的使用寿命内有4.4%会发生故障。 此外，这个低故障率是在假设有限的温度和振动范围的情况下成立。如果超过了这些范围，那么所有的假设都会失效。一项对实际环境中的磁盘驱动器的调查（Gray和van Ingen，2005）发现，每年有3%-7%的驱动器发生故障，MTTF约为125,000-300,000小时。一项更大的研究发现，每年磁盘故障率为2%-10%（Pinheiro等人，2007）。因此，现实世界的MTTF大约比制造商的MTTF差2-10倍。 56 | 57 | **谬误** _峰值性能反映了观测性能（observed performance，译者注：这里应该指的是计算机实际运行的真实性能）_。 58 | 59 | 峰值性能的唯一普遍正确的定义是 "一台计算机绝不可能超过的性能水平"。图 1.24 显示了四个程序在四个多核处理器上的峰值性能百分比。它从5%到58%不等。由于差距如此之大，而且不同的基准会有很大的不同，所以峰值性能一般对预测观测性能没有用。 60 | 61 | ![图1.24 四个程序在四个多核处理器（最大64核）上的峰值性能百分比。 NEC Earth Simulator 和X1是矢量处理器（见第四章和附录G）。它们不仅提供了更高的峰值性能比，而且还具有最高的峰值性能和最低的时钟速率。除了Paratec程序，Power 4和Itanium 2系统提供的性能是其峰值的5%到10%（Oliker, L., Canning, A., Carter, J., Shalf, J., Ethier, S., 2004. Scientific computations on modern parallel vector systems. In: Proc. ACM/IEEE Conf. on Supercomputing, November 6–12, 2004, Pittsburgh, Penn., p. 10.）](../.gitbook/assets/NeatReader-1656472960435.png) 62 | 63 | **陷阱** _故障检测会降低可用度。_ 64 | 65 | 这个明显具有讽刺意味的陷阱是因为计算机硬件有相当多的状态，这些状态可能并不总是对正常运行至关重要。例如，如果分支预测器发生错误，并不是致命的，因为只会对性能产生影响。 66 | 67 | 在试图积极利用ILP的处理器中，并非所有的操作都是正确执行程序所需要的。Mukherjee等人（2003）发现，在SPEC2000基准测试中，只有不到30%的操作可能在关键路径上。 对程序的观测也是如此。如果一个寄存器在程序中是 "死的"，即程序再次读取它之前会先写入（译者注：写后读），那么错误就不重要了。但是，如果你在检测一个死寄存器瞬时故障时使程序崩溃，这将不必要地降低可用性。 68 | 69 | 甲骨文公司的Sun Microsystems部门在2000年的Sun E3000到Sun E10000系统中使用了包括奇偶校验但不包括纠错的L2高速缓存，掉入了这个陷阱。他们用来建立高速缓存的SRAM有间歇性故障，而奇偶校验可以检测到这些故障。如果高速缓存中的数据没有被修改，处理器就会简单地从高速缓存中重新读取数据。由于设计者没有用ECC（Error-Correcting Code，纠错码）保护缓存，操作系统别无选择，只能将脏数据报告为错误，使程序崩溃。虽然现场工程师在检查中发现90%以上的情况没有问题。 70 | 71 | 为了减少这种错误的发生频率，Sun公司修改了Solaris操作系统，通过有一个主动将脏数据写入内存的进程来 "刷洗 "缓存。因为处理器没有足够的引脚来添加ECC，所以对于脏数据的唯一硬件选择是复制外部缓存，使用没有奇偶性错误的副本来纠正错误。 陷阱在于检测故障而不提供纠正故障的机制。经历了这些，甲骨文公司的工程师们不太可能犯同样的错误，以至于再设计出一台在外部高速缓存上没有ECC的计算机。 72 | 73 | -------------------------------------------------------------------------------- /SUMMARY.md: -------------------------------------------------------------------------------- 1 | # Table of contents 2 | 3 | * [关于翻译](README.md) 4 | * [前言](qian-yan/README.md) 5 | * [我们为什么写这本书](qian-yan/wo-men-wei-shi-mo-xie-zhe-ben-shu.md) 6 | * [当前版本](qian-yan/dang-qian-ban-ben.md) 7 | * [选材与组织](qian-yan/xuan-cai-yu-zu-zhi.md) 8 | * [内容概述](qian-yan/nei-rong-gai-shu.md) 9 | * [阅读导览](qian-yan/yue-du-dao-lan.md) 10 | * [章节结构](qian-yan/zhang-jie-jie-gou.md) 11 | * [案例研究与习题](qian-yan/an-li-yan-jiu-yu-xi-ti.md) 12 | * [补充材料](qian-yan/bu-chong-cai-liao.md) 13 | * [帮助改进这本书](qian-yan/bang-zhu-gai-jin-zhe-ben-shu.md) 14 | * [结语](qian-yan/jie-yu.md) 15 | * [第一章 量化设计和分析的基础知识](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/README.md) 16 | * [摘要](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/zhai-yao.md) 17 | * [1.1 介绍](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.1-jie-shao.md) 18 | * [1.2 计算机的类别](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.2-ji-suan-ji-de-lei-bie/README.md) 19 | * [物联网/嵌入式计算机](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.2-ji-suan-ji-de-lei-bie/wu-lian-wang-qian-ru-shi-ji-suan-ji.md) 20 | * [个人移动终端](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.2-ji-suan-ji-de-lei-bie/ge-ren-yi-dong-zhong-duan.md) 21 | * [桌面计算机](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.2-ji-suan-ji-de-lei-bie/zhuo-mian-ji-suan-ji.md) 22 | * [服务器](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.2-ji-suan-ji-de-lei-bie/fu-wu-qi.md) 23 | * [集群/数据仓库规模的计算机](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.2-ji-suan-ji-de-lei-bie/ji-qun-shu-ju-cang-ku-gui-mo-de-ji-suan-ji.md) 24 | * [并行性和并行架构的类别](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.2-ji-suan-ji-de-lei-bie/bing-hang-xing-he-bing-hang-jia-gou-de-lei-bie.md) 25 | * [1.3 计算机体系结构的定义](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.3-ji-suan-ji-ti-xi-jie-gou-de-ding-yi/README.md) 26 | * [指令集架构：计算机体系结构的“狭隘”观点](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.3-ji-suan-ji-ti-xi-jie-gou-de-ding-yi/zhi-ling-ji-jia-gou-ji-suan-ji-ti-xi-jie-gou-de-xia-ai-guan-dian.md) 27 | * [名副其实的计算机体系结构：设计组织（Organization）和硬件以满足设计指标和功能需求](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.3-ji-suan-ji-ti-xi-jie-gou-de-ding-yi/ming-fu-qi-shi-de-ji-suan-ji-ti-xi-jie-gou-she-ji-zu-zhi-organization-he-ying-jian-yi-man-zu-she-ji.md) 28 | * [1.4 技术趋势](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.4-ji-shu-qu-shi/README.md) 29 | * [性能趋势：带宽的提升大于延迟](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.4-ji-shu-qu-shi/xing-neng-qu-shi-dai-kuan-de-ti-sheng-da-yu-yan-chi.md) 30 | * [晶体管性能和导线的扩大](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.4-ji-shu-qu-shi/jing-ti-guan-xing-neng-he-dao-xian-de-kuo-da.md) 31 | * [1.5 集成电路中功率和能耗的发展趋势](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.5-ji-cheng-dian-lu-zhong-gong-shuai-he-neng-hao-de-fa-zhan-qu-shi/README.md) 32 | * [电源和能耗，一个系统的视角](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.5-ji-cheng-dian-lu-zhong-gong-shuai-he-neng-hao-de-fa-zhan-qu-shi/dian-yuan-he-neng-hao-yi-ge-xi-tong-de-shi-jiao.md) 33 | * [微处理器内的能耗和功率](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.5-ji-cheng-dian-lu-zhong-gong-shuai-he-neng-hao-de-fa-zhan-qu-shi/wei-chu-li-qi-nei-de-neng-hao-he-gong-shuai.md) 34 | * [由于能耗的限制，计算机架构的转变](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.5-ji-cheng-dian-lu-zhong-gong-shuai-he-neng-hao-de-fa-zhan-qu-shi/you-yu-neng-hao-de-xian-zhi-ji-suan-ji-jia-gou-de-zhuan-bian.md) 35 | * [1.6 成本的发展趋势](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.6-cheng-ben-de-fa-zhan-qu-shi/README.md) 36 | * [时间、数量和商品化的影响](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.6-cheng-ben-de-fa-zhan-qu-shi/shi-jian-shu-liang-he-shang-pin-hua-de-ying-xiang.md) 37 | * [集成电路的成本](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.6-cheng-ben-de-fa-zhan-qu-shi/ji-cheng-dian-lu-de-cheng-ben.md) 38 | * [成本与价格](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.6-cheng-ben-de-fa-zhan-qu-shi/cheng-ben-yu-jia-ge.md) 39 | * [制造成本与运营成本](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.6-cheng-ben-de-fa-zhan-qu-shi/zhi-zao-cheng-ben-yu-yun-ying-cheng-ben.md) 40 | * [1.7 可靠性](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.7-ke-kao-xing.md) 41 | * [1.8 评测、报告和总结性能](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.8-ping-ce-bao-gao-he-zong-jie-xing-neng/README.md) 42 | * [基准评测](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.8-ping-ce-bao-gao-he-zong-jie-xing-neng/ji-zhun-ping-ce/README.md) 43 | * [桌面应用基准](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.8-ping-ce-bao-gao-he-zong-jie-xing-neng/ji-zhun-ping-ce/zhuo-mian-ying-yong-ji-zhun.md) 44 | * [服务器应用基准](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.8-ping-ce-bao-gao-he-zong-jie-xing-neng/ji-zhun-ping-ce/fu-wu-qi-ying-yong-ji-zhun.md) 45 | * [报告性能结果](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.8-ping-ce-bao-gao-he-zong-jie-xing-neng/bao-gao-xing-neng-jie-guo.md) 46 | * [总结性能结果](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.8-ping-ce-bao-gao-he-zong-jie-xing-neng/zong-jie-xing-neng-jie-guo.md) 47 | * [1.9 计算机量化设计原则](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.9-ji-suan-ji-liang-hua-she-ji-yuan-ze/README.md) 48 | * [利用并行化的优势](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.9-ji-suan-ji-liang-hua-she-ji-yuan-ze/li-yong-bing-hang-hua-de-you-shi.md) 49 | * [局部性原理](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.9-ji-suan-ji-liang-hua-she-ji-yuan-ze/ju-bu-xing-yuan-li.md) 50 | * [关注常见情况](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.9-ji-suan-ji-liang-hua-she-ji-yuan-ze/guan-zhu-chang-jian-qing-kuang.md) 51 | * [阿姆达尔定律](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.9-ji-suan-ji-liang-hua-she-ji-yuan-ze/a-mu-da-er-ding-lv.md) 52 | * [处理器性能方程](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.9-ji-suan-ji-liang-hua-she-ji-yuan-ze/chu-li-qi-xing-neng-fang-cheng.md) 53 | * [1.10 把它们放在一起：性能、价格和功耗](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.10-ba-ta-men-fang-zai-yi-qi-xing-neng-jia-ge-he-gong-hao.md) 54 | * [1.11 谬误和陷阱](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.11-miu-wu-he-xian-jing.md) 55 | * [1.12 结论](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.12-jie-lun.md) 56 | * [1.13 历史观点和引用](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/1.13-li-shi-guan-dian-he-yin-yong.md) 57 | * [案例研究和习题](di-yi-zhang-liang-hua-she-ji-he-fen-xi-de-ji-chu-zhi-shi/an-li-yan-jiu-he-xi-ti.md) 58 | * [第二章 内存层次结构设计](di-er-zhang-nei-cun-ceng-ci-jie-gou-she-ji.md) 59 | * [第三章 指令级并行及其应用](di-san-zhang-zhi-ling-ji-bing-hang-ji-qi-ying-yong.md) 60 | * [第四章 矢量、SIMD和GPU架构中的数据级并行性](di-si-zhang-shi-liang-simd-he-gpu-jia-gou-zhong-de-shu-ju-ji-bing-hang-xing.md) 61 | * [第五章 线程级并行](di-wu-zhang-xian-cheng-ji-bing-hang.md) 62 | * [第六章 大规模数据中心级计算机的并行性：请求级并行（RLP）和数据级并行](di-liu-zhang-da-gui-mo-shu-ju-zhong-xin-ji-ji-suan-ji-de-bing-hang-xing-qing-qiu-ji-bing-hang-rlp-he.md) 63 | * [第七章 领域特定架构（DSA）](di-qi-zhang-ling-yu-te-ding-jia-gou-dsa.md) 64 | * [附录A-指令集设计原则](fu-luazhi-ling-ji-she-ji-yuan-ze.md) 65 | * [附录B-内存层次结构的回顾](fu-lubnei-cun-ceng-ci-jie-gou-de-hui-gu/README.md) 66 | * [摘要](fu-lubnei-cun-ceng-ci-jie-gou-de-hui-gu/zhai-yao.md) 67 | * [B.1 介绍](fu-lubnei-cun-ceng-ci-jie-gou-de-hui-gu/b.1-jie-shao/README.md) 68 | * [缓存性能回顾](fu-lubnei-cun-ceng-ci-jie-gou-de-hui-gu/b.1-jie-shao/huan-cun-xing-neng-hui-gu.md) 69 | * [四个内存层次的问题](fu-lubnei-cun-ceng-ci-jie-gou-de-hui-gu/b.1-jie-shao/si-ge-nei-cun-ceng-ci-de-wen-ti.md) 70 | * [一个例子：Opteron的数据缓存](fu-lubnei-cun-ceng-ci-jie-gou-de-hui-gu/b.1-jie-shao/yi-ge-li-zi-opteron-de-shu-ju-huan-cun.md) 71 | * [附录C-流水线：初级和中级概念](fu-lucliu-shui-xian-chu-ji-he-zhong-ji-gai-nian.md) 72 | * [附录D-存储系统](fu-ludcun-chu-xi-tong.md) 73 | * [附录E-嵌入式系统](fu-lueqian-ru-shi-xi-tong.md) 74 | * [附录F-多机互联](fu-lufduo-ji-hu-lian.md) 75 | * [附录G-深入向量处理器](fu-lugshen-ru-xiang-liang-chu-li-qi.md) 76 | * [附录H-VLIW和EPIC的硬件和软件](fu-lu-hvliw-he-epic-de-ying-jian-he-ruan-jian.md) 77 | * [附录I-大规模多处理器和科学计算的应用](fu-luida-gui-mo-duo-chu-li-qi-he-ke-xue-ji-suan-de-ying-yong.md) 78 | * [附录J-计算机算数（Arithmetic）相关](fu-lujji-suan-ji-suan-shu-arithmetic-xiang-guan.md) 79 | * [附录K-指令集架构的回顾](fu-lukzhi-ling-ji-jia-gou-de-hui-gu.md) 80 | * [附录L-地址翻译（Address Translation）的高级概念](fu-luldi-zhi-fan-yi-address-translation-de-gao-ji-gai-nian.md) 81 | * [附录M-历史观点和参考文献](fu-lumli-shi-guan-dian-he-can-kao-wen-xian.md) 82 | --------------------------------------------------------------------------------