摘要：探討一下軟體移植到鯤鵬平臺過程的原理，以及軟體工程的相應的過程。

Linux環境下跨平臺軟體移植過程中，需要開發者閱讀程式碼、手工修改、反覆編譯和除錯，移植週期長，效率低，那麼如何改進週期長，效率低的問題呢？

基於此，來自華為智慧計算專家張汝濤帶來了“90%程式碼如何實現自動移植到鯤鵬平臺”的主題分享活動，他主要從鯤鵬開發套件實現基於C/C++軟體的高效程式碼移植，加速開發者實現跨平臺軟體移植兩個層面進行分享。以下分享的速記內容：

今天要講的主題是關於軟體遷移這一件事，是一個久遠的話題。因為但凡是牽扯到切換平臺、CPU架構的變化，甚至一些語言版本的升級，我們都可能會面臨到一些軟體遷移的問題。今天一起來探討一下軟體移植過程的原理，以及軟體工程的相應的過程。

鯤鵬在軟體移植的過程當中，如何去幫助開發者去提升效率，如何把鯤鵬沉澱下來的，把華為沉澱下來的軟體開發以及一致的經驗如何反饋到開發者，讓開發者能夠加速軟體開發的進度，降低成本。我們推出我們鯤鵬的開發套件，幫助使用者做軟體的移植，以及做基於鯤鵬平臺的效能加速，今天主要是這樣三個內容。

一提到軟體移植，我不知道大家有多少是做了比較底層軟體的，做底層軟體的話，大家可能會用到一些彙編，C++加這樣的底層語言。用到這種底層語言，它是會和機器的硬體架構強相關的，當你在從一個平臺切換到另外一個平臺的時候，這些強相關的語言勢必要進行一次，跟我們所採用的程式語言以及移植的平臺環境強相關。

當我們用匯編程式碼或者是用這種編譯型語言的時候，我們就會面臨著一些移植的問題、一些挑戰。有些問題可通過編譯器能解決，有些問題特別是一些低階的程式碼或者底層的程式碼，我們就會可能要面臨著必須要手工去查手冊，然後去把它相應的去轉換到新平臺所使用的機器碼。

這裡就列出我們鯤鵬處理器和x86處理器的一個指令差異，例如一個簡單的兩個數相加，兩個int型相加的這樣一個簡單程式。通過GCC編譯完之後，我們去通過OMGD，我們就能看到指令的具體的格式形式以及相應的對應的彙編程式碼。這裡能看到對x86平臺而言，因為x86是CICS指令是複雜指令集，鯤鵬是完全相容Arm64架構的，是華為自研的vinic，指令集也是和Arm64副精簡指令集是完全相容的。

其實所謂的經限指定集和複雜指令集的區分是從上個世紀的70年代開始的，IBM曾經做過一個研究，就是關於說CPU如何去高效的執行，然後他們會發現可能有些常用的指令或者是程式程式碼，當時背景下常用的程式程式碼，可能常用的和不常用的有很大的差異，當時又因為IC的製程或者工藝或者器件的設計水平沒有現在這麼突飛猛進，所以就會想如何去把CPU從硬體設計上簡單一點，從軟體上高效一點，所以他們就提出了精簡指令集這麼一個概念，其最大顯著的特點就是它的指令寬度就是長度。我們說的指令長度，是相等的，也就說每一個指令這個位寬是相等的，那麼每個指令執行的SICO幾乎也相同，就是他把很繁雜的事情做的儘可能的簡單，然後用很多簡單的操作去完成一件複雜的任務。

從相反的複雜指令集的角度，我們看一下x86下面的複雜指令級，它每一個指定的長度是不同的，也就是說像這裡列舉的mov和add這兩個指令，它的機器碼、指令碼是不同的，長度是不同的，勢必會造成我們IC器件的解碼器，以及包括我們真正的到軟體流水操作上處理的步驟是不一樣的，也必然會導致我們每條指令的執行的週期是不同的，但是這樣也有一個好處，就是我一個指令就能完成一個比較複雜的事情，儘管說我的指令可能會變得很長，但是我一條指令能完成一比較複雜的事情，對上層的程式設計師來講，可能就便於理解或者是相對的會容易理解一些。

