最近2018中文字幕在日韩欧美国产成人片_国产日韩精品一区二区在线_在线观看成年美女黄网色视频_国产精品一区三区五区_国产精彩刺激乱对白_看黄色黄大色黄片免费_人人超碰自拍cao_国产高清av在线_亚洲精品电影av_日韩美女尤物视频网站

因為 JavaScript 動態(tài)語言的特性，我們通常直到運行時才知道值的確切類型，僅僅觀察源代碼，往往不可能知道某個操作的可能輸入值。所以這就是為什么我們需要推測，根據(jù)之前運行收集到的值的反饋，然后假設將來總會看到類似的值。這種方法聽起來可能作用相當有限，但它已被證明適用于JavaScript這樣的動態(tài)語言。

你可能會聯(lián)想到CPU的分支預測能力，如果是這樣，那么恭喜你，你并沒有想錯。

我們再回到這段代碼

function add(x, y) {
    return x + y;
}

你可能已經(jīng)想到了，作為一個動態(tài)類型的語言，推測的第一步，就是要收集到足夠多的信息，來預測 ??add?? 在今后的執(zhí)行中會遇到的類型。

所以，首先向你介紹反饋向量（Feedback Vector)，它是我們執(zhí)行預測最核心的成員之一：負責儲存我們收集到的信息。

反饋向量（Feedback Vector)

當一段代碼被初次執(zhí)行時，它所執(zhí)行的往往是解釋器產(chǎn)生的字節(jié)碼。當這段字節(jié)碼每次的執(zhí)行后，都會會產(chǎn)生一些反饋信息，這些反饋信息會被儲存在「反饋向量」（過去叫類型反饋向量） 中，這個特殊的數(shù)據(jù)結構會被鏈接在閉包上。如果從對象結構的角度來看，反饋向量和其他相關的內(nèi)容會是這樣。

其中 SharedFunctionInfo，它包含了函數(shù)的一般信息，比如源位置，字節(jié)碼，嚴格或一般模式。除此之外，還有一個指向上下文的指針，其中包含自由變量的值以及對全局對象的訪問。

關于自由變量和約束變量的概念， 閉包 (計算機科學)

反饋向量的大致結構如下，slot是一個槽，表示向量表里面的一項，包含了操作類型和傳入的值類型，

比如，第二個是一個 BinaryOp 槽，二元操作符類似“+，-”等能夠記錄迄今為止看到的輸入和輸出的反饋。先不用糾結它的含義，后面我們會具體介紹。

如果你想查看你的函數(shù)所對應的反饋向量，可以在你的代碼中加上專門的內(nèi)部函數(shù) ??%DebugPrint???  ，并且在d8中加上命令 ??–allow-natives-syntax?? 來檢查特定閉包的反饋向量的內(nèi)容。

源代碼：

function add(x, y) {
return x + y;
} 
console.log(add(1, 2));
%DebugPrint(add);

在d8 使用這個命令 –allow-natives-syntax 運行，我們看到 :

$ out/Debug/d8 --allow-natives-syntax add.js
DebugPrint: 0xb5101ea9d89: [Function] in OldSpace
- feedback vector: 0xb5101eaa091: [FeedbackVector] in OldSpace
- length: 1
SharedFunctionInfo: 0xb5101ea99c9 
Optimized Code: 0
Invocation Count: 1
Profiler Ticks: 0
Slot #0 BinaryOp BinaryOp:SignedSmall

我們看到調(diào)用次數(shù)（Invocation Count）是1，因為我們只調(diào)用了一次函數(shù)add。此時還沒有優(yōu)化代碼（根據(jù)Optimized Code的值為0）。反饋向量的長度為1，說明里面只有一個槽，就是我們上面說到的二元操作符槽（BinaryOp Slot），當前反饋為 SignedSmall。

這個反饋SignedSmall代表什么？這表明指令Add只看到了SignedSmall類型的輸入，并且直到現(xiàn)在也只產(chǎn)生了SignedSmall類型的輸出。

但是什么是SignedSmall類型？JavaScript里面并不存在這種類型。實際上，SignedSmall來自己V8中的一種優(yōu)化策略，它表示在程序中經(jīng)常使用的小的有符號整數(shù)（V8將高位的32位表示整數(shù)，低位的全部置0來表示SignedSmall），這種類型能夠獲得特殊處理（其他JavaScript引擎也有類似的優(yōu)化策略）。

「值的表示」

