[FFmpeg-devel] PATCH: av_strtod

[Ramiro Polla]

On Tue, Jun 2, 2009 at 12:13 AM, Pavel Pavlov <pavel at summit-tech.ca> wrote:
>>> 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
>
>
>
> It didn't take that much time for me to update it.
> I regularly update my svn view and check new changes/updates and rebuild
> my code.
>
> With that mlpdsp I was surprised that it compiles on gcc at all ;) I

Me too =)

But hey, it worked on gcc 4.x, 3.x, 2.95, icl (linux) and llvm, so it
mustn't be that bad...

> didn't benchmark that code, but I thought that it would be even faster

Oh, I benchmarked quite a bunch of different suggestions, and this was
the best candidate... There's still one suggestion by Uoti that I
haven't gotten around to make a patch for that speeds up C code about
3% on x86_32. IIRC it consisted of
if(order==x) goto end;
accum += xxx;
for each order.

> because there wouldn't be any more jumps inside the loop. Probably if
> functions are called in order like 4_3, 3_2, 2_1 and if it looped just
> for 2-3 times in each of the functions... Still it shouldn't be slower I

I didn't understand this suggestion.

[...]
> I know I could just disable it, but I didn't disable anything. However,
> I forgot to mention in previous post that I had to disable all 3dnow
> code, icl refuses any 3dnow instruction :)
> ./configure with disable-3dnow doesn't work at all. I think that any
> 3dnow code has to be guarded by #if 3DNOW_ENABLE etc, same for mmx, sse
> etc. Otherwise this configure option should be trashed, since it may
> make ppl think that resulting binary doesn't contain 3dnow code which
> isn't correct at all.

Bug reports and patches are welcome to properly disable code for simd
that is not supported. But IIRC that should already work.

And do you think you could clear up your replies a bit? They aren't
quoting (>) properly, and your mailer is using long lines, besides you
could trim a bit more. Take a look at
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-June/date.html
to see what they look like and compare against the other messages.

Ramiro Polla