This is a trivial rewrite of the loops that results in better
prefetching and associated cache efficiency. Essentially, the problem is
that modern prefetching logic is based on finite state Markov memory, a reasonable
assumption that is used elsewhere in CPU's in for instance branch
predictors.
Surrounding loops all iterate forward through the array, making the
predictor think of prefetching in the forward direction, but the
intermediate loop is unnecessarily in the backward direction.
Speedup is nontrivial. Benchmarks obtained by 10^6 iterations within
solve_lls, with START/STOP_TIMER. File is tests/data/fate/flac-16-lpc-cholesky.err.
Hardware: x86-64, Haswell, GNU/Linux.
new:
17291 decicycles in solve_lls, 2096706 runs, 446 skips
17255 decicycles in solve_lls, 4193657 runs, 647 skips
17231 decicycles in solve_lls, 8384997 runs, 3611 skips
17189 decicycles in solve_lls,16771010 runs, 6206 skips
17132 decicycles in solve_lls,33544757 runs, 9675 skips
17092 decicycles in solve_lls,67092404 runs, 16460 skips
17058 decicycles in solve_lls,134188213 runs, 29515 skips
old:
18009 decicycles in solve_lls, 2096665 runs, 487 skips
17805 decicycles in solve_lls, 4193320 runs, 984 skips
17779 decicycles in solve_lls, 8386855 runs, 1753 skips
18289 decicycles in solve_lls,16774280 runs, 2936 skips
18158 decicycles in solve_lls,33548104 runs, 6328 skips
18420 decicycles in solve_lls,67091793 runs, 17071 skips
18310 decicycles in solve_lls,134187219 runs, 30509 skips
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Commit 14ea4151d7 had a bug in that the
conversion of the uint64_t result to an int (the return signature) would
lead to implementation defined behavior, and in this case simply
returned 0 for NAN. A fix via AND'ing the result with 1 does the trick,
simply by ensuring a 0 or 1 return value.
Patch tested with FATE on x86-64, GNU/Linux by forcing the compatibility
code via an ifdef hack suggested by Michael.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
* commit '588b6215b4c74945994eb9636b0699028c069ed2':
rtmpcrypt: Do the xtea decryption in little endian mode
xtea: Add functions for little endian mode
Conflicts:
libavutil/xtea.c
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This improves the mathematical behavior of hypotenuse computation.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
It is known that the naive sqrt(x*x + y*y) approach for computing the
hypotenuse suffers from overflow and accuracy issues, see e.g
http://www.johndcook.com/blog/2010/06/02/whats-so-hard-about-finding-a-hypotenuse/.
This adds hypot support to FFmpeg, a C99 function.
On platforms without hypot, this patch does a reaonable workaround, that
although not as accurate as GNU libm, is readable and does not suffer
from the overflow issue. Improvements can be made separately.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
isnan and isinf are actually macros as per the standard. In particular,
the existing implementation has incorrect signature. Furthermore, this
results in undefined behavior for e.g double values outside float range
as per the standard.
This patch corrects the undefined behavior for all usage within FFmpeg.
Note that long double is not handled as it is not used in FFmpeg.
Furthermore, even if at some point long double gets used, it is likely
not needed to modify the macro in practice for usage in FFmpeg. See
below for analysis.
Getting long double to work strictly per the spec is significantly harder
since a long double may be an IEEE 128 bit quad (very rare), 80 bit
extended precision value (on GCC/Clang), or simply double (on recent Microsoft).
On the other hand, any potential future usage of long double is likely
for precision (when a platform offers extra precision) and not for range, since
the range anyway varies and is not as portable as IEEE 754 single/double
precision. In such cases, the implicit cast to a double is well defined
and isinf and isnan should work as intended.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
* commit '1fc94724f1fd52944bb5ae571475c621da4b77a0':
xtea: Clarify that the current API works in big endian mode
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
The function is renamed to ff_rint64_clip()
This should avoid build failures on VS2012
Feel free to changes this to a different solution
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The rationale for this function is reflected in the documentation for
it, and is copied here:
Clip a double value into the long long amin-amax range.
This function is needed because conversion of floating point to integers when
it does not fit in the integer's representation does not necessarily saturate
correctly (usually converted to a cvttsd2si on x86) which saturates numbers
> INT64_MAX to INT64_MIN. The standard marks such conversions as undefined
behavior, allowing this sort of mathematically bogus conversions. This provides
a safe alternative that is slower obviously but assures safety and better
mathematical behavior.
API:
@param a value to clip
@param amin minimum value of the clip range
@param amax maximum value of the clip range
@return clipped value
Note that a priori if one can guarantee from the calling side that the
double is in range, it is safe to simply do an explicit/implicit cast,
and that will be far faster. However, otherwise this function should be
used.
avutil minor version is bumped.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This adds msvc optimisations as well as fixing an error in icl whereby it will generate invalid code otherwise.
Signed-off-by: Matt Oliver <protogonoi@gmail.com>
ICC versions older than atleast 12.1.6 dont have the tzcnt intrinsics.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Matt Oliver <protogonoi@gmail.com>
Fixes compilation of host tool aacps_fixed_tablegen.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Otherwise v=INT_MIN doesn't get normalized and thus triggers av_assert2
in other functions.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The correct result can't be expressed in SoftFloat.
Currently it returns a random value from an out of bounds read.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Trim unneeded leading components and trailing zeros.
Move the formating code in a separate function.
Use the function also to format the default value, it was currently
printed as plain integer, inconsistent to the way it is parsed.
This is of use for defining comparator callbacks. Common approaches like
return x-y are not safe due to the risks of overflow.
Furthermore, the (x > y) - (x < y) trick is optimized to branchless
code.
This also documents this macro accordingly.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Avoids inheritance of file handles on Windows systems similar to the
O_CLOEXEC/FD_CLOEXEC flag on Linux.
Fixes file lock issues in Windows applications when a child process
is started with handle inheritance enabled (standard input/output
redirection) while a FFmpeg transcoding is running in the parent
process.
Links relevant to the subject:
https://msdn.microsoft.com/en-us/library/w7sa2b22.aspx
Describes the _wsopen() function and the O_NOINHERIT flag. File handles
opened by _wsopen() are inheritable by default.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx
Describes handle inheritance when creating new processes. Handle
inheritance must be enabled (bInheritHandles = TRUE) e.g. when you want
to pass handles for stdin/stdout via lpStartupInfo.
Signed-off-by: Tobias Rapp <t.rapp@noa-audio.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
clSetKernelArg can return an error due to lack of memory (for instance):
https://www.khronos.org/registry/cl/sdk/1.1/docs/man/xhtml/clSetKernelArg.html.
Thus this error must be propagated.
Currently should not trigger warnings, but adds robustness.
Untested.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This simplifies and cleans up the code.
Furthermore, it is much faster due to absence of the slow log computation.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Current code is fine, this just adds robustness.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
av_gcd is now always defined regardless of input. This documents this
change in the "documented API". Two benefits (closely related):
1. The function is robust, and there is no need to worry about INT64_MIN, etc.
2. Clients of av_gcd, like av_reduce, can now be made fully correct. Currently,
av_reduce can trigger undefined behavior if e.g num is INT64_MIN due to
integer overflow in the FFABS. Furthermore, this undefined behavior is
completely undocumented, and could be a fuzzer's paradise. The FFABS was needed in the past as
av_gcd was undefined for negative inputs. In order to make av_reduce
robust, it is essential to guarantee that av_gcd works for all int64_t.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This ensures that no undefined behavior is invoked, while retaining
identical return values in all cases and at no loss of performance
(identical asm on clang and gcc).
Essentially, this patch exchanges undefined behavior with implementation
defined behavior, a strict improvement.
Rationale:
1. The ideal solution is to have the return type a uint64_t. This
unfortunately requires an API change.
2. The only pathological behavior happens if both arguments are
INT64_MIN, to the best of my knowledge. In such a case, the
implementation defined behavior is invoked in the sense that UINT64_MAX
is interpreted as INT64_MIN, which any reasonable implementation will
do. In any case, any usage where both arguments are INT64_MIN is a
fuzzer anyway.
3. Alternatives of checking, etc require branching and lose performance
for no concrete gain - no client cares about av_gcd's actual value when
both args are INT64_MIN. Even if it did, on sane platforms (e.g all the
ones FFmpeg cares about), it produces a correct gcd, namely INT64_MIN.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This one should not trigger any warnings, but will be useful for future
robustness.
Strictly speaking, one could check the size after the call by examining
the structure instead of the return value. Such a use case is highly
unusual, and this commit may be easily reverted if there is a legitimate
need of such use.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This ensures that the macro remains correct in the sense of allowing
expressions for value and bits, by placing the value and bits expressions within
parentheses.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