這就是精簡指令集和複雜指令集的一個簡單背景，在反彙編下來的x86指令集和鯤鵬指令集的彙編程式碼上，可以看到操作指令是完全不同的，計存器的命名也是完全不同的，在x86的平臺上，有16個通用暫存器。這裡講的是x86 64模式下，有16個通用暫存器，浮點計存器，根據我們支援的MMX技術、SSE或者是ABS技術，x86平臺最多可以存在32個浮點暫存器。

反觀鯤鵬平臺，因為它是和Arm64指令相容的，所以指令集要事完全對照，所以從這個角度來講，鯤鵬平臺有31個通用暫存器，除了這31個通用暫存器以外，還有一些狀態暫存器或者是一個站暫存器。那對應到浮點暫存器，就有32個這樣一個叫做ASMB的的advances單指令多資料這樣一個暫存器。鯤鵬有32個暫存器位，位寬是128。這一點是和x86 64平臺是有差異的，比如說現在x8664，它如果支援ABX512的話，它的位寬是500 12位元，從這個角度上，是一個硬體器件差異是非常明顯的。

然後從反彙編的角度來看，大家不知道有沒有注意到x86平臺上有一個mov指令。從第一行我們能看到從暫存器、rbp一個mov的儲存資料，到EDX這樣一個暫存器，做一個從把變數從記憶體裡漏斗進來。同樣的一件事情在上面的鯤鵬處理器平臺上暫存器的指令就變成了LDR和然後下面當然加法還是有add的，然後儲存的時候對於x86來講，又是從暫存器mov到了記憶體力，但是對於鯤鵬平臺它是用一個str指令，所以這也反映出了一個risk指令的特點，也許是第2個特點，我們姑且這麼叫，它是用一個load stall這樣一個模式，也就是說在鯤鵬處理器平臺上不支援記憶體到記憶體的一個直接訪問，必須要經過一個暫存器作為橋接作為一箇中轉。

這一點是和x86指令複雜型指令集不同的另外一個地方。還有就是在x86這個平臺上，它的記憶體訪問的模式非常多，對於公共平臺上就沒有豐富了。這個就是以一個程式為例，簡單列舉一下，從CPU的角度來看，同樣是一段C程式碼，CPU他做了不同的事情，執行了不同的指令，經過不同的週期不同的運算以後，它會輸出最終計算的一個結果。當然從這個角度來講，從這段程式兩個平臺是沒有任何差異的，除了指令上以外，執行結果是不會有任何變化。

但這裡側面反應出來，因為指令集不一樣，所以對於C，C++這樣偏底層的這樣一個語言來講，雖然它是個高階語言，但是必須要考慮一個平臺差異，在平臺切換的時候，甚至在平臺這個軟體的編制過程當中，就要考慮一個平臺相容性，所以要養成一個良好的程式設計習慣。

跨平臺移植軟體要面臨的不少問題，因為軟體移植本身就是一個工程性問題。這裡通常第1步來講，如果說我們決定從x86平臺遷移到鯤鵬平臺，就要去判斷一下這個軟體遷移值不值得，困難有多大？通常目前的常用的做法就是把x86的平臺，相應的軟體包拿下來，然後去看看它的依賴性關係。這個是什麼意思呢？就是我們看看這個軟體，如果跑在x86平臺上，它依賴哪些第三方元件？這些第三方元件在你這個目標平臺上存不存在要做一些這樣的判斷。這種判斷通常都是這個平臺之間的反反覆覆的安裝、執行，然後根據系統報出來的錯誤去一個個來排除，所以這都是通過人工來完成的，比較費勁。如果有移植經驗的同學就會覺得比較費勁，有些事情很繁瑣瑣碎，一個不小心就錯了，可能還找不出來原因。

