Asm.js: Javascript的編譯目標

時間  2019-11-30
標籤 asm.js asm javascript 編譯 目標 欄目 JavaScript 简体版
原文   原文鏈接

正如許多開發者同樣，我也爲Asm.js的前景而感到興奮不已。最近的新聞——Asm.js正 在被Firefox支持——引發了個人興趣。一樣感興趣的還有Mozilla和Epic聲明（mirror）他們已經爲Asm.js而支持Unreal Engine 3——而且運行十分良好。javascript

得到一個C++遊戲引擎運行Javascript，並使用WebGL來渲染，這是一個重大的突破，這個突破很大程度上歸功於Mozilla開發的工具鏈，才使得這一切變得可能。java

因爲Unreal Engine 3開始支持Asm.js，我瀏覽了來自Twitter，blogs和其餘地方的迴應，當一部分開發者表現出對這項製造奇蹟的技術躍躍欲試時，我也看到許多 疑惑：Asm.js是一個插件嗎？Asm.js能讓我平時使用的Javascript運行的更快嗎？它兼容全部瀏覽器嗎？從這些迴應中，我認爲 Asm.js及其相關技術很重要，我將解釋這些技術，好讓開發者明白髮生了什麼以及他們將會如何從這些技術中獲益。另外，爲了寫出這篇我對這項技術的概 覽，我也請教了David Herman（Mozilla研究院的高級研究員）一大堆關於Asm.js和如何梳理這些知識的問題。web