V8通常使用一種叫做指針標記（Pointer Tagging）的技術來表示值，應用這種技術，V8在每個值里面都設置一個標識。我們處理的大部分值都分配在JavaScript堆上，并且由垃圾回收器（GC）來管理。但是對某些值來說，總是將它們分配在內(nèi)存里開銷會很大。尤其是對于小整數(shù)，它們通常會用在數(shù)組索引和一些臨時計算結果。

在V8中存在兩種指針標識類型：分別是是Smi（即 Small Integer的縮寫）和堆對象（ HeapObject，就是JavaScript的引用類型），其中堆對象是分配在內(nèi)存的堆中，圖中的地址即指向堆中的某塊地方。

我們用最低有效位來區(qū)分堆對象（標志是1）和小整數(shù)（標志是0）。對于64位結構上的Smi，至少有32位有效位（低半部）是一直被置為0。另外32位，也就是Word的上半部，是被用來儲存32位有符號小整數(shù)的值。

僅僅是一次的執(zhí)行，還不足以讓引擎這么快下定決心，相信add 函數(shù)隨后的執(zhí)行都是Smi 類型。那么我們先來看看，如果在隨后的執(zhí)行中，我們傳入不一樣的類型會怎么樣。

反饋向量的變化

反饋類型SignedSmall是指所有能用小整數(shù)表示的值。對于add操作而言，這意味著目前為止它只能看到輸入類型為Smi，并且所產(chǎn)生的輸出值也都是Smi（也就是說，所有的值都沒有超過32位整數(shù)的范圍）。下面我們來看看，當我們調(diào)用add的時候傳入一個不是Smi的值會發(fā)生什么。

function add(x, y) {
return x + y;
}
console.log(add(1, 2));
console.log(add(1.1, 2.2));
//調(diào)用100ci
%DebugPrint(add);

在d8加入命令 –allow-natives-syntax ，然后看到下面結果。

$ out/Debug/d8 --allow-natives-syntax add.js
DebugPrint: 0xb5101ea9d89: [Function] in OldSpace
…
- feedback vector: 0x3fd6ea9ef9: [FeedbackVector] in OldSpace
- length: 1
SharedFunctionInfo: 0x3fd6ea9989 
Optimized Code: 0
Invocation Count: 2
Profiler Ticks: 0
Slot #0 BinaryOp BinaryOp:Number

首先，我們看到調(diào)用次數(shù)現(xiàn)在是2，因為運行了兩次函數(shù)add。然后發(fā)現(xiàn)BinaryOp 槽的值現(xiàn)在變成了Number，這表明對于這個加法已經(jīng)有傳入了任意類型的數(shù)值（即非整數(shù)）。此外，這有一個反饋向量的狀態(tài)遷移圖，大致如下所示：

反饋狀態(tài)從 None 開始，這表明目前還沒有看到任何輸入，所以什么都不知道。狀態(tài)Any表明我們看到了不兼容的（比如number和string）輸入和輸出的組合。狀態(tài)Any意味著Add（字節(jié)碼中的）是多態(tài)。相比之下，其余的狀態(tài)表明Add都是單態(tài)（monomorphic），因為看到的輸入和產(chǎn)生的都是相同類型的值。下面是圖中名詞解釋：

• SignedSmall 表示所有的值都是小整數(shù)（有效數(shù)值為是32位或者31位，取決于Word的在不同架構上的大?。?，均表示為Smi。
• Number 表明所有的值都常規(guī)數(shù)字 (這包括小整數(shù))。
• NumberOrOddball 包括其他能被轉(zhuǎn)換成 Number 的 undefined， null， true 和 false 。
• String ：所有輸入值都是字符串
• BigInt 表示輸入都是大整數(shù)。

需要注意一點，反饋只能在這個圖中前進（從 None 到 Any），不能回退。如果真的那樣做，那么我們就會有陷入去優(yōu)化循環(huán)的風險。那樣情況下，優(yōu)化編譯器發(fā)現(xiàn)輸入值與之前得到反饋內(nèi)容不同，比如之前解釋器生成的反饋是 Number，但現(xiàn)在輸入值出現(xiàn)了 String，這時候已經(jīng)生成的反饋和優(yōu)化代碼就會失效，并回退到解釋器生成的字節(jié)碼版本。當下一次函數(shù)再次變熱（hot，多次運行），我們將再次優(yōu)化它，如果允許回退，這時候優(yōu)化編譯器會再次生成相同的代碼，這意味著會再次回到 Number 的情況。如果這樣無限制的回退去優(yōu)化，再優(yōu)化，編譯器將會忙于優(yōu)化和去優(yōu)化，而不是高速運行 JavaScript 代碼。