當你解決完第1步編譯的過程的這個問題之後，你可能會還碰到一些跑過，結果新平臺上出現了function fault，功能性錯誤我們就很討厭了，可能性原因比較多，有的是本身軟體邏輯有問題；可能是第三方元件的APA跨平臺相容性有問題；可能是系統本身支援度也有問題，這個就是影響因素比較多。這樣就需要移植之後，技術人員去相應定位。定位對每個人對相應的工程人員來講，專業技術要求會比較高，也存在著一個反覆編譯、反覆調整、反覆驗證，這個過程成本會很高。

當完成了功能驗證之後，跑過一些基本測試以後，感覺這個軟體在新平臺上可以刊用了。你可能會面臨的一個性能的問題，當你用在工作環境、生產環境的情況下，因為生產環境的軟體都希望用最小的硬體跑出最大的效能，然後跑出最高的一個性價比，這時候都會對軟體效能上的需求，對它有要求。這個時候我們就會不得不去採取一些方法，例如用一些商業軟體也好，或者一些開源的軟體命令也好，去分析這個軟體的瓶頸到底是哪裡有問題，是系統有配置的引數有問題，還是我軟體本身邏輯有問題。

所以這三步是我們在華為的軟體這麼多年的開發過程當中積累下來覺得比較重要的三步，對我們軟體的質量、移植的質量是有決定性影響的。這三步也同時對於任何人來講，可能都不是一個能輕鬆逾越的幾個障礙。

對於我們軟體移植這件事情，通常我們講的是對於編譯型軟體會面臨這樣的一個困難，對於解釋性反而比較輕鬆，為什麼？比如像我們現在常用的一些Java的或者Python的，甚至一些GOD這樣一些軟體，我們的依賴是什麼？依賴的是語言所提供的虛擬執行環境，甚至是一些像Java提供的Java虛擬機器GUM，我們只需要選一相應平臺的GUM安裝，我們就能把底層的所有差異性都遮蔽掉。

這個軟體只根據執行環境去跑，通常是沒有問題的。對於像C,C++,GOD這種的，可能作為編譯，甚至說可能會呼叫C,C++加這種元件的這種軟體，我們就需要C,C++這種程式碼進行移植，可以分這麼幾種情況。

第1種是開源軟體，對我們通常是和社群進行合作，讓社群去支援空洞平臺，或者是支援M64的平臺，這樣我們就一勞永逸的解決問題。然後對於自研軟體，對於有些SB使用者會開發者資源軟體，他不能開放程式碼，我們就需要進行商業合作，去引導客戶去移植到我們鯤鵬平臺上。

對於商業B軟體是最典型的，比如說像微軟的一系列軟體，或者是Oracle的軟體資料庫，我們不可能去獲得原始碼，去推動他們和我們中國的軟體界合作也非易事.這個時候你只能找到要麼是合作，要麼就是找一個替代方案，對吧？如果實在是又不能替換使用者的業務，又不能去修改，我們就可能不得已採取一個鯤鵬平臺和x86進行一些混合部署，這是一個軟體部署方面的策略。

還有一種就是對於我們常用的windows平臺的一種系列開發，我們也知道windows雖然一年多前可能說要支援Arm64這個架構，但實際上到現在為止他也沒有宣佈。其實商業上的考慮或者是其他的因素可能都考慮的比較多，尤其是這樣一個大體量的公司，但是對於windows平臺就是說我們進行有限度的在開元生態裡面進行有限度的支援，比如說像微軟的C shut，其實他的call3.0已經開源了，已經在Arm平臺上能夠用起來了。換句話來講，我們也可以在鯤鵬平臺上基於call3.0支援C shut。對於鯤鵬軟體移植的過程，可以把它分解為這樣幾個步驟流程，其中最重要的就是所列到的第2步第3步以及效能達標分析這一步，我們現在提供了相應的每一步提供一些的輔助工具去幫助客戶進行使用者開發者進行分析進行移植。

