上一篇小編和大家分享了在運行客戶的一個模型時遇到了一個PRelu算子,在利用TFLm自帶的PRelu參考實現(xiàn)的代碼,其中PRelu竟然拋出了188ms的天文數(shù)字...因此小編開始準備PRelu算子的優(yōu)化工作。
分析了參考實現(xiàn)后,發(fā)現(xiàn)了兩個優(yōu)化方向,其一是PRelu中alpha參數(shù)的特殊性所帶來的內存訪問優(yōu)化;以及量化模型所帶來的反量化問題。
本期小編就和大家一起來看下對于反量化問題的優(yōu)化細節(jié)。在開始前,再來回顧一下小編所特殊定制的模型:
這是一個具有5個節(jié)點的小巧的深度神經(jīng)網(wǎng)絡,輸入時128*128*3,模型推理時間(采用Keil IDE,ofast優(yōu)化):
跳過PRelu算子,模型推理時間:
這樣我們就可以得出PRelu算子的執(zhí)行時間為13ms,接下來就將以此為基礎進行算法優(yōu)化,TFLm算法實現(xiàn):
output_value = MultiplyByQuantizedMultiplier(
input_value, params.output_multiplier_1, params.output_shift_1);
output_value = MultiplyByQuantizedMultiplier(
input_value * alpha_value, params.output_multiplier_2, params.output_shift_2);
上一篇小編給大家解釋了為何需要進行反量化操作以及其必要性。所謂反量化操作的本質,就是要用int8類型的中間結果來準確表達浮點結果。那么具體來說需要怎么操作呢?下面就是嚴謹?shù)耐乒江h(huán)節(jié),請讀友們不要眨眼:
首先是整數(shù)環(huán)節(jié),我們假設輸入為input, 輸出為output,參數(shù)alpha;其參數(shù)類型均為int8。而想要將其反量化為浮點數(shù),需要為其設定對應的量化參數(shù),分別為scale以及zero_point。這樣一來,變量的浮點數(shù)表示即為:
v_fp=scale* (v_i8+zero_point)
為了分析簡單,我們假設zero_point為0,那么上式可被簡化為,當然實際計算式,只需要將輸入值提前加上其zero_point再進行操作即可:
v_fp=scale* v_i8
接下來我們根據(jù)輸入數(shù)據(jù)的符號進行區(qū)分,當輸入為正時,其輸出結果為,
scale_o* output=scale_i* v_i8
output=scale_i / scale_0* v_i8
這樣我們就可以根據(jù)輸入直接獲取int8類型的輸出結果。
當輸入為負時:
scale_o* output=(scale_a*alpha)*(scale_i* v_i8)
output=((scale_a* scale_i)/scale_0)* 〖alpha*v〗_i8)
這樣也就獲得了相對應的負數(shù)輸入所對應的輸出結果。不過,征程還沒有結束,TFLm的參考實現(xiàn)會將這兩組浮點數(shù)代表的scale參數(shù)轉換為指數(shù)形式,并以mul+shift的形式保存為:正數(shù)output_multipiler_1和output_shift_1, 負數(shù)output_multipiler_2和output_shift_2。
知道了結果是如何進行反量化操作的,回過頭我們看看TFLm的實現(xiàn):
inline std::int16_t SaturatingRoundingDoublingHighMul(std::int16_t a,
std::int16_t b) {
bool overflow = a == b && a == std::numeric_limits<std::int16_t>::min();
std::int32_t a_32(a);
std::int32_t b_32(b);
std::int32_t ab_32 = a_32 * b_32;
std::int16_t nudge = ab_32 >= 0 ? (1 << 14) : (1 - (1 << 14));
std::int16_t ab_x2_high16 =
static_cast<std::int16_t>((ab_32 + nudge) / (1 << 15));
return overflow ? std::numeric_limits<std::int16_t>::max() : ab_x2_high16;
}
inline int32_t MultiplyByQuantizedMultiplier(int32_t x,
int32_t quantized_multiplier,
int shift) {
using gemmlowp::RoundingDivideByPOT;
using gemmlowp::SaturatingRoundingDoublingHighMul;
int left_shift = shift > 0 ? shift : 0;
int right_shift = shift > 0 ? 0 : -shift;
return RoundingDivideByPOT(SaturatingRoundingDoublingHighMul(
x * (1 << left_shift), quantized_multiplier),
right_shift);
}
首先arm的cmsis-nn庫是兼容這種量化方式的,那么他也一定有一個這樣的實現(xiàn),功夫不負有心人,這個函數(shù)叫做arm_nn_requantize,直接替換MultiplyByQuantizedMultiplier函數(shù)讓我們先看一下速度:
嗯,不錯,有效果,44ms->42ms,相當于PRelu算子執(zhí)行速度從13ms->11ms; 還可以,無痛漲點。翻看arm_nn_requantize函數(shù),其中也不乏一些手撕浮點數(shù)的神秘操作??紤]到我們的RT1170本身兼?zhèn)湟粋€FPU單元,為啥不直接用浮點數(shù)計算呢?這次我們不對scale參數(shù)進行指數(shù)化轉換,而是直接將其作為浮點數(shù)參與運算,公式就是上面我們推導的:
// init the float mul, shift
float real_multiplier_1 = (input->params.scale) / (output->params.scale);
float real_multiplier_2 = (input->params.scale) * (alpha->params.scale) / (output->params.scale);
計算方式重新定義為:
output_value = MultiplyByQuantizedMultiplierFP32(
input_value, multiplier_pos);
static inline int32_t MultiplyByQuantizedMultiplierFP32(int32_t x, float mul){
return roundf(x * mul);
是不是看著非常清爽?讓我們看下時間:
額。。。有點尷尬,竟然沒有長點,而且和TFLm的原始實現(xiàn)速度一樣。小編才提到的內存優(yōu)化不是還沒有上?浮點運算這邊還有小插曲,讓我們繼續(xù)前行:
首先讓我們先看下浮點操作再如何進行優(yōu)化,由于我們的代碼由于采用了Ofast優(yōu)化策略,因此代碼的可閱讀性變得很差。為了進行代碼優(yōu)化,小編需要特殊編寫一組浮點運算代碼以供優(yōu)化參考,因為我們最終實現(xiàn)的是一個int32數(shù)據(jù)與浮點數(shù)相乘:
static inline int32_t MultiplyByQuantizedMultiplierFP32(int32_t x, float mul){
return roundf(x * mul);
}
編寫代碼如下:
int32_t v1 = (float)SysTick->VAL;
float v2 = SysTick->VAL * 0.0001f;
int32_t v3 = (v1 * v2);
PRINTF("%d", v3);
其所生成的匯編代碼為:
int32_t v1 = (float)SysTick->VAL;
800040DC LDR R2, [R0]
800040DE STRD R2, R1, [SP]
800040E2 VLDR D0, [SP]
800040E8 VSUB.F64 D0, D0, D1
800040F0 VCVT.F32.F64 S0, D0
800040F8 VCVT.S32.F32 S0, S0
800040FE VMOV R0, S0
float v2 = SysTick->VAL * 0.0001f;
800040E6 LDR R0, [R0]
800040EC STRD R0, R1, [SP, #16]
800040F4 VLDR D2, [SP, #16]
80004102 VSUB.F64 D0, D2, D1
80004106 VLDR D2, =0x4330000080000000
80004110 VCVT.F32.F64 S0, D0
80004122 VMUL.F32 S0, S0, S4
int32_t v3 = (v1 * v2);
800040FC STR R1, [SP, #12]
8000410A EOR R0, R0, #0x80000000
8000410E STR R0, [SP, #8]
80004116 VLDR D1, [SP, #8]
8000411A VSUB.F64 D1, D1, D2
8000411E VLDR S4, =0x38D1B717
80004126 VCVT.F32.F64 S2, D1
8000412A VMUL.F32 S0, S2, S0
到這里,小伙伴們可能已經(jīng)看到了端倪,小編也特意為大家標紅了幾條匯編代碼。那小編就先拋出疑問:我們明明定義的浮點型, 咋還用上double類型了呢?相同的代碼用GCC編譯會是什么樣的呢?
int32_t v1 = (float)SysTick->VAL;
300030f2: mov.w r3, #3758153728 ; 0xe000e000
300030f6: vldr s15, [r3, #24]
71 float v2 = SysTick->VAL * 0.0001f;
300030fa: vldr s14, [r3, #24]
300030fe: vcvt.f32.u32 s14, s14
30003102: vldr s13, [pc, #92] ; 0x30003160 +148>
30003106: vmul.f32 s14, s14, s13
72 int32_t v3 = __builtin_roundf(v1 * v2);
3000310a: vcvt.f32.s32 s15, s15
3000310e: vmul.f32 s15, s15, s14
30003112: vrinta.f32 s15, s15
看似正常,沒有使用double類型寄存器;那問題出在哪呢?難道Keil對于浮點數(shù)的支持不太行?翻閱了一萬件資料之后,小編在編譯時使用一個叫做-ffp-mode = full的參數(shù),這個參數(shù)的意思是:
同時還有兩個參數(shù),是-fp-mode=fast和-fp-mode=std,簡單來講就是full會保證轉換精度,因此會出現(xiàn)使用double類型的情況。而fast可能會丟失一點精度,而std介于兩者之間。那么我們定義-fp-mode=std試試?
代碼如下:
int32_t v1 = (float)SysTick->VAL;
800040D4 VLDR S0, [R0]
800040E2 VCVT.F32.U32 S0, S0
float v2 = SysTick->VAL * 0.0001f;
800040D8 VLDR S2, [R0]
800040DC VCVT.F32.U32 S2, S2
800040E6 VMUL.F32 S2, S2, S4
int32_t v3 = (v1 * v2);
800040EA VRINTZ.F32 S0, S0
800040EE VMUL.F32 S0, S2, S0
嗯,優(yōu)雅,就是這么簡單。指令條數(shù)減少了很多啊,讓我們再來看看時間:
這樣一來就和arm提供的方式一致了,相比實現(xiàn)就清爽了很多。
接下來小編還有一個殺手锏,內存優(yōu)化,不過此處的內存優(yōu)化是有個前提,我們知道PRelu的alpha參數(shù)是按通道的,這里要做個特殊的假設,假設輸入維度為 h w c,而且alpha參數(shù)是按h w共享的,即只有最后一維參數(shù),維度為11 c:
if((alpha_shape.Dims(0) == 1) && (alpha_shape.Dims(1) == 1))
這樣我們就可以按c通道進行展開,并進行順序訪問;
其次,輸入數(shù)據(jù)為int8類型,原始實現(xiàn)方式中每次只取一個數(shù)據(jù)進行計算:
const int32_t input_value =
params.input_offset + input_data[input_index];
這樣編譯器會將起編譯為LDRB指令,即每次只獲取一個字節(jié)的數(shù)據(jù)。對此進行優(yōu)化,每次讀取4個字節(jié)的數(shù)據(jù),這樣可以編譯為LDR指令,并放置于寄存器中,減少訪存次數(shù):
uint32_t steps = alpha_shape.Dims(2);
uint32_t total_size = input_shape.Dims(0) * input_shape.Dims(1) * input_shape.Dims(2) * input_shape.Dims(3);
for(int value_index=0;value_index T *alpha = (T *)alpha_data;
// each 4, calc the time_tick
uint32_t inner_loop = steps >> 2;
int8_t *input_data_ptr = (int8_t*)input_data + value_index;
int8_t *output_data_ptr = (int8_t*)output_data + value_index;
while(inner_loop --){
int32_t input_data_32 = *((int32_t*)(input_data_ptr));
input_data_ptr += 4;
uint32_t count = 4;
while(count--){
int8_t input_data_8 = input_data_32 & 0xFF;
input_data_32 >>= 8;
。。。。
;value_index+=steps){>
這樣一來,就可以順序取數(shù)據(jù),并且每次讀取4個字節(jié),看下時間:
Nice!~
PRelu的時間變?yōu)?7ms – 31ms = 6ms。經(jīng)過兩步優(yōu)化,將PRelu的執(zhí)行時間降低了7ms。用客戶的模型測試一下,PRelu算子運行時間從之前的188ms降低到了51ms。Perfect!
不過,小編精益求精,還有一些微小的優(yōu)化空間,后續(xù)將會進一步優(yōu)化。
歡迎朋友們持續(xù)關注~
-
mcu
+關注
關注
146文章
17178瀏覽量
351680 -
NXP
+關注
關注
60文章
1281瀏覽量
184591 -
恩智浦
+關注
關注
14文章
5864瀏覽量
107734 -
函數(shù)
+關注
關注
3文章
4338瀏覽量
62749 -
算子
+關注
關注
0文章
16瀏覽量
7267
原文標題:PRelu算子調優(yōu)經(jīng)歷-函數(shù)優(yōu)化策略
文章出處:【微信號:NXP_SMART_HARDWARE,微信公眾號:恩智浦MCU加油站】歡迎添加關注!文章轉載請注明出處。
發(fā)布評論請先 登錄
相關推薦
評論