On Feb 25, 2013, at 12:53, Carl Eugen Hoyos wrote: > René 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? 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
