Remove all alternative sample conversion code using lrintf in pa_converters.c

[RossBencina]

This is code guarded by PA_USE_C99_LRINTF. Fixes #390.

[RossBencina]

@dmitrykos I am asking for your review just in case you might care about this change. If you don't care, just say so. See #390 for details.

[RossBencina]

I posted about this to the mailing list. Let's wait and see whether anyone responds there before merging this one.

[dmitrykos]

@RossBencina, sorry I noticed this thread only now. I am in favor to remove lrintf() taking into account your findings in #390 thread.

The best way would be to use a cast to integer type and modify the rounding mode to - truncate towards zero. It is fast and rounding mode can be set on all platforms (Windows, Apple, Linux).

[Be-ing]

There is a merge conflict now.

[RossBencina]

@dmitrykos cast to integer is unaffected by rounding mode. In fact, on x386 target cast to integer is slow because it always resets the rounding mode to truncate, then restores it, on newer architectures it probably uses some SSE that doesn't require setting the rounding mode. if used correctly lrintf should be faster than cast to integer -- that is a good reason to use it. But it needs to be done properly, then with benchmarks etc etc.

[dmitrykos]

@RossBencina, thank you for correcting me that a cast to integer is guaranteed to be in Round-Towards-Zero mode. Rounding mode though affects lrint so the change (removal of lrint) made the code portable and unaffected by the rounding mode which could be changed by a user.

I made small experiment and used Visual Studio 2019 (MSVC compiler) targeting Windows 10 (x86, x64).

#include <stdio.h>
#include <math.h>
#include <fenv.h>

int main()
{
	fesetround(FE_UPWARD);

	volatile float vf = 2.2f;

	volatile int vi0 = lrintf(vf);
	volatile int vi1 = (int)vf;

	printf("vi0=%d, vi1=%d", vi0, vi1);

	return 0;
}

The result is - vi0 = 3 when using lrintf and a cast to integer results in vi1 = 2, so it confirms that cast works as expected (Round-Towards-Zero mode) and lrintf is affected by the rounding mode.

Currently for x86 mode the MSVC compiler enforces the usage of SSE SIMD cvttss2si even if SSE is not explicitly specified in the compiler settings when application is targeting Windows 10:

x86:

volatile int vi1 = (int)vf;
00F61031  movss       xmm0,dword ptr [vf]  
00F61036  cvttss2si   eax,xmm0  
00F6103A  mov         dword ptr [vi0],eax  

x64:

volatile int vi1 = (int)vf;
00007FF7627016B4  movss       xmm0,dword ptr [vf]  
00007FF7627016BA  cvttss2si   eax,xmm0  
00007FF7627016BE  mov         dword ptr [vf],eax

In case of lrintf compiler is generating a function call and more instructions in x86 mode:

x86

volatile int vi0 = lrintf(vf);
00591018  movss       xmm0,dword ptr [vf]  
0059101D  movss       dword ptr [esp],xmm0  
00591022  call        dword ptr [__imp__lrintf (0592058h)]  
00591028  mov         dword ptr [ebp-8],eax  
0059102B  add         esp,4  

Shorter for x64 but still a function call:

x64:

volatile int vi0 = lrintf(vf);
00007FF62C8C169D  movss       xmm0,dword ptr [vf]  
00007FF62C8C16A3  call        qword ptr [__imp_lrintf (07FF62C8CA228h)]  
00007FF62C8C16A9  mov         dword ptr [rsp+38h],eax 

I also checked what GCC (MinGW.org GCC-6.3.0-1) is doing and the results are similar for a cast to integer when complier is using SSE SIMD.

x86 + SSE:

movss	20(%esp), %xmm0	 # vf, vf.2_6
cvttss2si	%xmm0, %eax	 # vf.2_6, vi1.3_7
movl	%eax, 28(%esp)	 # vi1.3_7, vi1

For lrintf GCC is using single fistpl FPU instruction:

flds	20(%esp)	 # vf
/APP
 # 764 "c:\mingw\include\math.h" 1
fistpl 28(%esp)	 # retval
 # 0 "" 2
/NO_APP
movl	28(%esp), %eax	 # retval, _9
movl	%eax, 24(%esp)	 # _9, vi0

If no SSE SIMD requested from the compiler then a cast to integer becomes not optimal because compiler has to set Round-Towards-Zero mode with fldcw surrounding fistpl, it makes code slower due to FPU mode switch:

flds	36(%esp)	 # vf
movb	$12, %ah	 #, tmp94
movw	%ax, 28(%esp)	 # tmp94,
fldcw	28(%esp)	 #
fistpl	24(%esp)	 #
fldcw	30(%esp)	 #
movl	24(%esp), %eax	 #, vi1.3_7
movl	%eax, 44(%esp)	 # vi1.3_7, vi1

It is what you mentioned "on x386 target cast to integer is slow because it always resets the rounding mode to truncate, then restores it".

So the conclusion is:

1. If application is targeting x86 and not requesting SSE from the compiler then cast to integer will be not optimal in terms of performance due to additional usage of fldcw instruction surrounding fistpl.

2. Usage of lrintf when code is compiled with MSVC or GCC and with SSE SIMD enabled is also not optimal because MSVC is doing a function call to __imp__lrintf while GCC is falling back to a FPU code that is causing more instructions and also vectorized optimization is no longer possible.

3. Current change to the cast to integer looks optimal for x86/x64 when SSE SIMD is used but less optimal when compiler is using only FPU instructions.

4. lrint is affected by the rounding mode and the code should be slower (not benchmarked) on Windows platform if generated by MSVC compiler due to a function call (compiler does not substitute it with a single fistpl like GCC does it).

[philburk]

There is some interesting code in Android that does lots of PCM format conversions.
https://android.googlesource.com/platform/system/media/+/refs/heads/master/audio_utils/primitives.c