優(yōu)化管道（The Optimization Pipeline）

現(xiàn)在我們知道了解釋器Ignition 是如何為函數(shù)add收集反饋，下面來看看優(yōu)化編譯器如何利用反饋生成最小的代碼，因為_越小的機器指令代碼塊，意味著更快的速度_。為了觀察，我將使用一個特殊的內(nèi)部函數(shù)OptimizeFunctionOnNextCall（）在特定的時間點觸發(fā)V8對函數(shù)的優(yōu)化。我們經(jīng)常使用這些內(nèi)部函數(shù)以非常特定的方式對引擎進行測試。

function add(x, y) {
return x + y;
} 
add(1, 2); // Warm up with SignedSmall feedback.
%OptimizeFunctionOnNextCall(add);
add(1, 2); // Optimize and run generated code

在這里，給函數(shù)add傳遞兩個整數(shù)型值來明確call site “x + y”的反饋會被預熱為小整數(shù)（表示_這個call site全部傳遞的都是小整數(shù)，對于優(yōu)化引擎來說將來得到的輸入也會是小整數(shù)_），并且結果也是屬于小整數(shù)范圍。然后我們告訴V8應該在下次調(diào)用函數(shù)add的時候去優(yōu)化它（用TurboFan )，最終再次調(diào)用add，觸發(fā)優(yōu)化編譯器運行生成機器碼。

TurboFan 拿到之前為函數(shù)add生成的字節(jié)碼，并從函數(shù)add的反饋向量表里提取出相關的反饋。優(yōu)化編譯器將這些信息轉(zhuǎn)換成一個圖表示，再將這個圖表示傳遞給前端，優(yōu)化以及后端的各個階段（見上圖）。在本文不會詳細展開這部分內(nèi)容，這是另一個系列的內(nèi)容了。我們要了解的是最終生成的機器碼，并看看優(yōu)化推測是如何工作的。你可以在d8中加上命令 –print-opt-code來查看由TurboFan 生成的優(yōu)化代碼。

這是由TurboFan 在x64架構上生成的機器碼，這里省略了一些無關緊要的技術細節(jié)（，下面就來看看這些代碼做了什么。

# Prologue
leaq rcx,[rip+0x0]
movq rcx,[rcx-0x37]
testb [rcx+0xf],0x1
jnz CompileLazyDeoptimizedCode
push rbp
movq rbp,rsp
push rsi
push rdi
cmpq rsp,[r13+0xdb0]
jna StackCheck

第一段代碼檢查對象是否仍然有效（對象的形狀是否符合之前生成機器碼的那個），或者某些條件是否發(fā)生了改變，這就需要丟棄這個優(yōu)化代碼。這部分具體內(nèi)容可以參考 Juliana Franco 的 “Internship on Laziness“。一旦我們知道這段代碼仍然有效，就會建立一個棧幀并且檢查堆棧上是否有足夠的空間來執(zhí)行代碼。

# Check x is a small integer
movq rax,[rbp+0x18]
test al,0x1
jnz Deoptimize
# Check y is a small integer
movq rbx,[rbp+0x10]
testb rbx,0x1
jnz Deoptimize
# Convert y from Smi to Word32
movq rdx,rbx
shrq rdx, 32
# Convert x from Smi to Word32
movq rcx,rax
shrq rcx, 32

然后從函數(shù)主體開始。我們從棧中讀取參數(shù)x和y的值（相對于幀指針rbp，比如rbp+1這樣的地址，請參考棧幀概念），然后檢查兩個參數(shù)是否都是 Smi 類型（因為根據(jù)“+”得到的反饋，兩個輸入總是Smi）。這一步是通過測試最低有效位來完成。一旦確定了參數(shù)都是Smi，我們需要將它轉(zhuǎn)換成32位表示，這是通過將值右移32位來完成的。如果x或y不是Smi，則會立即終止執(zhí)行優(yōu)化代碼，接著負責去優(yōu)化的模塊就會恢復到之前解釋器生成的函數(shù)add的代碼（即字節(jié)碼）。

# Add x and y (incl. overflow check)
addl rdx,rcx
jo Deoptimize
# Convert result to Smi
shlq rdx, 32
movq rax,rdx
# Epilogue
movq rsp,rbp
pop rbp
ret 0x18

