On Wed, May 15, 2019 at 12:13:07PM -0700, Adam Richter wrote: > On Tue, May 14, 2019 at 6:48 PM myp...@gmail.com <myp...@gmail.com> wrote: > > > > On Wed, May 15, 2019 at 7:01 AM Hendrik Leppkes <h.lepp...@gmail.com> wrote: > > > > > > On Tue, May 14, 2019 at 11:25 PM Adam Richter <adamricht...@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
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
