華爲鯤鵬專家解讀：90%代碼如何移植到鯤鵬平臺

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

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~四、7四、7.五、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認證認證其實在華爲內部還在對華爲來說仍是蠻有價值的，對開發者來說也是頗有價值的。由於你經過了認證以後，在必定程度上將會成爲你進入華爲從事軟件開發的一個直通車。

因此你們能夠關注一下相關的一些培訓認證的信息，去找到一個適合本身的方向，而後去在一個更大的舞臺上，咱們一塊兒來構建華爲鯤鵬的軟件生態環境，讓華爲鯤鵬作得愈來愈好。

點擊關注，第一時間瞭解華爲雲新鮮技術~