[FFmpeg-devel] [PATCH] unscaled float 2 int conversion

[Benjamin Larsson]

Michael Niedermayer wrote:
> On Thu, May 15, 2008 at 09:14:15PM +0200, Benjamin Larsson wrote:
>   
>> Michael Niedermayer wrote:
>>     
>>>> Well when I tried the last time I did't get it to work, there was some
>>>> overlap issue that wasn't trivial to sort out. 
>>>>         
>>> You just add 384 or what it was after the windowing/overlap.
>>>
>>>       
>> Just to be clear, this bias scale thing is about not having to use the
>> fstp fpu call or whatever it is called on other cpus. To perform it you
>> first scale down your samples to -1 and 1. This scaling operation is
>> most often performed for free by scaling a suitable table somewhere.
>> Then you add 384 so you can cast the float value directly to an integer.
>> So you trade a float add against fstp which must have been faster on
>> some cpu (or else they wouldn't have used it).
>>
>> In FFmpeg we also have 3dnow, sse and altivec code that can do float to
>> int16 conversion. I think we can agree that the simd code is faster then
>> the bias trick on all processors that supports the simd code. Then we
>> are left with Intel cpus before P3, the Motorola G3 and various other
>> cpus with only fpus and no simd unit. I'm pretty sure that this trick is
>> the best when we are dealing with P2 cpus and lower but I'm not sure it
>> is for the G3.
>>
>> So then we come to the matter of performance, you want benchmarks to
>> justify changing or adding a new scaling method. As I don't have access
>> to any machines that doesn't have a simd unit I can't do any usable
>> benchmarks. But I'm quite sure that if I had access it would show that
>> doing the bias trick would be faster. So one could argue that well ok
>> then we keep the code as it is. But my opinion is that we should scrap
>> this anyway, it makes the code complex, it slows down the simd code
>> (very little though) for no good reason, it complicates the development
>> of a proper audio api and filter system. Cpus with slow fpus should use
>> fixed point code instead.
>>
>> So I propose that we start cleaning out this.
>>     
>
> Ohh well, why do i always have to do the work? You could have safed me
> some time by just saying that you wont do the benchmarks.
>   

What I'm saying is that I think it is irrelevant that the bias trick is 
faster on a P3 then lrint because on the P3 we have sse available. Thus 
on P3 we can beat the bias trick. What would be interesting is P2 and 
lower. But as I don't have access to any machine like that I can't make 
any relevant benchmark.


> PS: yes i dont give a damn what you or anyone else thinks, either
> i see benchmarks or people can go talking to their next wall.
> It would have taken you less time to disable MMX*/SSE* and write
> a benchmark than explaining why its better not to.
>   
No P2, no benchmark, or do you suggest that the C code always have to be 
the fastest available possible? Even if 99% of the time people will run 
the simd version?

MvH
Benjamin Larsson