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

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

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

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

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

圖 1.放大跟蹤視圖來檢查跟蹤數據。

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

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

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

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

圖 3. 時間信息視圖。

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

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

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

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

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

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

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

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

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

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

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

自定義間隔

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

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

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

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

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