I am trying to make my image processing program faster.
So, i changed my scalar code into vectorized code.
for understanding, the purpose of program is" read right(4) and left(4) total 8 pixel of target pixel from input buffer
then compare them with target pixel and calculate weight, then write result into other buffer.
so, i coded in this style
Read 16 pixel(Read_in) , then 8 pixel of this will be 8 target pixel(center).
After that, split pixels into 4(letf)&4(right) . and store them into vector variables.
float8 splited1=(float8)(Readin.s0123,Readin.s5678)
float8 splited2=(float8)(Readin.s1234,Readin.s6789) and so on...
then compare splited1~n with center by using vector operators and calculate weight.
Fianally, store result data(float8) into buffer.
In mali optimization guide, vectorized code is faster than scalar code.
but, in my case, vectorized code is slower than scalar code about 3 times.
why this thing is happened? is it caused by too many elements?
My device is samssung galaxy s6 equipped with mali t760-mp8
First of all, I am not familiar with Mali so my comments are more on the general aspects of vector vs. scalar code performance. My observation from the description that you provided are:
1. In order to get the most benefit from vector processing your data need to be stored in memory in vector format otherwise the overhead from packing/unpacking data (vector <--> scalar) might eliminate any benefit from using vector processing. Your pseudo code implies that you are loading 16 pixels individually from memory then you pack them into vector variables which results in unnecessary overhead. You need to check if you can store the 16 pixels contiguously in memory so they can be loaded and stored with a single load/store instruction.
2. Some ALU operations like multiplication/addition/etc. generate wide result and requires additional steps to truncate the value for it to be stored/packed into a "vector" variable. Unless the processor/co-processor supports truncated result storage then your program will end using extra instructions.
The best approach is to look at the assembly code to determine where the overhead is coming from. I also suggest that you post the actual code (C/assembly) in order to get more significant feedback. Good luck.
If you data is all fp32 floats the I would guess you are hitting issues around register availability - if you are reading 8 fp32 values for input and needing 8 fp32 values for output then that is a huge amount of data to have hanging about in registers. See Anton's blog here for some basic info on register limits which you probably want to stick to:
ARM Mali Compute Architecture Fundamentals
Also remember that GPUs have finite memory bandwidth - 8 cores all making vec8 fp32 accesses are likely to end up memory limited anyway, depending how much maths you are doing per access. Look at whether you really need to use fp32 inputs - fp16 is much faster (half the bandwidth, almost twice the arithmetic performance in Mali's maths units) and normally fine for processing color values (which end up as 8-bit int unorm before being displayed anyway), and many algorithms can operate on int8 luminance values (using int16 or fp16 for temporary precision inside the core if needed, storing an int8 result) which halves the memory bandwidth again.
... but without seeing your exact code it's going to be hard to provide specific advice.
HTH, Pete
thank you for comment, i changed my code with 128bit-wide simd operations.
then, it gets faster a little bit.