On Feb 25, 2013, at 12:00, Carl Eugen Hoyos wrote: > Unfortunately, turning auto-vectorisation on triggers > bugs in gcc and is therefore no option;-(
Maybe in ffmpeg sources, but we're not talking about that here. 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. Yes, it's on by default in gcc 4.7 and has to be switched off explicitly. BTW, I did force a gcc-4.7 auto-vectorised build of ffmpeg recently (using also -ftracer), and didn't notice any errors once alignment issues were avoided (i.e. on OS X). I just noticed no speed gains in my application that justified the effort that would be required to ensure correct alignment on MSWin. Oh, and I didn't claim that a compiler-optimised ad-hoc scalar function would perform better. I just wouldn't be amazed if it had less overhead than using a generic function, as I think we're talking about a very simple operation ... and especially if the buffers are relatively small. And debugging your own code is (almost) always easier than debugging someone else's code O:-) > And since this is a mailing list for developers, it > makes absolutely no sense to argue "compilation is > so difficult", especially as it is only a question No one ever said that ... I just raised the point that a local build would be required. Note that the step from using prebuilt static libraries to self-built libraries does require satisfying all the dependencies first. Not necessarily difficult, but it can be a nuisance if you don't want to use something like MacPorts or apt-get because they'd impose even more dependencies... As to the cast - I suppose Brad put it there just to get rid of a compiler warning (or error, if he's using c++). Of course it shouldn't be doing anything else. R _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