其中的二進位制檔案依賴掃描，是我們去提供了一個工序軟體進行軟體安裝、依賴庫的掃描和軟體執行依賴庫的掃描。根據我們長期積累的有一個相容性清單，這個相容性清單覆蓋了市面上大多數流行的以及常用的OS以及相應的版本，還有相應的GCC的版本，對於移植的第二階段，像移植修改C，C++原碼，我們也同樣提供了一款工具去做C，C++原始碼的分析，這個分析主要是集中在這樣幾個方面，集中在彙編程式碼、邊選項，還有巨集定義，還有built in函式和編輯提供的built in函式和attribute，然後去重點檢查使用者的Makefile和CMakeList。如果使用者軟體是用make構建的或者CMake構建的，我們能幫助去發現一些，識別一些移植中需要修改的地方，同時我們會給出移植修改的建議。

當移植完成之後，我們會提供一個性能分析的工具，去幫助使用者去check這個軟體是不是能夠達到工作這樣一個標準，也就是說check它的效能指標，我們會去進行系統性的效能分析，也會去做軟體級的熱點定位分析。然後在此基礎上我們會給使用者提供一些華為所積累下來的認為比較有效的一些軟體優化的方法，做一些比如說終端版殼操作，甚至一些其他的軟體修改的這樣建議，這個就是我們今天要介紹的三款軟體，通過這三款軟體我們就能比較方便的或者比較高效率的完成C，C++程式碼，從非鯤鵬平臺向鯤鵬平臺的這樣一個遷移值的過程。

在C，C++軟體移植的過程當中，我們要著重考慮三個方面的問題，第1個問題是軟體構建檔案的差異。這裡面舉兩個例子，一種是咱們這個方案裡面，我們可能在x86平臺上常看到一個叫-M64的這樣一個知道編譯選項的option，這個含義，實際上是說要把我這個軟體生成成為64位模式的。是分成64位模式的，我們編譯目的碼的ABI。實際上在鯤鵬平臺上，我們可以用類似的，我們可以用-mabi=lp64去來替換，當然如果安全的情況下，加上-FPIC就生成一個flowting的address，來遮蔽一些底層的相關依賴性，這樣子就能達到一個編譯選項M64的一個替換。

還有一個就是對應Arm指令集、SA的這樣一個替換，我們常用的可能會見到一些-march的這樣一個引數，在x86的平臺上提供了多達二三十種架構平臺，從intend到AMD的各種各樣的，Arm平臺來說，就相對簡單一點，我們只需要去選用我們鯤鵬平臺，你CPU所支援的相容Arm的架構。我們鯤鵬920，我們進入的是AArm8.2-a這樣一個架構。如果這些版本比較新，比如說9.1以上的，我們就可以去選用-mtune=tsv110。這實際上是我們泰山微核心110這個型號這裡面會在Gcc內部進行了我們提了一些措施，針對架構做的一些的public的tune優化，能夠提供一個相對較好的效能。 效能增加，據說有5%~10%的效能提升。

接下來第二部分就是C，C++原碼的移植，這裡面也舉兩個例子，第1個例子是這個是基本資料型別，儘管說我們鯤鵬平臺支援的是LP64，然後這個x86平臺也支援LP64的這樣一個規範，但是實際上大家在某些細節定義上還是有區別的，雖然字元寬度，比如說對x來講都是8位元組，但是x86他這個x是有符號型別的，但是對於我們鯤鵬平臺，我們用是無符號型別的，但這塊的改動我們就可以通過修改makefile裡面，加一個引數，加上-makefilex，去把預設的無符號的x定義成有符號的x，這樣就能保證C程式碼邏輯，關於x操作上不會引入歧義。

第2類問題就是我們編譯器當中提供了多達數百個的這個巨集定義，可以被我們C，C++軟體識取，比如說我們用GC的話，我們可以在C，C++的軟體裡面，原檔案裡面直接去使用相應的巨集定義，這個巨集定義在編譯的時候可能會我們的編譯器直接做環境變數的check，然後直接設定了相應的正確的值，跟host環境相關的。我這裡指編譯和執行在同一款機器上，我們不講host和target相異的情況。這個時候對於相應的軟體，我們就可能需要區分一下巨集定義，比如說像這裡x86 64，顯然一看就知道他是支援x86的，不可能在我們鯤鵬平臺上執行，這時候我們就會建議使用者去修改使用者程式碼，用預編譯的方式做軟體範圍的定義隔離，很顯然對於我們鯤鵬平臺，我們常用的關鍵字就是aarch64或者是Arm64，這樣的關鍵字去做軟體邏輯的定義，除了這些以外，包括BBC都有各自的架構定義關鍵字。

