[FFmpeg-devel] PATCH: av_strtod

[Ramiro Polla]

On Mon, Jun 1, 2009 at 10:43 PM, Ramiro Polla <ramiro.polla at gmail.com> wrote:
> On Mon, Jun 1, 2009 at 10:38 PM, Pavel Pavlov <pavel at summit-tech.ca> wrote:
>> On Mon, Jun 01, 2009 at 01:27:52AM -0400, Pavel Pavlov wrote:
>>> Biggest problem is the black voodoo code related to inline assembly
>>> and
>>> MANGLE(...) plus the worst ever code is in recently added
>>> mlp_filter_channel_x86, which mangles lables. WTF, why not a
>>> standalone .asm file instead?!?
>>
>> And how would you do that with a plain .asm file? Write the function setup code yourself (meaning you will only support the select few architectures you explicitly write code for) or using yasm (meaning you will support only the less select but still quite few architectures ABIs it supports)?
>>
>>
>>
>> Well, for that file instead of storing pointers to labels and doing repeatative jumps in the loop I wrote mlpdsp_template.c that creates using C preprocessor 8*4 functions mlp_filter_channel_x86_X_Y and I use table of function pointers and call a function based on the X and Y. That was just about the only way I could make that function work on for intel compiler.
>
> Have you benchmarked the code?
>
> It was much slower (even slower than the for() loops in C) to have 8*4
> functions because of instruction cache misses.

I tested again with attached patch, and it's not "much" slower like I
said before, but actually ~2% slower for x86_64 and ~6% slower for
x86_32. It adds 8k of object code.

Besides, you don't "have to" make it work on intel compiler. It is
just an optimization. Optimizations can easily be disabled if the
compiler doesn't like them (for example x86 optimizations are disabled
for ppc). Everything worked fine without them there, just a little bit
slower.

Ramiro Polla
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mlp_filter_array.diff
Type: text/x-patch
Size: 4604 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090601/7063e4d0/attachment.bin>