[FFmpeg-devel] [PATCH] update doc/optimization.txt
Ronald S. Bultje
rsbultje
Wed Sep 22 15:47:16 CEST 2010
Hi,
2010/9/22 M?ns Rullg?rd <mans at mansr.com>:
> Michael Niedermayer <michaelni at gmx.at> writes:
>> On Wed, Sep 22, 2010 at 02:11:49PM +0100, M?ns Rullg?rd wrote:
>>> Michael Niedermayer <michaelni at gmx.at> writes:
>>> > On Wed, Sep 22, 2010 at 08:37:07AM -0400, Ronald S. Bultje wrote:
>>> >> Also, should I mention (in general tips) that functions that use huge
>>> >> structs (e.g. MpegEncContext) are A) "discouragable" in general and B)
>>> >> better written in inline asm than yasm because of the difficulty of
>>> >> predicting struct offsets?
>>> >
>>> > B is ok about A, who uses huge structs when its not needed ...
>>>
>>> If possible, the asm functions should be passed pointers into (or
>>> values from) the struct in preference over passing a pointer to the
>>> whole struct.
>>
>> if one needs just 1 pointer into a struct yes, if one needs 5, its not
>> efficient to use up 5 registers and waste the time to initialize them
>> besides that x86-32 has too few registers for this to work out
>
> In many such cases, those values could be put in a struct of their own
> contained within the larger struct. ?Manually managing offsets in a
> small struct is simple enough.
I think this is sort of the message I was hoping to put forward. I'm
not saying we should change MpegEncContext, that code exists and works
well, I'm just saying that for future (newly written) pieces of code
requiring new simd, we should look into alternatives as both of you
pointed out. Both of your alternatives could work in some situations,
and there's others where a big struct is really the best solution.
Hence no details in the doc, just "isn't always best".
Ronald
More information about the ffmpeg-devel
mailing list