最近小編收到一個客戶模型，其中使用了一個叫做PRelu的算子，想要運行在RT170上。本來小編是信心滿滿的答應客戶說：速度上放心，我們這主頻1GHz的CPU絕對沒問題，包您滿意。沒想到跑分結果出爐直接給了小編沉重一擊。

直接依賴TFLm推理引擎的默認實現，PRelu算子的運行時間竟然高達188ms。于是小編本著工程師本有的探索精神，決定迎難而上，徹底將它優化一下。

所謂知己知彼，百戰不殆，首先我們來看一下什么叫做PRelu算子。

PRelu，看著好像特別的高大上，我們將其拆分來看，將其分成P+Relu，是不是瞬間就覺得熟悉了。沒錯，他實際上就是我們常用的Relu算子的變種。其中，P，是Parametric的縮寫，因此，所謂PRelu就是帶參數的Relu，只不過，這里的參數實際上是可以被訓練的，而非一個固定值。那么PRelu到底長什么樣呢？小編馬上揭開它的神秘面紗：

上圖就是PRelu的廬山真面目。i 表示不同的通道。alpha的個數是跟著通道走的，不過好消息是，各個通道之間參數是可以共享的，這樣看著清爽了不少。特殊的，如果我們配置H和W通道共享參數，那么參數alpha就變成了類似于bias的功能，逐通道共享一個參數，因此，其shape = (1, 1, c);

為了對客戶負責，外加能夠更加方便地進行模型測試，小編首先收利用Keras手動構建一個具有PRelu算子的小巧模型。正所謂小巧而又不失優雅，我們構建模型如下所示：

這個小巧的模型本身具備了我們所常見的多個算子，例如Conv2D，MaxPool2D，FullyConnect等，因此作為PRelu算子的測試模型也不至于顯得過于寒酸。

接下來和大家聊聊小編的調試經歷：

第一步，就是要對TFLm的源碼進行分析，了解為何其運行緩慢。

PRelu算子實際上就是一個進階版本的Relu算子，根據其輸入值的正負分別進行計算，當輸入為正是，就等于本身；當輸入為負時，將結果乘以一個系數alpha。看似非常簡單的計算方式，為啥TFLm的參考實現能算的這么慢呢？口說無憑，show me the code：

if (input_value >= 0) { output_value = MultiplyByQuantizedMultiplier( input_value, params.output_multiplier_1, params.output_shift_1); } else { auto alpha_index = SubscriptToIndex(desc2, b, y, x, c); const int32_t alpha_value = params.alpha_offset + alpha_data[alpha_index]; output_value = MultiplyByQuantizedMultiplier( input_value * alpha_value, params.output_multiplier_2, params.output_shift_2); }

看到這里，恰似風平浪靜，的確是按照我們分析的那樣，按照輸入值的正負進行計算。但是...細心的讀友可能發現了問題：

1） 這里的alpha_data有個index，沒錯，這就是運行慢的第一個原因。剛才說過，PRelu中的alpha參數是和通道數相關的，也就是說每個通道都可以擁有自己的值，而且各通道之間還可以共享，因此并不能直接順序訪問，而是需要根據index進行查找。

2） 這里多了一個叫做MultiplyByQuantizedMultiplier的函數，為啥不直接計算？這是另一個原因。熟悉深度學習的伙伴們一定知道，MCU平臺常被稱作：資源受限平臺，這里的受限不僅體現在算力上，還有內存空間上，相較于MPU那種動輒幾個G的DDR的龐然大物，MCU上的內存資源也是捉襟見肘。

想要將我們訓練的模型部署運行在MCU上，第一步就是對模型進行量化操作，將浮點類型的模型轉換為int8類型的模型，這樣直接縮小到之前的1/4。同時由于量化后的模型采用int8表示，同時能夠借助于優化后的運行庫進行加速。

這樣一來，為了既想要使用int8模型帶來的遍歷，又保證模型精度，就需要對輸出結果進行反量化表示，已達到使用int8類型結果表達浮點數的效果。因此，就需要調用類似MultiplyByQuantizedMultiplier這樣的函數進行反量化處理。

基于以上兩點，我們也就發現了算法本身所存在的慢速隱患，接下來的優化操作也正是基于此展開。

下一篇會繼續介紹通過內存外加反量化函數的改造提升算法執行速度。