技術分享 | 如何將代碼自動遷移到鯤鵬平臺

本文內容源視頻地址：

https://huaweicloud.bugu.mudu.tv/watch/ym1bzp7p

大家好，今天要講的主題是關于軟件遷移，這是一個久遠的話題，因為但凡牽扯到切換平臺、CPU架構的變化，甚至一些語言版本的升級，都可能會面臨到軟件遷移的問題。今天我們就探討一下軟件移植過程的原理，以及如何進行軟件遷移。

在軟件移植的過程當中，如何幫助開發(fā)者提升效率，如何把華為沉淀下來的軟件開發(fā)以及移植的經(jīng)驗反饋給開發(fā)者，幫助開發(fā)者加速軟件開發(fā)的進度，降低成本，這是我們一直關注的問題，為此，我們還推出了鯤鵬的開發(fā)套件，幫助用戶做軟件的移植，以及做基于鯤鵬平臺的性能加速。

其實一提到軟件移植，如果是做了比較底層軟件的話，大家可能會用到一些匯編這樣的底層語言。它和機器的硬件架構強相關，當你在從一個平臺切換到另外一個平臺的時候，這些強相關的語言勢必要進行一次代碼移植，跟我們所采用的編程語言以及移植的平臺環(huán)境強相關。當我們用匯編代碼或者是用這種編譯型語言的時候，就會面臨著一些移植的問題和挑戰(zhàn)，有些問題通過編譯器能解決，有些問題特別是一些低階的代碼或者比較底層的代碼，就要手工去查手冊，然后去把它相應的轉換成新平臺所使用的機器碼。

上圖列出了鯤鵬處理器和x86處理器的指令差異，列了一個簡單的兩個數(shù)相加，兩個int型相加的這樣一個簡單程序。通過GCC編譯完之后，通過OMGD，就能看到指令的具體的格式形式以及相應的對應的匯編代碼。可以看出，對應x86平臺而言， X86是復雜指令集，鯤鵬是完全兼容Arm64架構的，指令集也是和Arm64精簡指令集是完全兼容的。

這里講一下背景，其實所謂的精簡指令集和復雜指令集的區(qū)分是從上個世紀70年代開始的，IBM曾經(jīng)做過一個研究，關于CPU如何去高效的運行，他們發(fā)現(xiàn)有些常用的指令或者是程序代碼，常用的和不常用的有很大的差異，又因為集成電路的制程、工藝或器件的設計水平?jīng)]有現(xiàn)在這么突飛猛進，就會想如何把CPU從硬件上設計簡單一點，從軟件上高效一點，所以就提出了精簡指令集這個概念，其最大的特點就是它的指令寬度是相等的，每個指令執(zhí)行的周期幾乎也相同，它把很繁雜的事情做的盡可能的簡單，然后用很多簡單的操作去完成一件復雜的任務。

從相反的復雜指令集的，我們看一下x86下面的復雜指令集，它每一個指令的長度是不同的，像這里列舉的mov和add這兩個指令，它的機器碼、指令碼是不同的，長度是不同的，勢必會造成IC器件的解碼器，到軟件流水操作上處理的步驟是不一樣的，也必然會導致每條指令的執(zhí)行周期不同，但是這樣也有一個好處，就是一個指令就能完成一個比較復雜的事情，盡管說指令可能會變得很長，但是一條指令能完成一比較復雜的事情，對上層的程序員來講，會容易理解一些。

這就是精簡指令集和復雜指令集的一個簡單背景，我們能看到，在反匯編下來的x86指令集和鯤鵬指令集的匯編代碼上，操作指令是完全不同的，寄存器的命名也是完全不同的，在x86的平臺上，有16個通用寄存器， x86 64模式下，有16個通用寄存器，浮點寄存器，根據(jù)支持的MMX技術或者SSE技術。

