絕大多數(shù)嵌入式 Linux 軟件開發(fā)人員編寫用戶空間應用程序。由于這些應用程序特定于某個領(lǐng)域并且非常復雜，因此應用程序開發(fā)人員需要一種簡單的機制來驗證其應用程序的功能并衡量性能。

跟蹤點是 LTTng 用戶空間跟蹤庫提供的特定于應用程序的檢測點，用于將用戶指定的數(shù)據(jù)捕獲為事件，它可實現(xiàn)此目的。跟蹤點可以通過兩種方式創(chuàng)建：第一種稱為 tracef，是一種非常簡單的方法，可將所有數(shù)據(jù)捕獲為單個事件。第二種允許開發(fā)人員創(chuàng)建自定義事件。雖然后一種機制需要編寫更多代碼，但它也為收集數(shù)據(jù)并將其顯示在 Tracealyzer 中提供了最大的靈活性。

我在這里使用了 tracef 方法，但請注意，這也會捕獲內(nèi)核跟蹤，原因有二。首先，包含內(nèi)核跟蹤通?？梢越忉層脩艨臻g事件的時間線。例如，如果我們應用程序中的兩個事件之間存在較長的延遲，則內(nèi)核事件應該可以顯示導致延遲的原因。其次，從 4.4.2 版開始，Tracealyzer 需要內(nèi)核跟蹤中的一些數(shù)據(jù)才能正確顯示 UST 事件，盡管它不需要是完整的內(nèi)核跟蹤。

Tracealyzer 還可以測量用戶空間應用程序的性能。此特定示例使用 Linux usleep 函數(shù)模擬需要一定時間的函數(shù)，在函數(shù)調(diào)用之前添加一個跟蹤點，并在之后添加另一個跟蹤點，以測量函數(shù)完成所需的時間。

在實際場景中，開發(fā)人員會確定應用程序中需要測量執(zhí)行時間的位置，并在那里添加 tracef 調(diào)用。例如，一個函數(shù)可能有多個實現(xiàn)候選，并且會檢查執(zhí)行時間以找到最快的算法?；蛘咛囟ê瘮?shù)可能很復雜，需要對執(zhí)行進行表征。編譯上述應用程序、在目標上啟動 LTTng 會話、捕獲和下載生成的跟蹤數(shù)據(jù)后，在 Tracealyzer 中檢查跟蹤數(shù)據(jù)。

圖 1.放大跟蹤視圖來檢查跟蹤數(shù)據(jù)。

usleep 函數(shù)調(diào)用的執(zhí)行時間可以定義為每對“開始”和“停止”事件之間的時間。在 Tracealyzer 中執(zhí)行此操作的最佳方法是為自定義用戶事件創(chuàng)建間隔。

保存自定義間隔定義后，它將出現(xiàn)在間隔和狀態(tài)機窗口中，并且 Tracealyzer 會在跟蹤視圖中突出顯示它，從而允許生成間隔時序圖。

圖 2. 要繪制間隔時間圖，請在視圖菜單中選擇設置...。

毫不奇怪，所有間隔執(zhí)行似乎都持續(xù)了大約 25 毫秒，但單擊其中一個數(shù)據(jù)點就會顯示有關(guān)該間隔的有價值的時間信息。

圖 3. 時間信息視圖。

Tracealyzer 顯示每個間隔長度的統(tǒng)計數(shù)據(jù)，這與相關(guān)函數(shù)的執(zhí)行時間相對應。第二個框顯示我們感興趣的函數(shù)執(zhí)行間隔時間的統(tǒng)計數(shù)據(jù)，例如停止事件和下一個啟動事件之間的時間。第三個框顯示每個間隔發(fā)生的頻率，即從啟動到下一個啟動測量的時間。

區(qū)間圖可用于識別感興趣的函數(shù)的任何異常時間，并且選擇詳細信息視圖中的信息可用于收集高級時間統(tǒng)計數(shù)據(jù)。

大多數(shù)嵌入式軟件開發(fā)人員將在基于 Linux 的嵌入式系統(tǒng)上開發(fā)用戶空間應用程序。Tracealyzer 與 LTTng 跟蹤點結(jié)合使用，可以成為一種非常有用的工具，用于確定應用程序的運行情況、識別任何異常行為并提供高級時序統(tǒng)計數(shù)據(jù)。然后，它可用于進一步排除任何時序問題并提高應用程序的性能。

