[FFmpeg-soc] [soc]: r5419 - als/alsdec.c

[Michael Niedermayer]

On Fri, Oct 23, 2009 at 01:03:56PM +0200, Thilo Borgmann wrote:
> Michael Niedermayer schrieb:
> > On Thu, Oct 22, 2009 at 08:26:12PM +0200, Thilo Borgmann wrote:
> >> Michael Niedermayer schrieb:
> >>> On Thu, Oct 22, 2009 at 01:32:15PM +0200, Thilo Borgmann wrote:
> >>>> Michael Niedermayer schrieb:
> >>>>> On Thu, Oct 22, 2009 at 11:29:55AM +0200, Thilo Borgmann wrote:
> >>>>>> Thilo Borgmann schrieb:
> >>>>>>> Michael Niedermayer schrieb:
> >>>>>>>> On Wed, Oct 21, 2009 at 12:33:21PM +0200, Thilo Borgmann wrote:
> >>>>>>>>> Michael Niedermayer schrieb:
> >>>>>>>>>> On Tue, Oct 20, 2009 at 03:00:40PM +0200, thilo.borgmann wrote:
> >>>>>>>>>>> Author: thilo.borgmann
> >>>>>>>>>>> Date: Tue Oct 20 15:00:40 2009
> >>>>>>>>>>> New Revision: 5419
> >>>>>>>>>>>
> >>>>>>>>>>> Log:
> >>>>>>>>>>> Splits reading of block data and decoding of block data.
> >>>>>>>>>>> Introduces ALSBlockData struct.
> >>>>>>>>>> You are missing the "why" part, that should be explained in the commit
> >>>>>>>>>> message
> >>>>>>>>> Yes, sorry.
> >>>>>>>>>
> >>>>>>>>>> also this needs a benchmark as there are many additional dereferences
> >>>>>>>>>> added
> >>>>>>>>> It is a necessary evil to support MCC. If it would be faster the "old"
> >>>>>>>>> way for non-MCC files, would this reason to have both, a split read &
> >>>>>>>>> decode function pair and an all-in-one function?
> >>>>>>>> I think a benchmark is usefull to judge if we should spend time thinking
> >>>>>>>> about alternatives to the many dereferences or not
> >>>>> [...]
> >>>>>>> This is a 30% difference which makes me think to try these alternatives.
> >>>>>>>
> >>>>>>> What comes into my mind would be to use local copies, thus dereferencing
> >>>>>>> the field of *bd just twice. One at the top and one at the bottom of the
> >>>>>>> function.
> >>>>>>>
> >>>>>> I tested using local copies instead of dereferencing:
> >>>>> [...]
> >>>>>> That's a 4% gain so I think local copies don't pay off...
> >>>>>>
> >>>>>> Other alternatives?
> >>>>> i would first confirm that gcc did not do something stupid about inlining.
> >>>>> Or more precissely not inlining some random unrelated function after the
> >>>>> file got bigger ...
> >>>> How to do that?
> >>> nm -S foobar.o
> >>> will show you things that are not inlined and how large they are
> >> The BSD version does not have the option to show the size instead of the
> >> 'value'...
> >>
> >>
> >>> you can also use gcc to compile code to .s files and use grep on them
> >> ... so this seems to be necessary. What am I grepping for?
> > 
> > here
> > egrep '(^[^.]*.:|call[[:space:]]*[a-z])'
> > shows function names and all calls to non inlined functions
> > a diff of this from old and new could be interresting
> 
> Ok, reading this thread again I began not to feel too sure about if we
> are talking about the diff between "local variables <-> dereferences" or
>  "combined <-> separate" functions.
> 
> So I grepped both files for both cases. I'm not trained in reading the
> diff's so I included the grep output for all cases.

you need a different grep line
its suposed to look like (for huffyuv for example)
add_left_prediction:
sub_left_prediction:
decode_422_bitstream:
decode_gray_bitstream:
decode_bgr_bitstream:
draw_slice:
encode_end:
	call	av_freep
	call	av_freep
	call	av_freep
	call	av_freep
	call	av_freep
alloc_temp:
	call	av_malloc
	call	av_malloc
	call	av_malloc
	call	av_malloc
	call	av_malloc
decode_end:
	call	av_freep
	call	av_freep
	call	av_freep
	call	av_freep
	call	free_vlc
	call	free_vlc
	call	free_vlc
	call	free_vlc
	call	free_vlc
	call	free_vlc


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20091023/a3c34a82/attachment.pgp>