反觀鯤鵬平臺，因為是和Arm64指令兼容的，所以指令集要完全對照，從這個角度來講，鯤鵬平臺有31個通用寄存器，除了這31個通用寄存器以外，還有一些狀態(tài)寄存器或者是一個棧寄存器，對應到浮點寄存器，就有32個叫做單指令多數(shù)據(jù)這樣一個寄存器，32個寄存器位，位寬是128，這一點是和x86 64平臺是有差異的，比如說x86 64如果支持AVX512的話，那么它的位寬是512比特，從這個角度上，硬件器件差異是非常明顯的。

從反匯編的角度來講，不知道大家有沒有注意到x86平臺上有一個mov指令。從第一行我們能看到從寄存器rbpmov一個存儲數(shù)據(jù)，到EDX這樣一個寄存器，把變量從內存里拷貝進來。同樣的一件事情，在鯤鵬處理器上加載數(shù)據(jù)到寄存器的指令就變成了LDR，加法指令仍然是add，存儲時對于x86來講，是從寄存器mov到了內存里，但是對于鯤鵬平臺它是用str指令，這也反映出精簡指令的特點，它是用load stall模式，也就是說在鯤鵬處理器平臺上不支持內存到內存的直接訪問，必須要經(jīng)過寄存器作為橋接來中轉。

這是和x86指令復雜指令集不同的另外一個地方，還有就是在x86平臺上，它的內存訪問的模式非常多，對于公共平臺上就沒有那么豐富了。以一個程序為例，我們簡單列舉一下，從CPU的角度來看，同樣是一段C代碼，CPU做了不同的事情，執(zhí)行了不同的指令，那么經(jīng)過不同的周期不同的運算以后，它會輸出最終計算的一個結果。當然從這個角度來講，從這段程序兩個平臺是沒有任何差異的，除了指令上以外，執(zhí)行結果不會有任何變化。

跨平臺移植軟件要面臨的不少問題，因為軟件移植本身就是一個工程性問題。這里通常第1步來講，如果說我們決定從x86平臺遷移到鯤鵬平臺，就要去判斷一下這個軟件遷移值不值得，困難有多大？目前常用的做法就是把x86平臺，相應的軟件包拿下來，然后去看它的依賴性關系。看看這個軟件，如果跑在x86平臺上，他依賴哪些第三方組件？這些第三方組件在目標平臺上存不存在要做一些判斷，這種判斷通常都是這個平臺之間的反反復復的安裝，去運行，然后根據(jù)系統(tǒng)報出來的錯誤去一個個來排除，這都是通過人工來完成的，如果有移植經(jīng)驗的同學就會覺得比較費勁，很繁瑣瑣碎，不小心就錯，可能還找不出來。

當解決完第1步編譯過程的問題之后，可能會還碰到跑過之后，結果新平臺上出現(xiàn)了function fault，功能性錯誤原因比較多，有的是軟件邏輯有問題，第2個可能是第三方組件的跨平臺兼容性有問題，第3個可能是系統(tǒng)本身支持度也有問題，影響因素比較多，這就需要移植之后，技術人員去定位，定位對工程人員來講，專業(yè)技術要求會比較高，也存在著一個反復編譯、反復調整、反復驗證，這個過程成本會很高。

當完成了功能驗證，跑過一些基本測試以后，可能又會面臨的一個性能問題，當用在工作環(huán)境、生產環(huán)境的情況下，因為生產環(huán)境的軟件都希望用最小的硬件跑出最大的性能，跑出最高的性價比，這時候都會對軟件性能有要求。就不得不采取一些方法，例如用一些商業(yè)軟件，或者一些開源的軟件命令，去分析軟件的瓶頸到底是哪里有問題？是系統(tǒng)有配置的參數(shù)有問題，還是軟件本身邏輯有問題？

這三步是我在軟件開發(fā)過程當中積累下來覺得比較重要的三步，對軟件的質量、移植的質量有決定性影響。這三步對于任何人來講，可能都不是一個能輕松逾越的障礙。

再稍微解釋一下，對于軟件移植這件事情，通常我們講的是編譯型軟件會面臨的困難，對于解釋性反而比較輕松，為什么？比如像現(xiàn)在常用的Java或者Python，甚至Go，我們的依賴是什么？依賴的是語言所提供的虛擬運行環(huán)境，甚至是像Java提供的Java虛擬機JVM，只需要選相應平臺的JVM安裝，就能把底層的所有差異性都屏蔽掉。

