[FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

Michael Niedermayer michael at niedermayer.cc
Sun Jul 10 14:36:12 EEST 2016


On Sun, Jul 10, 2016 at 07:08:19AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Thu, Jul 7, 2016 at 8:51 AM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> 
> > Hi,
> >
> > On Thu, Jul 7, 2016 at 7:38 AM, Michael Niedermayer <
> > michael at niedermayer.cc> wrote:
> >
> >> On Thu, Jul 07, 2016 at 07:14:43AM -0400, Ronald S. Bultje wrote:
> >> > Hi,
> >> >
> >> > On Thu, Jul 7, 2016 at 7:07 AM, Michael Niedermayer
> >> <michael at niedermayer.cc>
> >> > wrote:
> >> >
> >> > > On Wed, Jul 06, 2016 at 07:28:27AM -0500, Dan Parrot wrote:
> >> > > > On Wed, 2016-07-06 at 09:07 +0200, Hendrik Leppkes wrote:
> >> > > [...]
> >> > >
> >> > > >
> >> > > > One other thing: why didn't this come up when the earlier patch was
> >> > > > submitted and applied?
> >> > >
> >> > > community patch review is not a reproduceable process, depending on
> >> > > who has time and does the review, different things can be found and
> >> > > pointed out, and people have also different oppinions.
> >> > > Real consistency can possibly only be achived by having an active
> >> > > maintainer that does all review ...
> >> > >
> >> > > To be more precisse the other patch was applied due to this comment
> >> > > IIRC:
> >> > >  "If this patch works (FATE passes on ppc64) and is faster than
> >> > >   the plain c functions then it can be committed as is"
> >> >
> >> >
> >> > How much faster was it?
> >>
> >> There where several benchmarks posted, one is here:
> >> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-June/196022.html
> >> it also contains some arguments why the speedup is less than on x86
> >
> >
> > I don't think these numbers are very convincing...
> >
> > The arguments, on the other hand, are not facts, they are hunches, so they
> > are essentially meaningless.
> >
> > I would suggest to revert the patch
> >
> [..]
> 
> So, this hasn't been reverted yet, is there any particular reason why it
> hasn't?
> 
> Again, the speedup is practically meaningless, the code unreviewed, and it
> will have to be rewritten by whoever finishes #5570. Can we please agree
> reverting is the best option - and then revert?

i think if you want to "mentor" this you should just do what you need
to do to mentor this ...

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160710/18ffffae/attachment.sig>


More information about the ffmpeg-devel mailing list