Hello.
I just have attempt, writing serious application, considering language
(C), tookit (gtk3, cairo, pango, etc) and that it is audio app. Besides
that many audio things use simple "float" for audio data, i noticed
some posts, where tension towards integer math appeared. While it is
not my case (my app is jack-based, and audio data have FP type
everywhere), i slightly distracted from audio side.
My app for now is spectrum analyzer, which later should evolve into
couple of spectral editing helper utilities (more exactly to generate
spectrogram and apply changes either by resynth or by filtering with
diff spectrogram).
I distracted to experiments with graphics post-processing for instant
spectrum view rendering. Due to cairo nature, color data in cairo image
surface may be at best argb32, rgb24 and rgb30 (for now i implemented
uspport only for first two). As result post-processing is all done in
integer mode. I can understand this, as i noticed that channel orders
in memory depends on endianness, what points that cairo relies more on
masks and bitshifts than for byte value arrays where is possible.
I decided to look in debugger for how gcc does optimize these ops.
Noticed following. Below is code chunk from kdbg with some asm blocks
expanded. There is only one line, where i tried to use floating point
ops, just for comparison (plus some context for better understanding).
for (int l = 0; l < 3; l++)
for (int c = 0; c < 3; c++)
{
unsigned char
* p = bpix[l][c];
col[0] += p[0] ,
0x5b27 movzbl 0x60(%rsp),%esi
col[1] += p[1] ,
0x5a34 movzbl 0x65(%rsp),%eax
col[2] += p[2] ,
0x5a42 movzbl 0x62(%rsp),%edx
col[3] += p[3];
0x5a47 movzbl 0x67(%rsp),%esi
0x5a4c mov 0x10(%rsp),%rbp
}
col[0] /= 9.0, col[1] /= 9.0, col[2] /= 9.0, col[3] /= 9.0;
0x5a39 pxor %xmm0,%xmm0
op[0] += col[0] ,
0x5b8d add %sil,0x0(%rbp)
op[1] += col[1] ,
0x5b94 add %cl,0x1(%rbp)
op[2] += col[2] ,
0x5b97 add %dl,0x2(%rbp)
op[3] += col[3];
0x5b91 add %al,0x3(%rbp)
for (int l = 0; l < 3; l++)
ip[l] += 3;
op += ch_n;
}
Notice, how line, containing chain of divisions, is compiled to single
sse operation. What is interesting, this is only asm line, involving
xmm or imm - i can't find anything else like mov, involving these
registers.
With division to integer 9 - it is still one line, but no xmm is
involved.
col[0] += p[0] ,
0x5b17 movzbl 0x64(%rsp),%eax
col[1] += p[1] ,
0x5a35 movzbl 0x65(%rsp),%eax
col[2] += p[2] ,
0x5a4a movzbl 0x7e(%rsp),%esi
col[3] += p[3];
0x5a4f movzbl 0x7f(%rsp),%ecx
}
col[0] /= 9, col[1] /= 9, col[2] /= 9, col[3] /= 9;
0x5a3a mov $0x38e38e39,%r8d
op[0] += col[0] ,
0x5b78 add %dl,0x0(%rbp)
op[1] += col[1] ,
0x5b3a add %dil,0x1(%rbp)
As for GCC opts, i used unusual combo "-march=native -O3 -g" in order
to get exhausing optimization, but still keep it readable for kdbg
disasm to get a look.
While searching for info about sse integer support, search pointed me
to wikipedia page about x86 instructions, where i found almost enough
instruction set - logical, add, sub and mul, signed and
unsigned, words and bytes (at least in SSE2 which according to
description enabled MMX set to use SSE registers, where integer support
was primary in MMX).
So, i'm in maze - why doesn't gcc involve such ops in integer mode?
Could it be possible, that what it did is better without SSE?
I'm about to eventually try more FP ops in this place but unsure, about
possible conversions, since source and dest are anyway cairo surfaces
with integer data.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