軟件根據(jù)運行環(huán)境去跑，通常是沒有問題的。對于像C,C++這種，作為編譯，甚至可能會調用C,C++這種組件的軟件，就需要對C,C++進行移植，分這幾種情況：

第1種是開源軟件，通常是和社區(qū)進行合作，讓社區(qū)去支持空洞平臺，或者是支持ARM64的平臺，這樣就能一勞永逸的解決問題。對于自研軟件，不能開放代碼，就需要進行商業(yè)合作，引導客戶移植到鯤鵬平臺上。

對于商業(yè)軟件，最典型的，比如說像微軟的一系列軟件，或者是Oracle的軟件數(shù)據(jù)庫，不可能去獲得源碼，去推動他們和中國的軟件界合作，可能也非易事，那么這個時候只能找到要么是合作，要么就是找一個替代方案，如果實在是不能替換用戶的業(yè)務，又不能去修改，就不得已采取一個鯤鵬平臺和x86進行混合部署，這是一個軟件部署方面的策略。

還有一種就是對于常用的windows平臺的系列開發(fā)，windows雖然一年多前說要支持Arm64這個架構，但實際上到現(xiàn)在為止他也沒有宣布，商業(yè)上的考慮或者是其他的因素可能都考慮的比較多，對這樣大體量的公司，windows平臺就是進行有限度的在開源生態(tài)里面進行有限度的支持，比如說像微軟的C#，.net core3.0已經(jīng)開源了，已經(jīng)在Arm平臺上能夠用起來了。換句話來講，我們也可以在鯤鵬平臺上基于.net core3.0支持C#。對于鯤鵬軟件移植的過程，我們把它分解為這樣幾個步驟流程，其中最重要的就是所列到的第2步第3步以及性能達標分析這一步，我們現(xiàn)在提供了相應的每一步提供一些輔助工具，去幫助客戶進行用戶開發(fā)者進行分析進行移植。

二進制文件依賴掃描，我們提供了一個工序軟件進行軟件安裝、依賴庫的掃描和軟件運行依賴庫的掃描。根據(jù)長期積累的有一個兼容性清單，這個兼容性清單覆蓋了市面上大多數(shù)流行的或者常用的OS以及相應的版本，還有相應的GCC的版本，對于移植的第二階段，像移植修改C，C++源碼，我們也同樣提供了一款工具去做C，C++源碼的分析，這個分析主要是集中在幾個方面，匯編代碼、邊選項，宏定義， builtin函數(shù)和編輯提供的builtin函數(shù)和attribute，去重點檢查用戶的Makefile和CMakeList。如果用戶軟件是用make構建的或者CMake構建的，那么我們能幫助去發(fā)現(xiàn)，識別一些移植中需要修改的地方，同時我們會給出移植修改的建議。

當移植完成之后，我們會提供一個性能分析的工具，幫助用戶去check這個軟件是不是能夠達到工作標準，也就是check它的性能指標，我們會進行系統(tǒng)性的性能分析，也會去做軟件級的熱點定位分析。然后在此基礎上會給用戶提供華為積累下來的比較有效的一些軟件優(yōu)化的方法，這個就是我們今天要介紹的三款軟件，通過這三款軟件我們就能比較方便的或者比較高效率的完成C，C++代碼，從X86平臺向鯤鵬平臺遷移。

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

還有一個就是對應Arm指令集替換，常用的可能會見到一些-march參數(shù)，在x86的平臺上提供了多達二三十種架構平臺，從Intel到AMD的各種各樣的，Arm平臺來說，就相對簡單一點，只需要去選用鯤鵬平臺，CPU所支持的兼容Arm的架構。如果版本比較新，比如說9.1以上的，可以選用-mtune=tsv110。這實際上是泰山微內核110這個型號在GCC內部進行了一些措施，針對架構做的一些的public的tune優(yōu)化，能夠提供一個相對較好的性能，性能增加，有5%~10%的性能提升。

