[FFmpeg-devel] [PATCH] "assert(a && b)" --> "assert(a); assert(b)" for more precise diagnostics, except for libformat

[Michael Niedermayer]

On Wed, May 15, 2019 at 12:13:07PM -0700, Adam Richter wrote:
> On Tue, May 14, 2019 at 6:48 PM mypopy at gmail.com <mypopy at gmail.com> wrote:
> >
> > On Wed, May 15, 2019 at 7:01 AM Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> > >
> > > On Tue, May 14, 2019 at 11:25 PM Adam Richter <adamrichter4 at gmail.com> wrote:
[...]
> > > >
> > > > Also after this, I may take a look at adding a branch hint to the av_assertN
> > > > macros if nobody objects.
> > > >
> > >
> > > Please don't, we don't do branch hints anywhere, and this is a bad
> > > place to start.
> > > If an assert is truely performance sensitive (as in, it makes a
> > > measurable difference), it should probably be moved from assert0 to
> > > assert1, and as such is only enabled in testing builds.
> > >
> > If assert0 or assert1 lead to performance drop, we need some profiling
> > data, then try to fix it.
> 
> The above comments by Hendrick and you does not identify a cost to
> adding a branch hint to assert.  There would be a downside in the form of
> a few lines of code complexity in libavutil/avassert.h.  If that is
> your concern,
> I guess our disagreement is that I see reducing the cost of assert so that
> perhaps CPU usage with and without would be a tiny bit more similar for
> reproducing problems and maybe (I'm not saying it's likely) it might tip a
> trade-off in favor of keeping an assert enabled in some borderline
> circumstance.  I'd take that trade (add the branch prediction).
> 
> If you want to educate me on some other reason why I may be wrong,
> about adding the branch prediction for assertion checks, I'd been keen
> to know, but I realize everyone's time is limited, and if I haven't
> convinced you and also created consensus in favor of adding the
> branch prediction to assertion checking, then I don't expect to advocate
> further on this list for merging such a change into your tree at this time.

I think a key question here would be if a speedeffect or code generation
improvment can be shown to have actually occured. Instead of assuming that
it could.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190517/984026df/attachment.sig>