什麼是 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代碼中的一個很大的計算機二進制對象。網絡

  1. function Vb(d) { 
  2.     d = d | 0; 
  3.     var e = 0, f = 0, h = 0, j = 0, k = 0, l = 0, m = 0, n = 0, 
  4.     o = 0, p = 0, q = 0, r = 0, s = 0; 
  5.     e = i; 
  6.     i = i + 12 | 0; 
  7.     f = e | 0; 
  8.     h = d + 12 | 0; 
  9.     j = c[h >> 2] | 0; 
  10.     if ((j | 0) > 0) { 
  11.     c[h >> 2] = 0; 
  12.     k = 0 
  13.     } else { 
  14.     k = j 
  15.     } 
  16.     j = d + 24 | 0; 
  17.     if ((c[j >> 2] | 0) > 0) { 
  18.     c[j >> 2] = 0 
  19.     } 
  20.     l = d + 28 | 0; 
  21.     c[l >> 2] = 0; 
  22.     c[l + 4 >> 2] = 0; 
  23.     l = (c[1384465] | 0) + 3 | 0; 
  24.     do { 
  25.     if (l >>> 0 < 26) { 
  26.     if ((4980736 >>> (l >>> 0) & 1 | 0) == 0) { 
  27.     break 
  28.     } 
  29.     if ((c[1356579] | 0) > 0) { 
  30.     m = d + 4 | 0; 
  31.     n = 0; 
  32.     while (1) { 
  33.     o = c[(c[1356577] | 0) + (n << 2) >> 2] | 0; 
  34.     do { 
  35.     if (a[o + 22 | 0] << 24 >> 24 == 24) { 
  36.     if (!(Vp(d, o | 0) | 0)) { 
  37.     break 
  38.     } 
  39.     p = (c[m >> 2] | 0) + (((c[h >> 2] | 0) - 1 | 0) * 40 & -1) + 12 | 0; 
  40.     q = o + 28 | 0; 
  41.     c[p >> 2] = c[q >> 2] | 0; 
  42.     c[p + 4 >> 2] = c[q + 4 >> 2] | 0; 
  43.     c[p + 8 >> 2] = c[q + 8 >> 2] | 0; 
  44.     c[p + 12 >> 2] = c[q + 12 >> 2] | 0; 
  45.     c[p + 16 >> 2] = c[q + 16 >> 2] | 0; 
  46.     c[p + 20 >> 2] = c[q + 20 >> 2] | 0; 
  47.     c[p + 24 >> 2] = c[q + 24 >> 2] | 0 
  48.     } 
  49.     } while (0); 
  50.     o = n + 1 | 0; 
  51.     if ((o | 0) < (c[1356579] | 0)) { 
  52.     n = o 
  53.     } else { 
  54.     break 
  55.     } 
  56.     } 
  57.     r = c[h >> 2] | 0 
  58.     } else { 
  59.     r = k 
  60.     } if ((r | 0) == 0) { 
  61.     i = e; 
  62.     return 
  63.     } 
  64.     n = c[j >> 2] | 0; 
  65.     if ((n | 0) >= 1) { 
  66.     i = e; 
  67.     return 
  68.     } 
  69.     m = f | 0; 
  70.     o = f + 4 | 0; 
  71.     q = f + 8 | 0; 
  72.     p = n; 
  73.     while (1) { 
  74.     g[m >> 2] = 0.0; 
  75.     g[o >> 2] = 0.0; 
  76.     g[q >> 2] = 0.0; 
  77.     Vq(d, p, f, 0, -1e3); 
  78.     n = c[j >> 2] | 0; 
  79.     if ((n | 0) < 1) { 
  80.     p = n 
  81.     } else { 
  82.     break 
  83.     } 
  84.     } 
  85.     i = e; 
  86.     return 
  87.     } 
  88.     } while (0); 
  89.     if ((c[1356579] | 0) <= 0) { 
  90.     i = e; 
  91.     return 
  92.     } 
  93.     f = d + 16 | 0; 
  94.     r = 0; 
  95.     while (1) { 
  96.     k = c[(c[1356577] | 0) + (r << 2) >> 2] | 0; 
  97.     do { 
  98.     if (a[k + 22 | 0] << 24 >> 24 == 30) { 
  99.     h = b[k + 14 >> 1] | 0; 
  100.     if ((h - 1 & 65535) > 1) { 
  101.     break 
  102.     } 
  103.     l = c[j >> 2] | 0; 
  104.     p = (c[1384465] | 0) + 3 | 0; 
  105.     if (p >>> 0 < 26) { 
  106.     s = (2293760 >>> (p >>> 0) & 1 | 0) != 0 ? 0 : -1e3 
  107.     } else { 
  108.     s = -1e3 
  109.     } if (!(Vq(d, l, k | 0, h << 16 >> 16, s) | 0)) { 
  110.     break 
  111.     } 
  112.     g[(c[f >> 2] | 0) + (l * 112 & -1) + 56 >> 2] = +(b[k + 12 >> 1] << 16 >> 16 | 0); 
  113.     h = (c[f >> 2] | 0) + (l * 112 & -1) + 60 | 0; 
  114.     l = k + 28 | 0; 
  115.     c[h >> 2] = c[l >> 2] | 0; 
  116.     c[h + 4 >> 2] = c[l + 4 >> 2] | 0; 
  117.     c[h + 8 >> 2] = c[l + 8 >> 2] | 0; 
  118.     c[h + 12 >> 2] = c[l + 12 >> 2] | 0; 
  119.     c[h + 16 >> 2] = c[l + 16 >> 2] | 0; 
  120.     c[h + 20 >> 2] = c[l + 20 >> 2] | 0; 
  121.     c[h + 24 >> 2] = c[l + 24 >> 2] | 0 
  122.     } 
  123.     } while (0); 
  124.     k = r + 1 | 0; 
  125.     if ((k | 0) < (c[1356579] | 0)) { 
  126.     r = k 
  127.     } else { 
  128.     break 
  129.     } 
  130.     } 
  131.     i = e; 
  132.     return 
  133.     } 

 