接下來第二部分就是C，C++源碼的移植，這里也舉兩個例子，第1個例子是基本數(shù)據(jù)類型，盡管說鯤鵬平臺支持的是LP64，x86平臺也支持LP64，但是實際上大家在某些細節(jié)定義上還是有區(qū)別的，雖然字符寬度，比如說對char來講都是8字節(jié)，但是x86 char是有符號類型的，對于鯤鵬平臺，是無符號類型的，這塊的改動就可以通過修改makefile，加一個參數(shù)，把默認的無符號的char定義成有符號的char，這樣就能保證C代碼邏輯，關于char操作上不會引入歧義。

第2類問題就是編譯器當中提供了多達數(shù)百個的宏定義，比如用GCC的話，可以在C，C++的軟件里面，源文件里面直接使用相應的宏定義，那么這個宏定義在編譯的時候，編譯器直接做環(huán)境變量的check，然后直接設置了相應的正確的值，跟host環(huán)境相關。這里指編譯和運行在同一款機器上，我們不講host和target相異的情況。這個時候對于相應的軟件，可能需要區(qū)分一下宏定義，比如說像x86 64，顯然一看就知道是支持x86的，不可能在鯤鵬平臺上運行，這時候就會建議用戶去修改用戶代碼，用預編譯的方式做軟件范圍的定義隔離，對于鯤鵬平臺，常用的關鍵字就是aarch64或者是Arm64，去做軟件邏輯的定義。

第3類問題就是匯編代碼的移植，這也是最頭疼的一塊，因為x86平臺有大概2100個匯編指令，鯤鵬平臺因為兼容Arm64，有1000~1100個匯編指令，加起來有3000多條，如果想把它分清楚，是非常痛苦的。Intel的相應指令集的手冊有4000多頁，Arm相關指令集的手冊有7000多頁，純英文的文檔大家讀起來肯定會崩潰的，所以匯編代碼的移植，是一個難點。

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

在x86的平臺上Intrisic總數(shù)將近7000個，在鯤鵬上就差的比較多，遠遠少于這個數(shù)，為什么？這是因為在x86平臺上它支持的指令集比較多，經(jīng)過二三十年的演進，有MMX的指令集，有SSE的指令集，還有AVX，AVX也分了128比特、256、512比特的三種。每一種它對應的Intrisic非常的多，所以移植的數(shù)量非常大。在這個里面可以找到一些，比如說對于128比特的操作進行一些對應，可以做一些替換。

針對上面提出的這些問題，我們提供了幾個工具：分析掃描工具，代碼遷移工具、性能分析工具。

比如說這里優(yōu)化了glibc基礎運行環(huán)境，優(yōu)化的壓縮、加密、加解密，包括數(shù)學計算這樣一些開源的或者是三方的組件，優(yōu)化了IPP信號處理的一些程序功能提升，就是用軟硬結合的方式極大提升了性能。這里面大致分析的一個流程，在分析掃描里面，把用戶的軟件上傳到工具環(huán)境下，工具環(huán)境就會分析用戶X86平臺上軟件的安裝包，比如說RPM包還有一些JAR、Java類的程序，包括壓縮包，會去掃描識別里面軟件包內部以及軟件安裝路徑內，包括壓縮包內部集成的，比如說SO文件、二進制文件，去檢驗是否在鯤鵬平臺上不同的操作系統(tǒng)上是否支持，反饋用戶一致性的分析報告，逐個告訴用戶SO是否兼容，不兼容的話怎么去處理？我們會提供鏈接，是源碼級的鏈接，或者是提供移植文檔方式書的這種鏈接，都會在報告里提供出來。

這個工具提供了兩種工作方式，一種是通過命令行的方式，這種形式通過參數(shù)輸入，一種是通過外部方式，在做了安裝包的依賴性分析以及源碼的掃描之后，會給用戶產生一個移植分析指導的報告，這個報告提供CSV的格式或者是HTML的格式，用戶可以去下載，里面會詳細羅列出哪些依賴庫，哪些二級制文件需要移植，然后哪些C，C++以及匯編代碼，需要移植規(guī)模有多大？會給用戶呈現(xiàn)一個移植的工作量，比如以每月為單位提供一個工作量。

