2. 程式人生 > >Dart編譯技術在服務端的探索和應用

Dart編譯技術在服務端的探索和應用

阿新 • • 發佈：2019-04-11

前言

最近閒魚技術團隊在Flutter+Dart的多端一體化的基礎上，實現了FaaS研發模式。Dart吸取了其它高階語言設計的精華，例如Smalltalk的Image技術、JVM的HotSpot和Dart編譯技術又師出同門。由Dart實現的語言容器，它可以在啟動速度、執行效能有不錯的表現。Dart提供了AoT、JIT的編譯方式，JIT擁有Kernel和AppJIT的執行模式，此外服務端應用有各自不同的執行特點，那麼如何選擇合理的編譯方法來提升應用的效能？接下來我們用一些有典型特點的案例來引入我們在Dart編譯方案的實踐和思考。

案例詳情

相應的，我們準備了短週期應用（EmptyMain & Fibonnacci & faas_tool）,長週期應用（

HttpServer）分別來說明不同的編譯方法在各種場景下的效能表現

測試環境參考

#實驗機1
Mac OS X 10.14.3 
Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz * 4 / 16GB RAM

#實驗機2
Linux x86_64
Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz * 4 / 8GB RAM

#Dart版本
Dart Ver. 2.2.1-edge.eeb8fc8ccdcef46e835993a22b3b48c0a2ccc6f1 

#Java HotSpot版本
Java build 1.8.0_121-b13 
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

#GCC版本
Apple LLVM version 10.0.1 (clang-1001.0.46.3)
Target: x86_64-apple-darwin18.2.0
Thread model: posix

短週期應用

Case1. EmptyMain

例子是一個空函式實現，以此來評估語言平臺本身的啟動效能，我們使用預設引數編譯一個snapshot

#1.預設條件下的app-jit snapshot生成
dart snapshot-kind=app-jit snapshot=empty_main.snapshot empty_main.dart

測試結果

  • 作為現代高階語言Dart和Java在啟動速度上在同一水平線
  • C語言的啟動速度是其它語言的20x，基本原因是C沒有Java、Dart語言平臺的Runtime
  • Kernel和AppJIT方式執行有穩定的微小差異，總體AppJIT優於Kernel

Case2. Fibonacci數列

我們分別用C、Java、Dart用遞迴實現Fibonacci(50)數列，來考察編譯工作對效能的影響。

long fibo(long n){
  if(n < 2){
    return n;
  }
  return fibo(n - 1) + fibo(n - 2);
}

AppJIT使用優化閾值實現激進優化,這樣編譯器在Training Run中立即獲得生成Optimized程式碼

#2.執行激進優化          
dart --no-background-compilation \
     --optimization-counter-threshold=1 \ 
     --snapshot-kind=app-jit \
     --snapshot=fibonacci.snapshot
     fibonacci.dart

將Fibonacci編譯成Kernel

#3.生成Kernel snapshot
dart --snapshot=fibonacci.snapshot fibonacci.dart

AoT的Runtime不在Dart SDK裡，需要自行編譯AoT Runtime

#4.AoT編譯
pkg/vm/tools/precompiler2 fibonacci.dart fibonacci.aot

#5.AoT的方式執行
out/ReleaseX64/dart_precompiled_runtime fibonacci.aot

測試結果

  • Dart JIT對比下,AppJIT在激進優化後效能稍好於Kernel，差距微小，編譯的成本佔比可以忽略不計
  • Dart AoT模式下的效能約為JIT的1/6不到
  • JIT執行模式下，HotSpot的執行效能最優，優於Dart AppJIT 25%以上
  • 包括C語言在內的AoT執行模式效能均低於JIT,Dart AppJIT效能優於25%

問題

AoT由於自身的特性(和語言無關)，無法在執行時基於Profile實現程式碼優化，峰值效能在此場景下要差很多，但是為何Dart VM比HotSpot有25%的差距？接下來我們針對Fibonacci做進一步優化

#6.編譯器調優，調整遞迴內聯深度
dart --inlining_recursion_depth_threshold=5 fibonacci.snapshot 50

#7.編譯器調優，HotSpot調整遞迴內聯深度
java -XX:MaxRecursiveInlineLevel=5 Fabbonacci 50

測試結果

  • HotSpot VM效能全面領先於Dart VM;兩者在最優情況下HotSpot VM的效能優於Dart 9%左右
  • Dart VM 藉助JIT調優，效能有大幅提升，相比預設情況有40%左右的提升
  • Dart AppJIT 效能微弱領先Kernel

