[FFmpeg-devel] [PATCH 2/2] configure: Use intel math.h header.

[Michael Niedermayer]

On Sun, May 11, 2014 at 03:42:30PM +1000, Matt Oliver wrote:
> >
> > > Msvc also optimizes
> > > out multiplies by zero
> > I'm fairly certain it does not with default options.
> 
> 
> Correct, my apologies for not being clearer. I was referring to optimizing
> out multiplies by zero with fp:fast optimizations which icl defaults to. So
> I was just trying to draw a comparison at those settings but as your right
> the default for msvc is fp:precise so at that setting the comparison is
> incorrect.
> 
> 
> > No, it really doesn't. Floating-point code is not the only thing in a
> > program and e.g. /fp:precise still allows plenty of (problematic) invalid
> > optimizations.
> > The problem is that Intel decide to enable by default very dangerous and
> > wrong optimizations.
> > If you search for the gcc "equivalent" -ffast-math you should find lots of
> > examples.
> > These optimizations are _dangerous_ and honestly you'd have to be insane
> > to enable them _globally_. Floating-point is problematic enough even if you
> > can rely on compliance.
> > We do not support/enable it on gcc for good reasons, and I object to
> > supporting it for other compilers just because the vendor though fast is
> > better than safe.
> > If we want it, make it an option and add -ffast-math for gcc as well.
> > Anything else is just setting people up for wrong benchmarks (by allowing
> > only some compilers to ignore the rules) and other bad surprises.
> 
> 
> icl provides two fast math optimization levels fp:fast=1/fp:fast=2 and by
> default uses the former. fp:fast=2 does heavy float optimizations and that
> one can as you say be _dangerous_/insane. Clearly fp:fast is not suitable
> either so given that msvc is using fp:precise it would be more consistent
> to patch icl to do the same. Adding a -fast-math option would be
> interesting but as it breaks stuff (this being case in point) then your
> right in that its probably not a good idea.
> 
> 
> > Is an ICL build even faster than a GCC build? Or why are you using it?
> > MSVC builds are significantly slower than GCC builds, even if I
> > disable inline assembly in the GCC build - and in my experience ICL
> > doesn't provide *that* much of a bonus.
> 
> 
> ICL is at times significantly faster than msvc depending on the code (SIMD
> heavy stuff benefits more). Comparing to gcc the benefits aren't that
> significant performance wise. However on Windows the comparison is with
> MinGW and the advantage that icl has is that its a native toolchain that
> can directly use the latest native windows headers/libs and
> integrates/debugs nicely with visual studio projects. So on non-Windows I
> have no problems with gcc but when it comes to native windows the
> comparison is between icl and msvc and there are advantages to icl.
> 
> But at any rate icl support was in FFmpeg before I did anything. So dont
> shoot the messenger so to speak as I didnt create the issues im just trying
> to fix them ;)
> 
> Attached is a new patch that should be more acceptable.

>  configure |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 6f47345edbdacaa5056da4c8ac763b700556852e  configure-Fix-floating-point-conformance-ith-icl.patch
> From 5ea7b950e416069aae5985858580fde44de8ef91 Mon Sep 17 00:00:00 2001
> From: Matt Oliver <protogonoi at gmail.com>
> Date: Sun, 11 May 2014 15:07:13 +1000
> Subject: [PATCH] configure: Fix floating point conformance ith icl.

applied
thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140511/7ec72bd3/attachment.asc>