計算標準，用戶是可以自己輸入的，如果說你的編碼能力強，那么你一個月C,C++代碼，可以完成800行，匯編代碼你可以完成600行，對吧？如果你的移植能力有限，有的編碼能力有限，技術成本有限，那么你可以設置成比如C,C++代碼一個月300行，匯編代碼100行，它會根據(jù)不同的標準，計算出移植工作量，做工程技術上的第1步，第1步信息掌握。

這里就列出了我們主要的功能，前面我已經(jīng)基本講述過，SO文件的檢查，構建工程的檢查、源文件的檢查，評估一致性，然后進行工作量評估，兩種方式：外部方式和命令行方式。

通過這個工具，就可以拿到軟件移植工程量的第1手資料，然后決定是否移植。當決定移植之后，就可以用代碼遷移工具去做進一步的分析，代碼移植工具主要是分析用戶的源代碼，它著重分析的是makefile，C，C++的源碼，就包括我們這里的編譯器提供的宏定義，然后用戶自定義宏，還有builtin函數(shù)、Intrisic、匯編代碼，我們分析完這些內容后會提供一個詳盡的移植指導，這里面就包含makefile怎么修改？C，C++代碼怎么修改？匯編代碼怎么修改？

這一頁就列出了代碼移植工具的大致工作流程，同樣我們也是外部方式和命令行方式兩種方式，方便用戶做選擇。我們分析用戶的源碼構建工程，還有構建工程配置文件、C，CC+的源碼和匯編源碼，然后給出移植指導，對于源碼的變化，我們會提供對比的方式顯示，像這里舉的例子就是左邊第1點是我們要改哪些文件，修改文件列表，第2類就是我們源文件是什么樣子，第3類就是建議修改成什么樣子？

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

前面已經(jīng)講了如何去做軟件依賴性的分析，通過華為開發(fā)套件去做軟件依賴性的分析，以及做C,C++的移植，在完成移植之后，會在生產環(huán)境上去跑這個軟件，這個時候會去做性能分析，我們提供了性能分析工具，這個工具主要是幫助用戶去做軟件性能定位，比如說有性能瓶頸或者想繼續(xù)優(yōu)化，我們提供了一些手段，這里對于這個工具我們可以幫助用戶去分析處理器相關指標，以及看到調度的一些信息，包括外設的信息、CPU、磁盤，甚至網(wǎng)卡、短期性的數(shù)據(jù)，去幫助用戶分析C，C++或者是Java程序這樣一個性能指標。

Java類不是說把JVM當成一個進程，我們是看到JVM內部的，還是有一定作用的。把這些數(shù)據(jù)統(tǒng)統(tǒng)的分析起來，然后通過自己定義的數(shù)學模型進行分析，去看到用戶的軟件性能瓶頸，比如說是資源競爭的問題或者是調度的問題，甚至比如說有一些bug導致了一些次循環(huán)等，我們提供了多種的方式來呈現(xiàn)這樣一個結果。比如常用的火焰圖的方式，能夠比較直觀幫助用戶去看自己的軟件里有沒有性質上的問題。

這個是羅列的目前性能分析工具能夠提供的性能指標，比如說硬件器件相關的，CPU、內存、磁盤、網(wǎng)卡、系統(tǒng)級的，我們也能看線系統(tǒng)調度比如說進程、線程，還有彼此之間的切換，或者是資源的爭搶，鎖一些關鍵變量的性能分析先行指標，我們也提供了一個基于火焰圖、基于代碼邏輯的深層次檢查，能夠提出用戶代碼的真正的開銷，大的地方在哪里，對應的代碼對應到源碼。

通過這樣的手段，就能幫助開發(fā)者比較快的定位自己的軟件，編譯型軟件的瓶頸。當定位到軟件瓶頸的時候，我們會提供一些附加的能力，比如說這里就提供加一個叫加速庫，軟硬結合的加速庫幫助用戶去優(yōu)化代碼。

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

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