然后我們繼續(xù)執(zhí)行對輸入值的整數(shù)加法，這時需要明確地測試溢出，因為加法的結果可能超出32位整數(shù)的范圍，在這種情況下就要返回到解釋器版本，并在隨后將add的反饋類型提升為Number（之前說過，反饋類型的改變只能前進）。

最后我們通過將帶符號的32位值向上移動32位，將結果轉(zhuǎn)換回Smi表示，并將結果返回存到累加器rax 。

我們現(xiàn)在可以看到生成的代碼是高度優(yōu)化的，并且適用于專門的反饋。它完全不去處理其他數(shù)字，字符串，大整數(shù)或任意JavaScript對象，只關注目前為止我們所看到的那種類型的值。這是使許多JavaScript應用程序達到最佳性能的關鍵因素。

為什么需要TypeScript?

在上面的介紹中，我們竭力避免了對JavaScript 對象的訪問，如果有對象加入，這將會變成一個很復雜的話題。但為了更好的展開這個話題，我們還是需要提一下，關于對象的優(yōu)化是V8中極其重要的一部分。例如，以下面這個對象為例

var o = {
    x: ''
}
var o1 = {
    x: ''
    y
}
//o1. o2

對于像 o.x這樣的屬性訪問，若o始終具有相同的形狀（形狀同結構，即相同的屬性以及屬性是相同的順序，例如o的結構一直是{x:v}，其中v的類型是String），我們會把如何獲得o.x的過程信息緩存起來，構造成一個隱藏類（ Hidden Class）。在隨后執(zhí)行相同的字節(jié)碼時，不需要再次搜索對象o中x的位置。這種底層實現(xiàn)被稱為內(nèi)聯(lián)緩存– inline cache (IC)。

你可以在Vyacheslav Egoro寫的這篇文章 “What’s up with monomorphism?” 中了解更多關于ICs和屬性訪問的細節(jié)。

總而言之，你現(xiàn)在應該了解到，作為一門弱類型的語言，從最早的SELF和smalltalk 語言開始，研究者就在不斷去優(yōu)化這種弱類型語言的執(zhí)行效率。

「從執(zhí)行的角度來說，動態(tài)類型性能瓶頸很大程度是因為它的動態(tài)的類型系統(tǒng)，與靜態(tài)類型的語言相比， JavaScript 程序需要額外的操作來處理類型的動態(tài)性，所以執(zhí)行效率比較低?！?/p>

說了這么多，最關鍵的一點

「確定你的代碼將要看到的類型很重要」

再加上另外一句話：

「作為動態(tài)語言，你的程序可能在90%的時間里，都在處理和代碼邏輯無關的事情。即：確認你的代碼是什么形狀」

從傳統(tǒng)的JavaScript 角度來說。

function add(x, y) {
    return x + y;
}

你無法很好的保證 add 函數(shù)將要看到的類型，哪怕你確實想要這么做。但在一個大型的系統(tǒng)中，維護每一個函數(shù)和對象的形狀，極其困難。

你可能在前99次都保證了add 看到的都是Smi 類型，但是在第100次，add 看到了一個String，而在這之前，優(yōu)化編輯器，即TurboFan，已經(jīng)大膽的推測了你的函數(shù)只會看到Smi，那么這時候

Ops！

優(yōu)化編輯器將不得不認為自己做了個錯誤的預測，它會立即把之前的優(yōu)化丟掉。從字節(jié)碼開始重新執(zhí)行。

而如果你的代碼一直陷入優(yōu)化<->去優(yōu)化的怪圈，那么程序執(zhí)行將會變慢，慢到還不如不優(yōu)化。

大多數(shù)的瀏覽器都做了限制，當優(yōu)化/去優(yōu)化循環(huán)發(fā)生的時候會嘗試跳出這種循環(huán)。比如，如果 JIT 做了 10 次以上的優(yōu)化并且又丟棄的操作，那么就不繼續(xù)嘗試去優(yōu)化這段代碼。

所以，到這里你應該明白了，有兩點準則：

1. 「確保你的代碼是什么形狀很重要」

但比第一條更重要的是：

1. 「確保你的代碼固定在某個形狀上」

而編寫TypeScript ，從工程和語言的層面上幫助你解決了這兩個準則，你可以暢快的使用TypeScript，而無需擔心你是否不小心違背了上面兩條準則。