您好,登錄后才能下訂單哦!
這篇文章主要介紹“Javascript編譯目標Asm.js的介紹”,在日常操作中,相信很多人在Javascript編譯目標Asm.js的介紹問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”Javascript編譯目標Asm.js的介紹”的疑惑有所幫助!接下來,請跟著小編一起來學習吧!
正如許多開發者一樣,我也為Asm.js的前景而感到興奮不已。最近的新聞——Asm.js正 在被Firefox支持——引起了我的興趣。同樣感興趣的還有Mozilla和Epic聲明(mirror)他們已經為Asm.js而支持Unreal Engine 3——并且運行十分良好。
獲得一個C++游戲引擎運行Javascript,并使用WebGL來渲染,這是一個重大的突破,這個突破很大程度上歸功于Mozilla開發的工具鏈,才使得這一切變得可能。
由于Unreal Engine 3開始支持Asm.js,我瀏覽了來自Twitter,blogs和其他地方的回應,當一部分開發者表現出對這項制造奇跡的技術躍躍欲試時,我也看到許多 疑惑:Asm.js是一個插件嗎?Asm.js能讓我平時使用的Javascript運行的更快嗎?它兼容所有瀏覽器嗎?從這些回應中,我認為 Asm.js及其相關技術很重要,我將解釋這些技術,好讓開發者明白發生了什么以及他們將會如何從這些技術中獲益。另外,為了寫出這篇我對這項技術的概 覽,我也請教了David Herman(Mozilla研究院的高級研究員)一大堆關于Asm.js和如何梳理這些知識的問題。
什么是 Asm.js?
為了理解 Asm.js 及其適用與瀏覽器的所在,你需要知道它的由來以及它存在的意義。
Asm.js 來自于 JavaScript 應用的一個新領域: 編譯成JavaScript的C/C++應用. 它是 JavaScript 應用的一個全新流派,由 Mozilla 的 Emscripten項目催生而來。
Emscripten 將 C/C++ 代碼傳入 LLVM, 并將 LLVM生成的字節碼轉換成 JavaScript (具體的, Asm.js, 是 JavaScript 的一個子集).
如果被編譯成的 Asm.js 的代碼做了一些渲染工作,那么它幾乎總是由WebGL來處理的 (并且由 OpenGL 來渲染). 這樣技術上就利用了JavaScript 和瀏覽器的好處,但幾乎完全避開了頁面中Javascript使用的實際的、常規的代碼執行和渲染路徑.
Asm.js是Javascript的一個子集,它深度的限制了其所能做的范圍和所能操作的對象。這樣做才能使得Asm.js的代碼能夠盡可能運行的快, 從而盡可能減少各種假定情況的出現,從而能夠把Asmjs代碼直接轉變成為匯編代碼。有一個特別值得注意的是 - Asmjs還只是Javascript - 不需要瀏覽器的插件或者是別的特性去運行它(雖然一個能夠檢測出并且優化Asmjs代碼的瀏覽器當然是要快一些)。它是Javascript的一個特定的 子集,為性能優化而生,特別是為那些需要編譯成為Javascript的應用程序來做優化。
***的理解Asmjs工作的方式,就是看看一些Asmjs-編譯化的代碼。讓我們看看這個函數,這是從真實的Asmjs編譯模塊里面提取出來的函數(來自BananaBread demo)。我對代碼格式做了調整,所以看起來更加合乎代碼片段的閱讀,原本它是一個高度壓縮的JavaScript代碼中的一個很大的計算機二進制對象。
function Vb(d) { d = d | 0; var e = 0, f = 0, h = 0, j = 0, k = 0, l = 0, m = 0, n = 0, o = 0, p = 0, q = 0, r = 0, s = 0; e = i; i = i + 12 | 0; f = e | 0; h = d + 12 | 0; j = c[h >> 2] | 0; if ((j | 0) > 0) { c[h >> 2] = 0; k = 0 } else { k = j } j = d + 24 | 0; if ((c[j >> 2] | 0) > 0) { c[j >> 2] = 0 } l = d + 28 | 0; c[l >> 2] = 0; c[l + 4 >> 2] = 0; l = (c[1384465] | 0) + 3 | 0; do { if (l >>> 0 < 26) { if ((4980736 >>> (l >>> 0) & 1 | 0) == 0) { break } if ((c[1356579] | 0) > 0) { m = d + 4 | 0; n = 0; while (1) { o = c[(c[1356577] | 0) + (n << 2) >> 2] | 0; do { if (a[o + 22 | 0] << 24 >> 24 == 24) { if (!(Vp(d, o | 0) | 0)) { break } p = (c[m >> 2] | 0) + (((c[h >> 2] | 0) - 1 | 0) * 40 & -1) + 12 | 0; q = o + 28 | 0; c[p >> 2] = c[q >> 2] | 0; c[p + 4 >> 2] = c[q + 4 >> 2] | 0; c[p + 8 >> 2] = c[q + 8 >> 2] | 0; c[p + 12 >> 2] = c[q + 12 >> 2] | 0; c[p + 16 >> 2] = c[q + 16 >> 2] | 0; c[p + 20 >> 2] = c[q + 20 >> 2] | 0; c[p + 24 >> 2] = c[q + 24 >> 2] | 0 } } while (0); o = n + 1 | 0; if ((o | 0) < (c[1356579] | 0)) { n = o } else { break } } r = c[h >> 2] | 0 } else { r = k } if ((r | 0) == 0) { i = e; return } n = c[j >> 2] | 0; if ((n | 0) >= 1) { i = e; return } m = f | 0; o = f + 4 | 0; q = f + 8 | 0; p = n; while (1) { g[m >> 2] = 0.0; g[o >> 2] = 0.0; g[q >> 2] = 0.0; Vq(d, p, f, 0, -1e3); n = c[j >> 2] | 0; if ((n | 0) < 1) { p = n } else { break } } i = e; return } } while (0); if ((c[1356579] | 0) <= 0) { i = e; return } f = d + 16 | 0; r = 0; while (1) { k = c[(c[1356577] | 0) + (r << 2) >> 2] | 0; do { if (a[k + 22 | 0] << 24 >> 24 == 30) { h = b[k + 14 >> 1] | 0; if ((h - 1 & 65535) > 1) { break } l = c[j >> 2] | 0; p = (c[1384465] | 0) + 3 | 0; if (p >>> 0 < 26) { s = (2293760 >>> (p >>> 0) & 1 | 0) != 0 ? 0 : -1e3 } else { s = -1e3 } if (!(Vq(d, l, k | 0, h << 16 >> 16, s) | 0)) { break } g[(c[f >> 2] | 0) + (l * 112 & -1) + 56 >> 2] = +(b[k + 12 >> 1] << 16 >> 16 | 0); h = (c[f >> 2] | 0) + (l * 112 & -1) + 60 | 0; l = k + 28 | 0; c[h >> 2] = c[l >> 2] | 0; c[h + 4 >> 2] = c[l + 4 >> 2] | 0; c[h + 8 >> 2] = c[l + 8 >> 2] | 0; c[h + 12 >> 2] = c[l + 12 >> 2] | 0; c[h + 16 >> 2] = c[l + 16 >> 2] | 0; c[h + 20 >> 2] = c[l + 20 >> 2] | 0; c[h + 24 >> 2] = c[l + 24 >> 2] | 0 } } while (0); k = r + 1 | 0; if ((k | 0) < (c[1356579] | 0)) { r = k } else { break } } i = e; return }
從技術上說,這是Javascript代碼,但是我們已經看到這段代碼一點都不像大多我們正常看到的操作DOM的Javascript。通過看這段代碼,我們可以發現幾件事:
這段特定的代碼只能處理數值。事實上這是所有Asm.js代碼的情形。Asm.js只能處理被挑出的幾種不同的數值類型,而沒有提供其他的數據類型(包括字符串,布爾型和對象)。
所有外部數據在一個稱為堆的對象中存儲并被引用。堆在本質上是一個大數組(應當是一個在性能上高度優化的類型化數組)。所有的數據在這個數組中存儲——有效的替代了全局變量,結構體,閉包和其他形式的數據存儲。
當訪問和賦值變量時,結果被統一的強制轉換成一種特定類型。例如f = e | 0;給變量f賦值e,但它也確保了結果的類型是一個整數(|0把值轉換成整數,確保了這點)。這也發生在浮點型上——注意0.0和g[...] = +(...)的使用.
看看從數據結構中寫入讀出的值,用c表示的數據結構好像是一個Int32Array(存儲32位整數,因為這些值總是通過|0被轉換成或者轉換自一個整數),g好像是一個Float32Array(存儲32位浮點數,因為這些值總是通過包裹上+(...)轉換成浮點數)。
這么做以后,結果就是高度優化,并且可以直接從Asm.js語法轉換成匯編,而不必像常常要對Javascript做的那樣解釋它。它有效地削減了使像Javascript之類的的動態語言緩慢的東西:例如需要垃圾收集器和動態類型。
作為一個更容易理解的Asm.js代碼示例,我們來看看一個Asm.js規范上的例子:
function DiagModule(stdlib, foreign, heap) { "use asm"; // Variable Declarations var sqrt = stdlib.Math.sqrt; // Function Declarations function square(x) { x = +x; return +(x*x); } function diag(x, y) { x = +x; y = +y; return +sqrt(square(x) + square(y)); } return { diag: diag }; }
看看這個模塊,它完全能讓人理解!閱讀這些代碼,我們能更好的理解Asm.js模塊的結構。一個模塊包含在一個函數中,它以頂部的"use asm";指令開始。它提示解釋器這個函數里所有的東西可以被當成Asm.js處理,并可以直接被編譯成匯編代碼。
注意在函數頂部的三個參數:stdlib,foreigh和heap。stdlib對象包含了很多內建數學函數的引用。foreign提供了自定義用戶功能(例如在WebGL中繪制圖形)的訪問。***,heap給了你一個ArrayBuffer,它可以通過很多透鏡(例如Int32Array和Float32Array)來觀察。
該模塊剩下的被分成了三部分:變量聲明,函數聲明,還有***把函數導出暴露給用戶的一個對象。
導出是尤其要去理解的一個重點,因為它既讓所有模塊中的代碼被當成Asm.js處理,又使得代碼可以被其他普通的Javascript代碼使用。因此,在理論上你可以通過使用上面的DiagModule代碼,寫下如下代碼:
document.body.onclick = function() { function DiagModule(stdlib){"use asm"; ... return { ... };} var diag = DiagModule({ Math: Math }).diag; alert(diag(10, 100)); };
這帶來了一個Asm.js模塊DiagModule,它被Javascript解釋器特殊處理,但仍然能夠被其他Javascript代碼使用(我們仍能訪問并使用它,比如一個單擊事件處理程序)。
性能如何?
現在Asm.js唯一的實現就是nightly versions of Firefox(而且也只是針對特定的幾個平臺)。原來的數字告訴我們Ams.js的性能是非常非常不錯的。對于復雜的應用(比如上面的游戲)性能僅僅比普通C++編譯的慢兩倍(可以和Java或者C#相媲美)。實際上,這已經比目前瀏覽器的運行時環境要快很多了,幾乎是***版的Firefox或者Chrome執行速度的4~10倍。
基于目前***測試,可以看出Asm.js在性能上有很大的提升。考慮到現在僅僅是Asm.js的最初開發階段,相信在不久的將來就會有更大的性能提升。
看到Asm.js和當前的Firefox和Chrome引擎的性能差距是很有意思的。一個4~10倍的性能差異是非常巨大的(就好像拿這些瀏覽器和IE6 做性能對比一樣)。有趣的是雖然有這么大的性能差異,但是許多的Asm.js演示例子仍然是可以在Chrome和Firefox——這些代表著當前 Javascript先進技術的引擎——上使用的。這也就是說他們的性能明顯不如一個運行著優化過的Asm.js代碼的瀏覽器相提并論。
使用情況
需要說明的是現在幾乎所有基于Asm.js的應用都是C/C++應用使用Emscripten編譯的。可以肯定的說,在不久的將來,這類即將運行在 Asm.js的應用,將會從可以在瀏覽器中運行這一可移植性中獲益,但是在支持javascript方面有一定復雜度的應用將不可行。
到目前為止,大部分的使用情況下,代碼性能是至關重要的:比如運行游戲,圖像,處理語言翻譯和庫。從一個關于Emscripten項目列表的概覽可以看到許多即將被廣大開發者使用的技術。
許多游戲引擎已經被支持。一個好的演示也許就是BananaBread FPS游戲(源代碼),它可以直接在瀏覽器中運行,支持多玩家和機器人。
支持javascript的LaTeX,即textlive.js,使用Emscripten,允許你完全在你的瀏覽器中編輯PDF文檔。
支持javascript的SQLite,能夠在Node.js中運行。
NaCL:一個網絡加密解密的庫。
Asm.js支持
就像之前提到的那樣,現在只有nightly版本的Firefox支持Asm.js的優化。
但是,要注意Asm.js格式的Javascript代碼仍然是Javascript,雖然其存在一些限制。這樣,其他的瀏覽器即使不支持Asm.js仍可以將其作為普通的Javascript代碼運行。
有關代碼性能重要而令人不解的一點是:如果瀏覽器不支持typed array或者不能對Asm.js代碼進行特殊的編譯,Asm.js的性能會變的很差。當然,這并不止針對Asm.js,如果沒有這些特性,瀏覽器的性能在其他方面也會收到影響。
Asm.js與Web開發
你可能已經看出來了,上面的Asm.js代碼不是手工輸入的的。Asm.js需要一些特殊的工具來編寫,而且其開發和編寫普通的 Javascript代碼有很大區別。目前一般的Asm.js應用都是從C/C++編譯到Javascript的,很顯然它們都不會與DOM進行任何交 互,而是直接與WebGL打交道。
為了能讓一般的開發者使用,需要一些更能讓人接受的中間語言。目前LLJS已經逐漸實現向Asm.js編譯了。需要注意的是,LLJS這樣的語言同樣與常規的Javascript有很大區別,會讓許多Javascript開發者感到困擾。即使是用LLJS這樣更加友好的語言,編寫Asm.js必須要對復雜的代碼進行優化,這恐怕只有資深開發者能夠勝任了。
就算有了LLJS或者別的語言來幫助我們編寫Asm.js,我們也沒有同樣性能優異的DOM可以使用。理想的環境應該是將LLJS與DOM一起編譯產生單一的可執行二進制文件。我還想不出這樣做性能會有多好,但是我想這么做!
與David Herman的問答
我寫信給David Herman(Mozilla Research的高級研究員),向他詢問了一些問題。他們是如何將Asm.js的各部分結合在一起的?他們又希望用戶從中得到什么呢?他親切地深入回答了這些問題,有些回復很有趣。我希望你們也同樣能從中獲得啟發。
Asm.js的目標是什么?你們這個計劃的目標人群是哪些?
我們的目標是讓開放網絡成為一個虛擬主機,使之變為其他語言和平臺的編譯目標平臺。在最初的版本中,我們集中于編譯較底層的語言:C和C++。我們的長期目標是為更高層的語言提供支持,例如結構對象和垃圾回收等特性。我們最終會讓其支持諸如JVM和.NET之類的應用。 既然asm.js的確擴展了web的基礎,潛在的用戶群很廣。其中一批用戶就是那些想得到盡可能多的運算能力的游戲開發者。除此之外,有開創性的 web開發者總會用一切工具來完成目標,誰能料到他們的辦法呢?所以我真心希望asm.js成為讓我想不到的創新應用得以實現的技術。 |
創建一個利于用戶訪問版本的Asm.js是否合理呢,比如一個更新版本的LLJS?或者是擴展目前項目的范圍,而不僅僅是一個編譯器的目標語言?
絕對可能。事實上,我的同事James Long最近聲明,他已經從LLJS上開辟了一個初級的分支,用來編譯成為asm.js。在Mozilla 研究所的團隊也試圖和James的工作相配合,從而能夠正式的讓LLJS支持asm.js。 我的看法是,一般來說你想手工書寫asm.js代碼的場景非常的少,和任何匯編語言一樣。更多的是,你想用具有豐富表達力的語言,而最終把它們高效編譯為 asm.js。當然,當一種語言達到***的表達力,例如javascript,你就會難以預測其性能。(我的朋友 Slava Egorov寫一篇相當好的文章來描述用高級語言寫高性能代碼的挑戰。LLJS的目標是作為一種中間地帶,就像一種相對于asm.js匯編語言的C語言, 這樣就比寫原始的asm.js語言更加容易,而比常規的js有更可預知的性能。但是不象C,它仍然和常規的JS有著良好的互通。這樣,你可以用JS來寫你 的app的大部分,而對于那些高度消耗性能的地方,則可以專注用LLJS來完成。 |
有一個討論是關于,在目前支持Asm.js的瀏覽器和不支持的瀏覽器之間,會出現一種因此更新而形成的性能的分界,類似與 2008/2009年中所發生的JavaScript性能競爭。雖然技術上來看,Asm.js的代碼在現實中,可以運行于任意兩者之上,而性能的不同,對 于大多數的場合而言將會有有明顯的不同(譯者注:原詞是too crippling,意思大致是嚴重的傷害)。那么對于這種分界,以及高度限制Javascript,為什么你選擇了Javascript作為編譯的目標?為什么不是另一種取代javascript的語言或者是一種插件?(譯者注:作者似乎是想說明,Javascript的限制對于所有瀏覽器都會有影響,那么對于不支持Asm.js的瀏覽器會有所傷害,所以為什么不選擇別的語言或者是插件,這樣就會只影響自己的產品)
首先,我不認為這種分界如你所定義的那么嚴重:我們做過一些出色的演示代碼的編譯工作,這些代碼在目前的瀏覽器上工作的很好,而且可以得益于asm.js這樣的性能“殺手”。 這 一點是當然的事實,你可以創建一個應用程序,依賴于asm.js所曾益的性能,而且是可用的。與此同時,就如同任何新的web平臺的能力,應用程序可以決 定是否降低一些性能,減輕那些與計算密切相關的行為。對于一個應用在降低性能的時候工作,和一個應用完全不能工作是有些不同的。 更廣泛的來看,記得在00年之后開始的瀏覽器性能的競爭對于今天的web有著顯著的好處,并且應用伴隨著瀏覽器得到了改善。我相信同樣的事情會而且將發生在asmjs上。 |
拿Asm.js和Google的Native Client做比較,你覺得如何?他們似乎都有這類似的目標,同時Asmjs有著可以運行在任何支持javascript的地方的優勢。有過對于兩者之間的任何性能比較么?
嗯,Native Client有點不同,由於它其中配備了平臺相關的匯編代碼;我不認為Google會作為一種web內容技術而支持它(相對於是它用於Chrome Web Store 內容或者 Chrome 擴展而言),或者說,最近沒有。 便攜的Native Client (PNaCI)有著類似的目標,使用平臺無關的LLVM的bitcode來代替原始的匯編代碼。如你所說,asmjs的***個優勢就是其和現有的瀏覽器兼 容。我們也不必去創建一個系統的接口和重復全部的Web API中所有的接口層,好像Pepper API那樣,由於asmjs訪問目前存在的API是通過直接使用Javascript的。最終,這將對於實現更加輕松有利:Luke Wagner在一個多月中,就把我們***次實現的OdinMoney的實現版本移植到了Firefox,主要是靠他一個人的工作。因為asmjs沒有一大堆的系統調用和API,而且因為它是在Javascript語法的基礎上建立起來的,你可以重復使用現存的Javascript的引擎和web運行環境提供的全部機制。 我們本可以做一些和PNaCI的性能比較,不過這會有一定的工作量,而且我們更多的是專註於縮小和原始的native代碼性能的距離。我們計劃建立一些自動化的性能測試,這樣就可以用圖表來描述相對於native C/C++編譯器,我們目前的進展。 |
Emscripten是另一個Mozilla項目,也是Asm.js的主要兼容代碼的貢獻者。有多少Asm.js的開發被Emscripten的項目需求所支配?Emscripten又從引擎的提升上獲得了什么益處?
我們使用Emscripten作為Asm.js的***個測試用例,通過這種途徑來保證它能夠正確適應實際本地應用的需求。當然Emscripten受益也 使他們想要支持的所有擁有本地應用的人受益,比如Epic Games,我們僅在幾天之內就與之組建了開發團隊,通過使用Emscripten和Asm.js來支持web版的Unreal Engine 3的開發 |
但是Asm.js能夠使那些專注于底層javascript子集的任何人獲益。舉個例子,我們提到過的開發與Emscripten有相似功能的 Mandreel編譯器的folks,我們相信他們可以從Asm.js中受益,就像不久前啟動的Emscripten項目一樣。 |
Alon Zakai正在編譯我們的基準測試程序,這個程序只比本地代碼要慢大約2倍,以前我們看到的數字是5倍到10倍或者20倍。這只是我們最初的 OdinMonkey版本,這個版本的asm.js支持Mozilla的SpiderMonkey javascript引擎。在接下來的幾個月中,我希望看到更多的提升。 |
Asm.js的功能還會變動么?隨著越來越多編譯器開發者的加入,你贊不贊同加入更多的附加功能(比如更高級的數據結構)?
當然。Luke Wagner在Mozilla wiki上寫了asm.js與 OdinMonkey路線圖,里面討論了我們未來的計劃——我必須指出這里面沒有什么已經確定了的但的確說出了我們正在努力的方向。我很愿意加入對ES6結構對象的支持。這將會提供垃圾回收機制與良好的類結構,幫助像JSIL這類編譯器將C#和Java編譯為Javascript。我們也希望加入ES7數值類型,這將提供32位浮點數和64位整數支持,也許還會為提供SIMD支持加入定長向量 |
可以做出JavaScript-to-Asm.js轉譯器么,它會被做出來么?
可以做出來,但會做么?不一定。想想盜夢空間中你每次進行夢中夢的情景,時間將會變得多慢?一樣的道理,你要是想在JS中運行一個JS引擎那一定會非常慢的。我們不嚴格地算一算,如果asm.js比原生代碼慢一倍,那在asm.js中運行一個JS引擎,這引擎將會比它正常的速度慢一倍。 當然,你總是可以在一個JS引擎中運行另一JS引擎,誰知道到底會怎樣呢?現實中的性能從來就不像理論計算那樣明確。我歡迎一些積極的hacker去嘗試它。事實上,斯坦福的學生Alex Tatiyants已經用Emscripten將Mozilla的SpiderMonkey引擎編譯為JS了——你所需做的只是設置Emscripten編譯器參數讓它產生asm.js代碼,時間比我充裕的家伙可以嘗試一下…… |
現在Asm.js還不能進行與有關DOM和瀏覽器的操作。創建一個Emscripten到Ams.js版本的DOM(就像DOM.js)如何?
|
編寫Asm.js代碼與編寫一般的Javascript代碼相比確實十分困難,你有什么工具可以提供給開發者和編譯器作者呢?
|
我覺得你們很樂于和其他瀏覽器廠商一起工作,你們的合作和討論進展如何?
沒錯。我們之間有過一些非正式的討論,他們一直對我們給予鼓勵,我相信我們能做的更好。我很樂觀,我們可以與很多廠商一起發展asm.js,那時 它可以讓我們輕松地在不改變架構的情況下開發應用。就像我說的,事實上Luke只用了幾個月就開發出了OdinMonkey,這很令人激動。我很高興收到V8引擎下asm.js的bug報告。 更重要的是,我希望開發者可以檢查asm.js的源碼,看看我們是怎么想的,并反饋給我們和其他瀏覽器廠商。 |
到此,關于“Javascript編譯目標Asm.js的介紹”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。