當然了，你要使用我們提供的一些API的話，要遵循我們提供的用戶手冊，修改源碼，比如說可能原來掉的一些是軟件的這樣一些函數(shù)，或者是三方組建的API，要用加速器的話，就需要根據(jù)API修改相應的代碼邏輯，但這個代碼邏輯只是存在于API層面。

這里舉個例子，比如說集成了一個叫RSA的加速的引擎，是用來計算加密的，我們支持1024~4096，4種：1024 2048 3072 4096，4種密鑰長度。在加速器引擎里面，是通過一個用戶態(tài)的來lib去做隔離，對上去隔離用戶的，比如說開源的第三方軟件，比如說OpenSSL的的API，去對接OpenSSL API也可以把API暴露出來，直接給用戶的APP去使用，在lib下層的就是IC引擎的相應的驅動，用戶可以完全不用知道下面細節(jié)是如何實現(xiàn)的，只要正確調用鯤鵬RSA的提供的用戶lib，就可以去使用加速器的硬件計算能力，極大的加快了RSA的計算。

RSA計算如果用CPU算的話，是相當費時費力的。比如像x86的一個中高端的CPU，它每秒鐘只能執(zhí)行720次左右RSA2048的計算。但是你要用到了鯤鵬920提供的RSA計算引擎的話，計算量將是大幅度的提升，也就是說，可以把原本用來計算RSA的這些CPU完全釋放出來，跑其他的業(yè)務！在一個芯片內完成這項業(yè)務，對用戶來講就會提供另外一個選擇，不需要去買某些PCIE的插卡，直接去用軟件的方式來提升軟件性能，達到一個比較簡單的提升性能的方式。這是我們舉的一個例子，在移植工具里面，都會去通過軟件移植的這些能力去提供給開發(fā)者直接使用。

這是幾個工具組件的發(fā)布策略，我們目前停留在中間這一列，我們完成了多OS的適配，比如說支持CentOS7.4、7.5、7.6、7.7，支持中標麒麟等，支持了像SuSE這樣的操作系統(tǒng)，盡可能的去覆蓋常用的操作系統(tǒng)的類型，我們也支持了GCC的多個版本，從4.8.5一直支持到目前為止至少8.3，后續(xù)會支持到9點幾的版本，一直往上支持上去，幫助客戶盡可能的簡化重復勞動，我們還支持make構建工具，支持CMake構建工具

支持C，C++的代碼移植，也支持匯編代碼的識別，前面說了，從匯編指令的角度來講，從Intrisic的數(shù)量來講，這個量非常的大，而且也很有技術挑戰(zhàn)的，就是匯編語言的替換，所以這塊我們會逐步完善。對于加速這一塊，我們提供一些Intrisic的替換，比如說AVX或者SSE。

我們也優(yōu)化了一些常用的加速的三方的組件，像z-lib的加速或者stapi的加速，還有scan這種字符掃描的加速，用鯤鵬的指令去進行優(yōu)化，進行性能提升，取得了比較可觀的一個性能改變都是50%，一倍，甚至更多的3，4倍的性能提升，加速的效果還是挺明顯的。這樣也能讓用戶的軟件應用跑的又快又好。

如何去獲取這幾個工具，可以去鯤鵬社區(qū)去下載相應的軟件，

對于加速庫軟件，這里的策略是主要采取開源的策略，比如說像一些壓縮算法，壓縮引擎的，包括這些軟件組件，都是把相應的patch推動到社區(qū)。對于硬件加速引擎，是直接可以從華為的鯤鵬社區(qū)上去下載，然后去安裝使用，取用起來很方便。

鯤鵬社區(qū)是華為重點建設的和開發(fā)者溝通互動的橋梁。在社區(qū)里，可以下載到數(shù)百份的軟件移植指導以及相應的軟件調優(yōu)的經(jīng)驗，可以在這里面和其他的開發(fā)者做互動，做技術上進一步的探討。很多新的技術資料、技術文檔，包括一些白皮書，一些產品設計方案都會在社區(qū)里陸續(xù)發(fā)布，不同的開發(fā)者都能得到一些不同的信息。