也許也不難想象JVM HotSpot目前在伺服器開發領域上的相對Dart成熟，相比HotSpot，DartVM的“出廠設定”比較保守，當然我們也可以大膽猜測，在服務端應用下應該還有除JIT的其它優化空間；
和Case1相同，Kernel模式的效能依然低於AppJIT,主要原因是Kernel在執行前期需要把AST轉換為堆資料結構、經歷Compile、Compile Optimize等過程，而在適當Training run後的AppJIT snapshot在VM啟動時以優化後的IL(中間程式碼)執行，但很快Kernel會追上App-jit，最後效能保持持平。有興趣的讀者可以參閱Vyacheslav Egorov Dart VM的文章。

Case3. FaaS容器編譯工具

在前面我們提到過Dart版本的FaaS語言容器，為追求極致的研發體驗，我們需要縮短使用者Function打包到部署執行的時間。就語言容器層面而言，Dart提供的Snapshot技術可以大大提升啟動速度，但是從使用者Function到Snapshot（如下圖）生成所產生的編譯時間在不做優化的情況下超過10秒,還遠遠達不到極致體驗的要求。我們這裡通過一些測試，來尋找提升效能的途徑

faas_tool是一個完全用Dart編寫的程式碼編譯、生成工具。依託於faas_tool, Function的編寫者不用關心如何打包、接入中介軟體，faas_tool提供一系列的模版及程式碼生成工具可以將使用者的使用成本降低，此外faas_tool還提供了HotReload機制可以快速響應變更。

這次我們提供了基於AoT、Kernel、AppJIT的用例來執行Function構建流程，分別記錄時間消耗、中間產物大小、產物生成時間。為了驗證在JIT場景下DartVM是否可通過調整Complier的行為帶來效能提升，我們增加了JIT的測試分組

測試結果

                                                                                                                   FaaS編譯工具-執行情況柱形圖 

  • AoT>AppJIT>kernel，其中AoT比優化後的AppJIT有3倍左右效能提升，效能是Source的1000倍
  • JIT(Kernel, AppJIT)分組下，通過在執行時減少CompilerOptimize或暫停PGO可以提升效能

很顯然faas_tool最終選擇了AoT編譯，但是效能結果和Case2大相徑庭，為了搞清楚原因我們進一步做一下CPU Profile

CPU Profile

AppJIT

Dart App-jit模式 43%以上的時間參與編譯,當然取消程式碼優化,可以讓編譯時間大幅下降，在優化情況下可以將這個比率下降到13%

Kernel

Kernel模式有61%以上的CPU時間參與編譯工作, 如果關閉JIT優化程式碼生成,效能有15%左右提升,反之進行激進優化將有1倍左右的效能損耗

AoT下的編譯成本

AoT模式下在執行時幾乎編譯和優化成本(CompileOptimized、CompileUnoptimized、CompileUnoptimized 佔比為0)，直接以目標平臺的程式碼執行，因此效能要好很多。

P.S. DartVM 的Profile模組在後期的版本升級更改了Tag命名, 有需要進一步瞭解的讀者參考VM Tags

附：DartVM調優和命令程式碼

#8.模擬單核並執行激進優化           
dart --no-background-compilation \
     --optimization-counter-threshold=1 \ 
      tmp/faas_tool.snapshot.kernel 
      
#9.JIT下關閉優化程式碼生成
dart --optimization-counter-threshold=-1 \ 
      tmp/faas_tool.snapshot.kernel 

#10. Appjit verbose snapshot
dart --print_snapshot_sizes \
     --print_snapshot_sizes_verbose \
     --deterministic  \
     --snapshot-kind=app-jit \
     --snapshot=/tmp/faas_tool.snapshot faas_tool.dart \
     
#11.Profile CPU 和 timeline 
dart --profiler=true \
     --startup_timeline=true \
     --timeline_dir=/tmp \
     --enable-vm-service \
     --pause-isolates-on-exit faas_tool.snapshot

長週期應用

HttpServer

我們用一個簡單的Dart版的HttpServer作為典型長週期應用的測試用例，該用例中有JsonToObject、ObjectToJson的轉換，然後response輸出。我們分別用Source、Kernel以及AppJIT的方式在一定的併發量下執行一段時間

void processReq(HttpRequest request){
  try{
    final List<Map<String,dynamic>> buf = <Map<String,dynamic>>[];
    final Boss boss = new Boss(numOfEmployee: 10);
    //Json反序列化物件
    getHeadCount(max: 20).forEach((hc){
      boss.hire(hc.idType, hc.docId);
      buf.add(hc.toJson());
    });
    request.response.headers.add('cal','${boss.calc()}');
    //Json物件轉JsonString
    request.response.write(jsonEncode(buf));
    request.response.close()
      .then((v) => counter_success ++)
      .timeout(new Duration(seconds:3))
      .catchError((e) => counter_fail ++));
  }  
  catch(e){
    request.response.statusCode = 500;
    counter_fail ++;
    request.response.close();
  }
}

