這本書很深，對於早已失去了專注力的我來說，想一遍就消化掉是不可能的，隻看文字不看視頻不去實踐一定會消化不良。曖昧一點吧，找不到好的詞匯形容。
走馬觀花也多少能記住些東西，先說一下第一塊難以理解又重要的地方是，其實每個地方都很難全部理解，但是對我而言，更重要的是現在大體上把說不通的點講通。
流水線是一個很難掌握的點。
首先是和洗碗筷差不多，任務是一個一個來的，即便核很多，如三個核，那要三個時鍾周期才能讓三個核都進入工作狀態。這個核，用自助餐廳的不同種食物代替吧。
之後是，每個核工作在同一個任務的不同階段，看起來是並行的，但彼此之間還有有細小的時間差異。
還是那個洗碗洗筷子模型，係統的吞吐量受到最慢階段的速度所限製，流水線是一步一步來，在一個時鍾內，即便一個階段被完成，但它總是需要等待前麵的階段或者後麵的階段完成，才可以進行跳轉。所以最慢的階段限製著流水線速度。
切分切分切分，最後限製速度的是寄存器的讀寫速度。
如果加入前後順序的反饋，那麽最後一步產生的反饋信息要給第一步，這是兩個過程之間傳遞反饋信息。需要做修改。將seq變為seq+，動態計算pc。（完全不知道自己在說什麽了）
我隻能理解為，各個階段需要配合，需要等待把每個步驟時間對齊，對不齊就容易產生用過去的信息計算當前的狀態，得到的是錯誤的答案，這錯誤有大有小，但一定是不可以的。
然後這種一有冒險就停止等待的做法可能過於緩慢，引出了用轉發來避免數據冒險。
本來我要等你寫完我再讀，可是不如你先直接送過來，這樣對於整個過程耽擱得就比較少，寫與送的過程應該是同樣速度的，那麽我覺得節約的時間是讀的時間。唔！
兩個過程之間沒法傳送數據了，這時候用暫停與轉發結合的方法。（有點不懂）
將一個數連加兩次和加一次一個數的兩倍，結果可能會不一樣，不排除兩個指針指向同一個地址的情況，比如由淺複製產生的對象的某個成員變量，加兩次原來數會變為原來的四倍，可能這樣加不了，他或許還沒有訪問權限。但加一次兩倍就變為原來的三倍。因此這兩個不可以相互代替。
對內聯函數有了更清楚的認知，將指定函數體插入並取代每一處效應該函數的地方。這不是宏定義。
函數在形參與實參結合時，最好用函數內的變量記錄一下實參的變量，相當於把別人的書抄了一遍就放在家裏用，否則，每次循環都使用的話，每次都要跑過去抄同一個字，再跑回來運行。測數組或者字符串長度測一次就記錄下來，不要把測試函數放在循環裏。減少調用的開銷。
記住for的短路啊！
但如果一些數據你可以調用，但是不能知道它的值是什麽怎麽辦呢？應該是不可能的，可以用，就可以讀，可不可寫才是安全性的重點吧。或許。
我不記得卡諾圖是如何化簡的了，但是，會不會他有化簡指令的能力？把100個指令同時塞進去，經過化簡變成幾個指令，這不就是一種優化嗎？或許。
我明顯是對邏輯的理解更深刻一些，對於硬件是如何工作的理解不多。
把重複的部分抽出來打包。我現在腦袋裏想的就是這個。
溢出處理也是一個安全部分較為重要的地方，難哦。
改變計算次序而提高運算速度或者運算精度的方法，我想了兩個，一個是秦九韶；一個是把數據排序後再做計算，可以減少大數吃掉小數後的損失。
學到的是，當對需要不斷更新的值做乘法時，可以把已知部分括起來，讓他們先行計算而不需要等待這個更新值，可以降低延遲。
用冒號問號的句式做數據交換，是一種基於條件數據傳送的手段。它有好有壞我不好掌握，但是，應該先好好習慣冒號問號的代碼書寫格式。
那種預測機製也不明白，隻能舉個應用場合的例子，當一個數不斷自加直到被上限擋住為止，這個過程預測出錯隻會出現在最開始和結尾，中間一直是否，預測起來不會出錯。
更深的地方就挖不動了，先這樣。
如何更快？硬件多數時間都在做加減乘除，再幹活，而不是把過多時間浪費在跑來跑去。
增加限製條件，然後去掉冗餘的限製條件。
放東西就是這個道理，越常用的越要放在能快速拿的地方。我們的世界不是遊戲裏抽象的倉庫，而是具有一個存儲的層次結構，有遠近難易之分。
有記憶的統計來自於局部性，它認為已有之事後必再有，已行之事後必再行。我之前覺得有道理，後來覺得也未必，有些東西摒棄掉了就是摒棄掉了，可能會在別的個體上持續發生，但在單個個體上未必。這有點算是抬杠了，總之呢，局部性可以大大提高性能。
無條件跳躍可能導致死循環啊，或者莫名其妙鬼畜起來了。雖然對於複雜的過程來說，未知錯誤是難免的，但還是盡可能把會出錯的地方修補一番，然後在關鍵的地方用try與catch。
映射表的查找方法，如果虛擬內存和物理內存之間的映射表的查詢方式是順序查找，映射表又很長，查的位置不滿足局部性來回跳，那時間就會花費很多，這麽大的宏觀的事可能不是我該考慮的，我就把他縮小吧。要是我建立一個用於存儲和查詢的表，我就會盡量讓他們的序號有一定的意義，至少可以讓我或者程序估計，要查的東西在前一半還是在後一半，哦我想起來了，這是不是設計了主鍵的排序呢？我真是笨蛋。
除了排序也可以分級，手動地告訴代碼，要找的東西在上一半還是下一半，分兩級就更加好找了。（過於幼稚）
層之間的關鍵字可以用門電路連接，這樣的話很客觀安全，但是是犧牲了物理空間換去來速度傷的性能。沒有兩全法的。隻有取舍。
借用必須要有借用恢複，有點像中斷。
需要保持狀態的塊，還是很經典的一句話，出門要有鎖存，進門要有緩衝。
去掉冗餘，相同的部分隻寫一次，這就是c++的優勢哦，不，是共享的優勢。
創建一個垃圾堆，或者垃圾堆也可以臨時使用，多想想如何把現實中的概念應用到虛擬的領域，這樣或許我們分不清夢境與現實之前，就已經分不清虛擬與現實了。
大塊與碎片的概念也很好，整可以碎，碎不可以整也。
相鄰的塊要比破碎的塊更好用，不相鄰就要花費一部分出來連接破碎的塊，可能也需要花時間挑選出合適或足夠的塊們。
&有和沒有區別很大，需要重視。
顯示地初始化為0十分重要，要注意。
動作的前麵都會加入一個隱含的形容詞，請求。
知其然容易，知其所以然難。我知前者少，知後者更少，怎麽會說話呢？不好意思啦。
雖然看不懂的多，但還是有收獲的，加油！
或許會二刷吧。或許。
走馬觀花也多少能記住些東西，先說一下第一塊難以理解又重要的地方是，其實每個地方都很難全部理解，但是對我而言，更重要的是現在大體上把說不通的點講通。
流水線是一個很難掌握的點。
首先是和洗碗筷差不多，任務是一個一個來的，即便核很多，如三個核，那要三個時鍾周期才能讓三個核都進入工作狀態。這個核，用自助餐廳的不同種食物代替吧。
之後是，每個核工作在同一個任務的不同階段，看起來是並行的，但彼此之間還有有細小的時間差異。
還是那個洗碗洗筷子模型，係統的吞吐量受到最慢階段的速度所限製，流水線是一步一步來，在一個時鍾內，即便一個階段被完成，但它總是需要等待前麵的階段或者後麵的階段完成，才可以進行跳轉。所以最慢的階段限製著流水線速度。
切分切分切分，最後限製速度的是寄存器的讀寫速度。
如果加入前後順序的反饋，那麽最後一步產生的反饋信息要給第一步，這是兩個過程之間傳遞反饋信息。需要做修改。將seq變為seq+，動態計算pc。（完全不知道自己在說什麽了）
我隻能理解為，各個階段需要配合，需要等待把每個步驟時間對齊，對不齊就容易產生用過去的信息計算當前的狀態，得到的是錯誤的答案，這錯誤有大有小，但一定是不可以的。
然後這種一有冒險就停止等待的做法可能過於緩慢，引出了用轉發來避免數據冒險。
本來我要等你寫完我再讀，可是不如你先直接送過來，這樣對於整個過程耽擱得就比較少，寫與送的過程應該是同樣速度的，那麽我覺得節約的時間是讀的時間。唔！
兩個過程之間沒法傳送數據了，這時候用暫停與轉發結合的方法。（有點不懂）
將一個數連加兩次和加一次一個數的兩倍，結果可能會不一樣，不排除兩個指針指向同一個地址的情況，比如由淺複製產生的對象的某個成員變量，加兩次原來數會變為原來的四倍，可能這樣加不了，他或許還沒有訪問權限。但加一次兩倍就變為原來的三倍。因此這兩個不可以相互代替。
對內聯函數有了更清楚的認知，將指定函數體插入並取代每一處效應該函數的地方。這不是宏定義。
函數在形參與實參結合時，最好用函數內的變量記錄一下實參的變量，相當於把別人的書抄了一遍就放在家裏用，否則，每次循環都使用的話，每次都要跑過去抄同一個字，再跑回來運行。測數組或者字符串長度測一次就記錄下來，不要把測試函數放在循環裏。減少調用的開銷。
記住for的短路啊！
但如果一些數據你可以調用，但是不能知道它的值是什麽怎麽辦呢？應該是不可能的，可以用，就可以讀，可不可寫才是安全性的重點吧。或許。
我不記得卡諾圖是如何化簡的了，但是，會不會他有化簡指令的能力？把100個指令同時塞進去，經過化簡變成幾個指令，這不就是一種優化嗎？或許。
我明顯是對邏輯的理解更深刻一些，對於硬件是如何工作的理解不多。
把重複的部分抽出來打包。我現在腦袋裏想的就是這個。
溢出處理也是一個安全部分較為重要的地方，難哦。
改變計算次序而提高運算速度或者運算精度的方法，我想了兩個，一個是秦九韶；一個是把數據排序後再做計算，可以減少大數吃掉小數後的損失。
學到的是，當對需要不斷更新的值做乘法時，可以把已知部分括起來，讓他們先行計算而不需要等待這個更新值，可以降低延遲。
用冒號問號的句式做數據交換，是一種基於條件數據傳送的手段。它有好有壞我不好掌握，但是，應該先好好習慣冒號問號的代碼書寫格式。
那種預測機製也不明白，隻能舉個應用場合的例子，當一個數不斷自加直到被上限擋住為止，這個過程預測出錯隻會出現在最開始和結尾，中間一直是否，預測起來不會出錯。
更深的地方就挖不動了，先這樣。
如何更快？硬件多數時間都在做加減乘除，再幹活，而不是把過多時間浪費在跑來跑去。
增加限製條件，然後去掉冗餘的限製條件。
放東西就是這個道理，越常用的越要放在能快速拿的地方。我們的世界不是遊戲裏抽象的倉庫，而是具有一個存儲的層次結構，有遠近難易之分。
有記憶的統計來自於局部性，它認為已有之事後必再有，已行之事後必再行。我之前覺得有道理，後來覺得也未必，有些東西摒棄掉了就是摒棄掉了，可能會在別的個體上持續發生，但在單個個體上未必。這有點算是抬杠了，總之呢，局部性可以大大提高性能。
無條件跳躍可能導致死循環啊，或者莫名其妙鬼畜起來了。雖然對於複雜的過程來說，未知錯誤是難免的，但還是盡可能把會出錯的地方修補一番，然後在關鍵的地方用try與catch。
映射表的查找方法，如果虛擬內存和物理內存之間的映射表的查詢方式是順序查找，映射表又很長，查的位置不滿足局部性來回跳，那時間就會花費很多，這麽大的宏觀的事可能不是我該考慮的，我就把他縮小吧。要是我建立一個用於存儲和查詢的表，我就會盡量讓他們的序號有一定的意義，至少可以讓我或者程序估計，要查的東西在前一半還是在後一半，哦我想起來了，這是不是設計了主鍵的排序呢？我真是笨蛋。
除了排序也可以分級，手動地告訴代碼，要找的東西在上一半還是下一半，分兩級就更加好找了。（過於幼稚）
層之間的關鍵字可以用門電路連接，這樣的話很客觀安全，但是是犧牲了物理空間換去來速度傷的性能。沒有兩全法的。隻有取舍。
借用必須要有借用恢複，有點像中斷。
需要保持狀態的塊，還是很經典的一句話，出門要有鎖存，進門要有緩衝。
去掉冗餘，相同的部分隻寫一次，這就是c++的優勢哦，不，是共享的優勢。
創建一個垃圾堆，或者垃圾堆也可以臨時使用，多想想如何把現實中的概念應用到虛擬的領域，這樣或許我們分不清夢境與現實之前，就已經分不清虛擬與現實了。
大塊與碎片的概念也很好，整可以碎，碎不可以整也。
相鄰的塊要比破碎的塊更好用，不相鄰就要花費一部分出來連接破碎的塊，可能也需要花時間挑選出合適或足夠的塊們。
&有和沒有區別很大，需要重視。
顯示地初始化為0十分重要，要注意。
動作的前麵都會加入一個隱含的形容詞，請求。
知其然容易，知其所以然難。我知前者少，知後者更少，怎麽會說話呢？不好意思啦。
雖然看不懂的多，但還是有收獲的，加油！
或許會二刷吧。或許。