第3類問題就是我們彙編程式碼的移植，這也是最頭疼的一塊，因為x86平臺如果細算的話，他將有2100個不到的彙編指令，鯤鵬平臺因為相容Arm64，我們有1000出頭，1100不到，這樣一個彙編指令，其實這加起來3000多條指令，如果大家想把它分清楚，那是非常痛苦的。Int的相應指令集的手冊有4000多頁，Arm相關指令集的手冊有7000多頁，純英文的文件大家讀起來肯定會崩潰的，所以在這裡面彙編程式碼的移植，這是一個難點。

彙編程式碼在我們的軟體過程中表現有若干種形式，第1種是我們純粹的就用Asm關鍵字去寫彙編程式碼，第2種是我們用built in函式做一些替換，比如說這裡舉個例子，像GCC裡提供了built in的CRC的32計算的一些加速指令，我們可以去尋找鯤鵬平臺上的相應的指令去進行替換，比如說像x86平臺上用到的預取的指令，我們也可以去找到鯤鵬平臺，上的built in函式去做替換。接下來還有第3種，就是我們可能會用到的Intrisic。Intrisic實際上是在jcc裡提供的像C語言可以一樣去使用的彙編函式，引出這個Intrisic是在x86平臺上和Arm64平臺，就相差非常的大。

在x86的平臺上Intrisic總數總數將近達到7000個，7000不到，然後在鯤鵬水平上相差就差的比較多，遠遠少於這個數，為什麼？這是因為在x86平臺上它支援的指令集比較多，他自己經過二三十年的演進，對吧？他有mx的指令集，有SSE的指令集，還有AVX，AVX也分了128位元的,256以及500 12位元的三種。 每一種它對應的Intrisic非常的多，所以移植的數量是非常大的。在這個裡面我們可以找到一些，比如說對於一個28位元的操作進行一些對應，可以做一些替換。

針對上面提出的這些問題，比如說我們C，C++剛才提出這些問題，我們就提供了這樣幾個工具，我們這裡提供了分析掃描工具，程式碼遷移工具。分析掃描工具，就是識別我們軟體移植的依賴性，然後去幫助使用者做相容性的排查。然後第2個提供程式碼遷移的工具是做原始碼的構建工程工程構建檔案，還有C，C++原碼以及彙編程式碼的掃描移植指導。第三個工具就是效能優化工具，我們剛把軟體移植到鯤鵬平臺之後，我們需要去用這個工具去分析效能，去發現熱點，我們也提供了基於鯤鵬平臺的一個加速庫這麼一個概念，一個元件。 這裡面就提供了一個軟體硬體協同加速使用者應用的一個方式。

比如說我們這裡優化了GDPC基礎執行環境，我們優化的壓縮、加密、加解密，包括一些數學計算這樣一些開源的或者是三方的組建，我們優化了一些IPP訊號處理的一些程式功能提升，就是用我們軟硬結合的方式極大提升了效能。這裡面我們大致分析的一個流程，我們會在分析掃描裡面，我們把使用者的軟體上傳到我們的工具環境下，我們工具環境就會分析使用者X86平臺上軟體的安裝包，比如說這裡的RPM包還有一些JAR、Java類的程式，包括一些壓縮包，我們就會去掃描識別裡面軟體包內部以及軟體安裝路徑內，包括我們壓縮包內部的整合的，比如說這些SO件、二進位制檔案，去檢驗它是否在鯤鵬平臺上不同的作業系統上是否支援，去反饋使用者一個一致性的分析報告，會逐個告訴使用者SO是否相容，不相容的話怎麼去處理？我們會提供連結是原碼的值，這個是原始碼級的連結，或者是提供移植文件方式書的這種連結，都會在我們報告裡提供出來。