測試結果


 
_                                                                                                                  Y軸表示成功的請求量，X軸為時間_
_

  • 上面三種無論是何種方式啟動，最終的執行時效能趨向一致，編譯成本在後期可以忽略不計，這也是JIT的執行特點
  • 在AppJIT模式下在應用啟動起初就有接近峰值的效能，即使在Kernel模式下也需要時間預熱達到峰值效能，Source模式下VM啟動需要2秒以上，因此需要相對更長時間達到峰值效能。從另一方面看應用很快完成了預熱，不久達到了峰值效能

P.S. 長週期的應用Optimize Compiler會經過Optimize->Deoptimize->Reoptimize的過程, 由於此案例比較簡
單，沒體現Deoptimize到Reoptimize的表現

附：VM調優指令碼

#12.調整當前isolate的新生代大小，預設2M最大32M的新生代大小造成頻繁的YGC
dart --new_gen_semi_max_size=512  \
     --new_gen_semi_initial_size=512  \ 
     http_server.dart \
     --interval=2

總結和展望

Dart編譯方式的選擇

  • 編譯成本為主導的應用，應優先考慮AoT來提高應用效能
  • 長週期的應用在啟動後期編譯成本可忽略，應該選擇JIT方式並開啟Optimize Compiler,讓優化器介入
  • 長週期的應用可以選擇Kernel的方式來提升啟動速度，通過AppJIT的方式進一步縮短warmup時間

AppJIT減少了編譯預熱的成本，這個特性非常適合對一些高併發應用線上擴容。Kernel作為Dart編譯技術的前端，其平臺無關性將繼續作為整個Dart編譯工具鏈的基礎。

在FaaS構建方案的選擇

通過CPU Profile得出faas_tool是一個編譯成本主導的應用，最終選擇了AoT編譯方案，結果大大提升了語言容器的構建的構建速度，很好滿足了faas對開發效率的訴求

仍需改進的地方

從JIT效能表現來看，DartVM JIT的執行時性和HotSpot相比有提升餘地，由於Dart語言作為服務端開發的歷史不長，也許隨著Dart在服務端的技術應用全面推廣，相信DarVM在編譯器後端技術上對伺服器級的處理器架構做更多優化

作者：閒魚技術-無浩

原文連結

本文為雲棲社群原創內容，未經

相關推薦

Dart編譯技術在服務端的探索和應用

前言 最近閒魚技術團隊在Flutter+Dart的多端一體化的基礎上，實現了FaaS研發模式。Dart吸取了其它高階語言設計的

人臉識別技術在HBase中的探索和應用

一、HBase基礎與儲存的優勢HBase主要具有五大核心優勢，即海量儲存、列式儲存、易擴充套件、高併發以及稀疏矩陣。HBase所能夠應用的場景包括物件儲存、使用者畫像推薦、聊天訊息實時流、索引、報表以及軌跡資料和監控資料等。 二、HBase應用分享這裡主要分享一下HBase在人臉識別場景中的應用。在京東，人

webservice服務端釋出和客戶端呼叫

1.服務端和客戶端增加Maven依賴包，如下 <!-- cxf方式webservice服務 --> <dependency>             <group

服務端渲染和客戶端渲染的對比

這裡結合art-template模板引擎說明。 首先了解下前端頁面中如何使用art-template 1、script 標籤匯入包，當這個標籤匯入完畢後，在window全域性中就有了template 函式。 2、建立一個script標籤，內部是模板字串 <script type="te

Java 服務端入門和進階指南

作者：謝龍 連結：https://www.zhihu.com/question/29581524/answer/44872235 來源：知乎 著作權歸作者所有，轉載請聯絡作者獲得授權。 現在網際網路上資源豐富，Java 學習並不難。貼個 Java 服務端入門和進階指南，是給我們組新人入門用的，包括了

kafka 服務端消費者和生產者的配置

在kafka的安裝目錄下，config目錄下有個名字叫做producer.properties的配置檔案 #指定kafka節點列表，用於獲取metadata，不必全部指定 #需要kafka的伺服器地址，來獲取每一個topic的分片數等元資料資訊。 metadata.broker.list=kafka0

node——10-服務端渲染和客戶端渲染的區別

客戶端渲染不利於 SEO 搜尋引擎優化 服務端渲染是可以被爬蟲抓取到的，客戶端非同步渲染是很難被爬蟲抓取到的 所以你會發現真正的網站既不是純非同步也不是純服務端渲染出來的 而是兩者結合來做的 例如京東商品列表是採用的服務端渲染，目的是為了 SEO 搜尋引擎優化 而它的商品評論列表