從技術上說，這是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規範上的例子：

  1. function DiagModule(stdlib, foreign, heap) { 
  2.         "use asm"; 
  3.       
  4.         // Variable Declarations 
  5.         var sqrt = stdlib.Math.sqrt; 
  6.       
  7.         // Function Declarations 
  8.         function square(x) { 
  9.             x = +x; 
  10.             return +(x*x); 
  11.         } 
  12.       
  13.         function diag(x, y) { 
  14.             x = +x; 
  15.             y = +y; 
  16.             return +sqrt(square(x) + square(y)); 
  17.         } 
  18.       
  19.         return { diag: diag }; 
  20.     } 

看看這個模塊，它徹底能讓人理解！閱讀這些代碼，咱們能更好的理解Asm.js模塊的結構。一個模塊包含在一個函數中，它以頂部的"use asm";指令開始。它提示解釋器這個函數裏全部的東西能夠被當成Asm.js處理，並能夠直接被編譯成彙編代碼。

注意在函數頂部的三個參數：stdlib，foreigh和heap。stdlib對象包含了不少內建數學函數的引用。foreign提供了自定義用戶功能（例如在WebGL中繪製圖形）的訪問。最後，heap給了你一個ArrayBuffer，它能夠經過不少透鏡（例如Int32Array和Float32Array）來觀察。

該模塊剩下的被分紅了三部分：變量聲明，函數聲明，還有最後把函數導出暴露給用戶的一個對象。

導出是尤爲要去理解的一個重點，由於它既讓全部模塊中的代碼被當成Asm.js處理，又使得代碼能夠被其餘普通的Javascript代碼使用。所以，在理論上你能夠經過使用上面的DiagModule代碼，寫下以下代碼：

  1. document.body.onclick = function() { 
  2.     function DiagModule(stdlib){"use asm"; ... return { ... };} 
  3.     var diag = DiagModule({ Math: Math }).diag; 
  4.     alert(diag(10, 100)); 
  5. }; 

這帶來了一個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有點難度，如今咱們還不支持任何DOM對象。在咱們不斷爲asm.js添加ES6類型的對象時，這種想法有可能變得可行而而且更加有效。

這方面一個比較酷的應用可能就是看看到底web平臺能多有效的執行自承載業務。建立DOM.js一個動機就是想要看一下純JS實現的DOM可否擊敗傳統、低效的出入隊列式的、跨堆棧的JS堆與相關C++ DOM對象之間的內存管理方法。有了asm.js的支持，DOM.js也許能夠在性能上賽過那些高度優化過的數據結構。這值得一試。

編寫Asm.js代碼與編寫通常的Javascript代碼相比確實十分困難，你有什麼工具能夠提供給開發者和編譯器做者呢？

  • 首先最重要的是，咱們有LLJS這樣的語言。就像你提到的那樣，能夠將其編譯爲Asm.js。一樣，咱們在將其使用於web時也會有一些挑戰，例如使用source maps之類的技術將生成的代碼對應到瀏覽器開發者工具中的原始代碼。我很高興看到source maps的發展，它已經能夠反饋更加豐富的調試信息。咱們要在在source maps的極小尋址信息和格式複雜的調試信息（DWARF）之間進行取捨，這是一個代價平衡的問題。
  •  
  • 對asm.js而言，我認爲近期咱們將會將精力集中在LLJS上，同時我也一直歡迎開發者告訴咱們一些可以改善他們編程體驗的建議。

我以爲大家很樂於和其餘瀏覽器廠商一塊兒工做，大家的合做和討論進展如何？

沒錯。咱們之間有過一些非正式的討論，他們一直對咱們給予鼓勵，我相信咱們能作的更好。我很樂觀，咱們能夠與不少廠商一塊兒發展asm.js，那時 它可讓咱們輕鬆地在不改變架構的狀況下開發應用。就像我說的，事實上Luke只用了幾個月就開發出了OdinMonkey，這很使人激動。我很高興收到V8引擎下asm.js的bug報告。

更重要的是，我但願開發者能夠檢查asm.js的源碼，看看咱們是怎麼想的，並反饋給咱們和其餘瀏覽器廠商。
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程