我們這個工具提供了兩種工作方式，一種是我們通過命令列的方式，下面這種形式通過引數輸入，一種是通過這種外部方式，我們在做了安裝包的依賴性分析以及原碼的掃描之後，會給使用者產生一個移植分析指導的報告，這個報告是提供CVS的格式或者是HDM的格式，使用者可以去下載，裡面就會詳細羅列出哪些依賴庫，哪些二級制檔案需要移植，然後哪些C，C++以及彙編程式碼，需要移植規模有多大？ 會給使用者呈現一個移植的工作量，比如以每月為單位提供一個工作量。

計算標準，使用者是可以自己輸入的，比如說你的編正能力強，你一個月C,C++程式碼，你可以完成800行，彙編程式碼你可以完成600行，對吧？如果你的移植能力有限，有的編碼能力有限，技術成本有限，你可以把它設定成比如說我C,C++程式碼一個月300行，彙編程式碼100行，它就會根據不同的標準，計算出你移植工作量，做工程技術上的第1步，第1部資訊掌握。

這裡就列出了我們主要的功能，前面我已經基本贅述了，就是SO檔案的檢查，構建工程的檢查、原始檔的檢查，評估一致性，然後進行工作量評估，兩種方式，外部方式和命令列方式。

通過這個工具，我們就可以拿到軟體移植的工程量的第1手資料，然後決定是否移植。當決定極值之後，我們就可以用程式碼遷移工具去做進一步的分析，程式碼移植工具主要是分析了使用者的原始碼，還是一樣，他著重分析的是makefile，C，C++的原始碼，就包括我們這裡的編譯器提供的巨集定義，然後使用者自定義巨集，還有built in函式，Intrisic，還有彙編程式碼，我們分析完這些內容會提供一個詳盡的移植指導，這裡面就包含makefile怎麼修改？C，C++程式碼怎麼修改？ 然彙編程式碼，我們怎麼去修改？

這裡我們只是給移植建議，我們並不去修改使用者的原碼，使用者可以參照著相應的輸出我們這裡輸出的一致報告，去用GTDF的方式，大家去做一個這個對比，然後去把它在工具介面以外用第三方的，比如說用其他的編輯工具把它完成修改。那麼這一頁我們就列出了我們程式碼移植工具的一個大致工作流程，同樣我們也是外部方式和命令列方式兩種方式，方便使用者做選擇。我們分析使用者的原始碼構建工程，還有公共建工程配置檔案，還有C，CC+加的原始碼或者是彙編原始碼，然後給出移植知道，那麼對於原始碼的變化，我們會提供對比的方式顯示，像這裡舉的例子就是左邊第1點是我們要改哪些檔案，就是修改檔案列表，第2類就是我們要原檔案是什麼樣子，第3類就是我們建議修改成什麼樣子？

這是我們軟體移植工具所能提供的能力，我們C，C++，我們這裡還是針對C，C++目前為止C，C++的這樣編譯型語言,去做了建議值，然後我們要有原始碼，沒有原始碼，也就談不上移植了。

前面已經講了，我們如何去做軟體依賴性的分析，通過華為開發套件去做軟體依賴性的分析，以及做C,C++的移植，我們在完成移植之後，我們會在生產環境上去跑我們這個軟體，我們可能會去做效能分析，這時候我們就會提供一個我們叫做分析的一個工具，這個工具主要是幫助使用者去做軟體效能定位，比如說你有些效能瓶頸或者有想繼續優化，我們這裡提供了一些手段，這裡對於這個工具我們可以幫助使用者去分析處理器相關指標，以及看到排程的一些資訊，包括外設的資訊，包括CPU、磁碟，甚至網絡卡、短期性的資料，去幫助使用者分析C，C++或者是Java程式這樣一個性能指標。

我們Java類不是說把GBM當成一個程序，我們是看到GBM內部的，還是有一定作用的，還是比較有用的。我們會把這些資料統統的分析起來，然後通過我們自己定的定義的數學模型進行分析，去看到使用者的軟體效能瓶頸，比如說是資源競爭的問題或者是排程的問題，甚至說比如說有一些bug導致了一些次迴圈等等的，我們提供了多種的方式來呈現這樣一個結果。比如說我們常用的這種火焰圖的方式，我們這裡能夠提供比較直觀的視覺化方式，幫助使用者去看自己的軟體裡面到底有沒有性質上的問題。