隨著鯤鵬計算平臺的壯大，應用越來越多，需要大量的開發(fā)者去投入到平臺的生態(tài)建設里面來。所以華為在這里推出了這種線上認證培訓一系列的技能提升的活動，包括在線課程，云端的實驗室，線上認證和線下培訓，希望大家能夠積極參與，來共同構建華為鯤鵬的生態(tài)軟件生態(tài)。

好，這就到最后一個提問互動環(huán)節(jié)了。線上的開發(fā)者有什么問題嗎？我們可以交流一下。

第1個問題是王涵，他這個問題是軟件移植是基于同樣的操作系統(tǒng)移植嗎？

我們的移植分析工具不是依賴于操作系統(tǒng)的，也就是說我們軟件可以跑在不同的操作系統(tǒng)上，例如，最終的軟件移植可能是移植在一個Ubuntu上，甚至說一個中標麒麟上。其實對于軟件移植人員來講，重點要關注的就是軟件運行依賴庫或者是安裝依賴庫的一個兼容性問題，就是積累一個兼容性清單。

第2個問題，從x86移植到鯤鵬，會不會導致性能急劇下降？

要看應用的類型。如果你是一個純粹的C,C++做一些通用計算的話，那么我能說是不會，但是如果說你C,C++里面非常高級的，你用了一些底層的匯編，如果用到了一些x86所獨有的，比如說AVX做一些向量化計算，或者是做一些這種高并發(fā)的計算，我不得不坦率的告訴你，性能軟件，因為AVX指令或者是不管無論是256比特大概是512比特，那么在鯤鵬920平臺上現(xiàn)在是沒有對應，但是以后會有對應。這是一個長期的演進的計劃和過程，如果你要用到這些AVX指令，那么我們是有性能差異的。

第3個問題，鯤鵬與手機處理器都是基于精簡指令集，能否認為可將手機一起底層的功能移植到鯤鵬平臺上？

這個是我們現(xiàn)在常說的所謂的端邊云融合，實際上做手機端開發(fā)，我們可能更多的是基于安卓的系統(tǒng)，然后做一些用一些Java類的語言，然后我們的應用可能是編譯成字節(jié)碼跑的JVM上。

從這個角度來講，如果說你單純從語言，我可能說差異并不大，在鯤鵬平臺上你可以方便裝一個安卓模擬器，通過這種方式，我們也提供這樣一個解決方案，讓你可以跑一個云手機，在官方平臺上看云手機，跑得非常的高效，所以從這個角度來講，我們提供了一套解決方案，沒有任何問題。

第4個問題，Java代碼如何移植？

這個問題在前面的膠片上我們已經(jīng)看了，因為Java屬于這種字節(jié)碼運行的，那么于強依賴于他的runtime環(huán)境，那么在我們華為鯤鵬平臺上，我們是完美支持OpenJDK的，所以你用Java，代碼語言是沒有問題的。但是如果說Java里面非常高級的，你又嵌套了一些C的一些API，那么請把C單獨的源碼拿出來做一些一致性的檢查。

第5個問題，目前提供什么移植工具？

Java剛才說的，我們在這個工具里面不去做涵蓋檢查，除非你Java，或者是像類似于這種Python，你用到了一些C編譯成的SO文件用到一些C提供的API，我們是要檢查。

主持人：希望大家多多關注我們的鯤鵬社區(qū)，今天老師主講的內容我們已經(jīng)上傳到了鯤鵬社區(qū)，大家可以對資料進行一個下載，再進行一些學習都可以的，因為鯤鵬社區(qū)，它匯聚了我們鯤鵬的最新的一些知識問答，也匯聚了一批我們行業(yè)的專家，大家有什么問題的話都可以在鯤鵬社區(qū)上進行一個留言，我們的專家會進行一個及時的回復，相關的技術包、安裝包以及相關的一些學習資料上面也比較齊全，如果關注鯤鵬的話，可以到上面去進行一個獲取。

鯤鵬

版權聲明：本文內容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內刪除侵權內容。

版權聲明：本文內容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內刪除侵權內容。