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

[Matt Oliver]

>
> > 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: configure-Fix-floating-point-conformance-ith-icl.patch
Type: application/octet-stream
Size: 1113 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140511/0c4eb19d/attachment.obj>