這個是我們這裡是羅列一下我們目前效能分析工具能夠提供的效能指標，我們能夠看硬體器件相關的，比如CPU、記憶體、磁碟、網絡卡、系統級的，我們也能看這種線系統排程以及的比如說程序、執行緒，還有彼此之間的切換，或者是資源的爭搶，鎖這樣的一些關鍵變數的這樣一些效能分析先行指標，我們也提供了一個基於火焰圖、基於程式碼邏輯的深層次檢查，能夠提出使用者程式碼的真正的開銷，大的地方在哪裡，對應的程式碼對應到原始碼。

通過這樣一個手段，我們就能幫助客戶比較快的去幫助開發者比較快的定位自己的軟體，編譯形軟體的瓶頸。，當定位到軟體瓶頸的時候，我們會提供一些附加的能力，比如說這裡我們就提供加一個叫加速庫，我們軟硬結合的加速庫幫助使用者去優化程式碼。這個原因是什麼？這原因主要是因為我們鯤鵬是一個sock，我們是一個片量系統。

除了泰山核心，以及多達48甚至64的核心以外，我們還提供了一些額外的能力，額外的一些引擎，這些加速引擎就可以支援，比如說壓縮LZ77的這種演算法，還有加解密的，比如說非對稱的，還有對稱加密的，包括一些常用的變加解密的這樣演算法，比如說DH編碼等等。

我們還支援了比如說儲存用到code等一些這樣一些常用的軟體演算法，我們把它運化成加速器，這種壓縮用起來非常簡單，就跟我們用一個外設一樣，我們只需要從華為的網站上去獲取相應的硬體驅動程式碼，把它安裝上之後，我們就可以像一個正常的外設一樣去使用它。

當然了你要使用我們提供的一些API的話，可能還要遵循一些,比如說我們要提供給使用者手冊，使用者可能要去修改一下自己的原始碼，比如說可能原來掉的一些是軟體的這樣一些函式，或者是三方組建的API，這時候可能去要用加速器的話，就需要根據API修改我相應的這個程式碼邏輯，但這個程式碼邏輯只是存在於API層面。

這裡舉個例子，比如說我們這裡集成了一個叫RC的加速的引擎，是用來計算finish加密的，我們支援1024~4096，4種：1024 2048 3072 3096，4種金鑰長度。我們在我們加速器引擎裡面，我們是通過一個使用者態的來libry去做一個隔離，對上去隔離使用者的，比如說開源的第三方軟體，比如說這裡貼到open SSL的的API，我們去對接open SSAPI我們也可以把API暴露出來，直接給使用者的APP去使用，在libry下層的就是我們IC引擎的相應的驅動，使用者可以完全不用知道下面細節是如何實現的，但是我們通過只要使用我們正確呼叫鯤鵬RC的提供的使用者libry，就可以去使用我們加速器的硬體計算能力，極大的加快了RC的計算。

其實我們也知道RC計算如果用CPU算的話，那是相當費時費力的。比如說一個像x86的一箇中高階的一個call，可能它每秒鐘只能執行720次左右的一個RC2048的計算。但是你要用到了鯤鵬920提供的RC計算引擎的話，計算量將是大幅度的提升，也就是說，我可以把原本用來計算RC的這些CPU完全釋放出來，跑我的業務！在一個晶片內完成這樣業務，就會對使用者來講就會提供另外一個選擇，我不需要去買某些PCIE的插卡，我直接去用軟體的方式來提升我的軟體效能，達到一個比較簡單的提升效能的一個方式。 這是我們舉的一個例子，在這些裡面，在我們移植工具裡面，都會去通過我們軟體移植的這樣一些能力去提供給開發者直接使用。