三週學會小程式第三講：服務端搭建和部署

通過第二講我們已經知道了怎麼快速搭建一個小程式客戶端，當然服務端也是必不可少的。登入驗證，內容儲存等等都離不開服務端。 本章節主要講解怎麼快速搭建一個服務端框架和免費部署。因為好多同學僅僅為了學習小程式，為此購買一個伺服器成本還是蠻高的，所以小編特此找了一種免費的服務資源提供給大家，等到你真正要部署小程式的時

vue服務端渲染快取應用

vue快取分為頁面快取、組建快取、介面快取，這裡我主要說到了頁面快取和介面快取 頁面快取： 　　在server.js中設定 const LRU = require('lru-cache') 1 2 3 4 5 6

Linux系統git服務端搭建和web專案的自動更新

伺服器端 1.linux伺服器上搭建 【centos】 yum install -y git 2.搭建完成後使用命令檢視 git --version 3. 伺服器端建立 git 使用者，用來管理 Git 服務，併為 git 使用者

SVN的安裝(服務端安裝和客戶端安裝詳細流程)

VisualSVN安裝-服務端 下載:VisualSVN安裝下載 安裝:下載完成後可以看到VisualSVN-Server的相關安裝包 上圖中: Location:是安裝主目錄 Repos

react精華之next.js getInitialProps自動切換服務端渲染和瀏覽器渲染 而不需要同時使用渲染

我們已經知道了伺服器端渲染的原理，你只需要搭建一個 Express 伺服器，在伺服器端手工打造『脫水』，在瀏覽器端做『注水』，完成某個頁面的伺服器端渲染並不難。 不過，伺服器端渲染的問題並不這麼簡單，一個最直接的問題，就是怎麼處理多個頁面的『單頁應用』（Single-Page-Applicati

postgresql從入門到菜鳥（二）服務端配置和psql連線

上一篇文章我們已經成功在rehel上安裝了postgrel資料庫。 關於window環境下的安裝，可以直接下載install檔案，進行雙擊安裝，或者通過編譯原始碼的方式安裝。 本篇文章將介紹postgresql資料的基本配置，以及客戶端與伺服器端的連線。 先看伺服器端 當我們通過

node服務端渲染和客戶端渲染的區別

1.客戶端渲染不利於SEO搜尋引擎優化 2.服務端渲染是可以被爬蟲抓取到的，客戶端非同步渲染是很難被爬蟲抓取到的   + 所以你會發現真正的網站既不是純非同步也不是純服務端渲染出來的   + 而是兩者結合來做的   + 例如京東的商品列表就採用的是服務端渲染，目

Linux下的socket程式設計實踐（四）TCP服務端優化和常見函式

併發下的殭屍程序處理 只有一個程序連線的時候，我們可以使用以下兩種方法處理殭屍程序： 1）通過忽略SIGCHLD訊號，避免殭屍程序     在server端程式碼中新增     signal(

Next.js 8.0.0-canary.3 釋出，服務端渲染 React 應用

   v8.0.0-canary.3 釋出了，Next.js 是一個用於在服務端渲染 React 應用程式的簡單框架。 主要更新 更換 event-emitter.js。 #5987 其他更新 在 README 中新增中文 #5046 使用 lo

Next.js 8.0.0-canary.4 釋出，服務端渲染 React 應用

   v8.0.0-canary.4 釋出了，Next.js 是一個用於在服務端渲染 React 應用程式的簡單框架。 更新內容 為 graphql-react 新增一個示例 #5984 修復 Head.propTypes #6020 當客戶端在專案

Next.js 8.0.0-canary.5 釋出，服務端渲染 React 應用

   v8.0.0-canary.5 釋出了，Next.js 是一個用於在服務端渲染 React 應用程式的簡單框架。 更新內容 轉移 next/router 以使用 React.createContext: #6030； 在錯誤頁面增加了 displayName: #6

Next.js 8.0.0-canary.6 釋出，服務端渲染 React 應用

   Next.js v8.0.0-canary.6 釋出了，Next.js 是一個用於在服務端渲染 React 應用程式的簡單框架。 更新說明： 除非 asPath 不變，否則不該替換方法成 replaceState: #6033 將 webpack 動態條目相容的註釋

淺談服務端指令碼和客戶端指令碼

    ASP.NET是一種嵌入網頁中的指令碼可由因特網伺服器執行的伺服器端指令碼技術。所以在學習ASP.NET程式設計之前，我覺得我們有必要來了解一下指令碼技術。那麼指令碼究竟是什麼呢？ 一、什麼是