了解編譯器選項對性能的影響

編譯器選項會影響最無害的計算的性能，即使是基本的正弦函數(shù)也是如此。使用 Tracealyzer 可以幫助開發(fā)人員了解這些選項如何影響執(zhí)行更復雜計算的用戶空間應用程序的性能。

我已經(jīng)能夠通過計算頻率為 100 Hz、采樣率為 1 kHz 的正弦波的 1000 個點來證明這一點。通過使用“標準”編譯器選項，我們在 Tracealyzer 中查看系統(tǒng)時間時會看到跟蹤中的不連續(xù)性。在將每個樣本打印到文件的代碼片段中添加 printf 調(diào)用不會顯示不連續(xù)性，因為這只是將值打印到文件中，沒有任何時間概念。但是，當將計算出的值輸出到跟蹤文件時，系統(tǒng)時間包含在每個跟蹤值中。

更改編譯器中的選項有助于減少這種不連續(xù)性。標準 CPU(例如 Arm 處理器)的架構(gòu)旨在高效執(zhí)行整數(shù)運算而不是浮點運算，因此編譯器將浮點指令轉(zhuǎn)換為一系列基于整數(shù)的指令。這會導致 CPU 執(zhí)行的指令數(shù)量大幅增加，系統(tǒng)中的另一個任務有更大的機會搶占正弦波計算。Tracealyzer 中的跟蹤視圖證實了這一點，其中負責正弦波計算的進程確實被其他進程搶占，在最壞的情況下暫停 900 微秒。

圖 4. 使用整數(shù)處理浮點應用程序的不連續(xù)性。

為編譯器指定“-mfloat-abi=hard”選項會告訴它使用一組專門為浮點操作設計的指令。然而，這并沒有產(chǎn)生任何真正的差異，因為仍然存在不連續(xù)，跡線視圖顯示正弦波過程暫停相同的時間-900 ms。

這是因為這些浮點指令有特定的擴展，可以在處理器本身上有一個單獨的、高度優(yōu)化的浮點單元(FPU)。這需要為編譯器指定“fpu”選項?！?mfloat-abi=hard”選項允許編譯器自由地選擇適當?shù)臄U展。

添加“-mfpu=neon”選項指示編譯器為該特定 FPU (NEON) 啟用一組特定的擴展。由于大多數(shù)浮點計算都在單獨的協(xié)處理器上運行，因此其他進程幾乎沒有機會搶占正弦波生成，從而導致不連續(xù)性大大減小。

自定義間隔

Tracealyzer 還可以使用自定義間隔直觀顯示每次正弦計算所需的時間。無需使用帶有計算出的正弦值的 tracef 調(diào)用，跟蹤“開始”和“停止”用戶事件即可跟蹤計算。

在不使用“float_abi=hard”編譯器選項的情況下編譯和運行應用程序表明，雖然函數(shù)的大部分執(zhí)行時間大約需要幾十微秒，但也存在一些異常值。在一個案例中，該函數(shù)執(zhí)行時間約為 200 微秒，而在另一案例中，執(zhí)行時間約為 1.05 毫秒!

添加硬 ABI 選項(但不是 NEON 擴展)顯示 100-200 微秒范圍內(nèi)的異常值和一次幾乎花費 1.1 毫秒的調(diào)用。

打開在應用程序編譯為使用硬 ABI 和 NEON 擴展時收集的跟蹤信息，顯示最長執(zhí)行時間現(xiàn)在略少于 240 微秒。這突出顯示了使用 NEON 擴展可以顯著減少計算點之間的最差延遲。

使用 LTTng 庫和 Tracealyzer，開發(fā)人員可以看到某些編譯器選項如何影響執(zhí)行浮點計算的用戶空間應用程序的性能。通常，這種分析是在事后進行的，當應用程序完成但觀察到的性能被視為不可接受時，這需要大量時間。我們已經(jīng)能夠證明，通過在開發(fā)階段使用 Tracealyzer 等可視化跟蹤診斷工具來驗證軟件時序，可以更早地發(fā)現(xiàn)和解決問題。從經(jīng)驗豐富的開發(fā)人員的角度來看，這可以避免隱藏的錯誤，并在項目后期節(jié)省時間和成本。