這個是我們幾個工具組建的釋出的策略，我們目前為止是停留在中間這一列上，我們完成了多OS的適配，比如說我們支援3~4、74、7.5、7.6、7.7、7.8對吧？我們也支援中標麒麟等，我們也支援了像蘇C這樣一些的作業系統，就是我們儘可能的去幫儘可能覆蓋我們常用的這樣一些作業系統的型別，我們也支援了GCC的多個版本，我們從4.8.9一直支援到目前為止至少8.3，我們後續會支援到9點幾的版本，一直往上支援上去，幫助客戶去儘可能的簡化一些重複勞動，我們也支援MAC構建工具，也要支援CVK構建工具，未來還會支援automake這樣的一個構建工具的一些檢查。

支援C，C++的與程式碼移植，也支援彙編程式碼的識別，因為剛才前面說了，從彙編指令的角度來講，從你Intrisic的數量來講，這個量非常的大，而且也很有技術挑戰的，就是組合語言的替換，所以這塊我們會逐步完善。對於加速這一塊，我們是提供一些Intrisic的一些替換，比如說我們有abs或者有SSE。

我們也去優化了，像一些常用的加速的三方的元件，比如說像一些z-lib的加速或者stapi的一些加速，還有一些scan這種字元掃描的加速的，我們用鯤鵬的指令去進行優化，進行效能提升，取得了比較可觀的一個性能改變都是50%，一倍，甚至更多的3，4倍的這樣一個性能提升，所以加速的效果還是挺明顯的。這樣也能讓使用者的軟體應用跑在空間當中跑的更快又快又好。

如何去獲取我們這幾個工具，我們可以通過華為的spot網站去下載，也可以通過華為空方社群去下載相應的軟體，這上面提供了一些連結。

對於我們加速庫軟體，這裡的策略是主要採取開源的這種策略，比如說像JDPC或者一些三方組建的，包括一些壓縮演算法，壓縮引擎的，包括這些軟體元件，我們都是把相應的patch去推動到社群裡面去。對於硬體加速引擎，我們也是直接可以從華為的鯤鵬社群上去下載，然後去安裝使用，取用起來還是比較方便的。

鯤鵬社群以後就是華為重點建設的一個和開發者溝通的互動的地方橋樑。在這個地社群裡，我們就可以下載到數百份的軟體移植指導以及相應的軟體調優的經驗，可以在這裡面和其他的開發者做互動，做技術上進一步的探討。 然後很多新的技術資料、技術文件，包括一些白皮書，一些產品設計方案都會在社群裡陸續釋出，不同的開發者都能得到一些不同的資訊。

這裡列出來，我們空開發者社群裡面如何去得到兩工具這幾個工具，目前我們這些工具都已經上線了，9月30號是第1版本，9月30號以後我們是每月逐月釋出的這樣一個節奏，這個節奏將延續到2020年，就是說我們不是一個短期行為，我們會一直從開發者的需求角度來出發，去把這個工具做的更加應用，更加方便幫助使用者完成C，C++加程式碼的90%的工具化移植。

其實在鯤鵬的開發的平臺裡面，因為鯤鵬是空中平臺，是一個新生事物，對吧？對於x86而言是一個新生事物，在這個裡面我們也能感受到，隨著鯤鵬計算平臺的壯大，應用越來越多，需要大量的開發者去投入到平臺的生態建設裡面來。所以華為在這裡推出了這種線上認證培訓的這麼一系列的技能提升的活動，包括線上課程，包括雲端的實驗室，包括線上認證和線下培訓，希望大家能夠積極參與，來共同構建華為鯤鵬的生態軟體生態。

這裡提到一個華為鯤鵬認證開發工程師這麼一件事情，就是HCIA認證認證其實在華為內部還在對華為來講還是蠻有價值的，對開發者來講也是很有價值的。因為你通過了認證之後，在一定程度上將會成為你進入華為從事軟體開發的一個直通車。

所以大家可以關注一下相關的一些培訓認證的資訊，去找到一個適合自己的方向，然後去在一個更大的舞臺上，我們一起來構建華為鯤鵬的軟體生態環境，讓華為鯤鵬做得越來越好。

點選關注，第一時間瞭解華為雲新鮮技