On 2/25/13, "Rene J.V. Bertin" <[email protected]> wrote: > On Feb 25, 2013, at 12:53, Carl Eugen Hoyos wrote: > >> Rene J.V. Bertin <rjvbertin@...> writes: >> >>> I for one assume that the gcc devs would not have provided >>> default-on auto-vectorisation if the feature triggered >>> (too many) bugs they know of. >> >> You probably also assume the gcc developers do know >> the difference between a undecidable and a NP-hard problem? >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203 > > Who cares, as long as they don't release versions that fail on too many > kinds of code? As far as I'm concerned they can use whatever kind of magic > as long as it isn't too black ;) > >> Seriously: If auto-vectorisation works (for some gcc >> versions) and has a performance-gain, please send a >> patch. > > Wilco, but don't count on it. If gains are to be had they'll probably not > only be for specific compiler and host types/versions, but also be on a > case-by-case basis (file or even function level), which is probably hard to > integrate into the build procedure. > > To be honest, the example I cited earlier was the 1st time I ever saw a true > gain from auto-vectorisation (as opposed to automatic use of the SSE abi for > 'regular' calculations). And even that spectacular gain is completely > drowned in my application ... little does it matter if a pixel format > conversion routine runs at 10kHz or at almost 25kHz when you're calling it > at typical video frequencies (or there are a number of other bottlenecks). > > BTW, is there some documentation on ffmpeg.org on how to create patches > after having hacked around in the source tree?
Yes, it is on usual location on project web page. > And a related question: what's a good way to perform real-world benchmarks > on the libraries? Can ffmpeg be compiled so that it collects performance > statistics on specific operations? Because I presume no one will be > interested in patches that give a performance gain that's significant > (reproducible) but completely irrelevant on the overall timescale of > operations... > (in fact I'm quite sure of that, having read a discussion on a patch to > support building universal binaries on OS X ... which could be as easy as > implementing the more-or-less standard --disable-dependency-tracking option > in configure :) ) > > R > _______________________________________________ > Libav-user mailing list > [email protected] > http://ffmpeg.org/mailman/listinfo/libav-user > _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
