Age | Commit message (Collapse) | Author |
|
marginal improvement on x86_64 for zero, 5-10% for tiny numbers;
100% time improvement (half the time) on i686 with zero.
#/bin/sh
g++ -x c++ -O3 -ffast-math -o /tmp/a.out - << EOF
#include <stdio.h>
#include <stdlib.h>
#include <cmath>
#include <limits>
static inline float accurate_coefficient_to_dB (float coeff) {
#if 1 // try me
if (coeff < 1e-15) return -std::numeric_limits<float>::infinity();
#endif
return 20.0f * log10f (coeff);
}
int main (int argc, char **argv) {
long long int i;
float f = 0;
if (argc < 3) return -1;
long long int end = atoll (argv[1]);
for (i = 0; i < end; ++i) {
f += accurate_coefficient_to_dB (atof (argv[2]));
}
printf ("%f\n",f);
return 0;
}
EOF
time /tmp/a.out 100000000000 0.0
time /tmp/a.out 100000000000 0.0
time /tmp/a.out 100000000000 0.0
|
|
fixes use of overloaded operator '==' is ambiguous (with operand types 'MPControl<gain_t>' and 'double') in previous commit.
|
|
1) Disambiguate 1.0 to GAIN_COEFF_UNITY, and 0.0 to GAIN_COEFF_ZERO
2) Add GAIN_COEFF_SMALL which replaces SMALL_SIGNAL (-140dB)
3) GAIN_COEFF_SMALL can used to avoid interpolating towards -inf on a db scale
4) GAIN_COEFF_SMALL is used to detect very small (denormal?) gains and memset to zero
|
|
Shoot for roughly 30 steps for all controls.
Always keep sensible step information in ParameterDescriptor and just convert
for the UI.
This is a little weird, but it's less weird than it was before, and works.
|
|
fast_coefficient_to_dB() returns a lower bound value, unsuitable
to catch audio peaks. The difference to 20*log10 is as large as 0.4 dB!
The effective speedup of fast_log10 compared to log10f is marginal
(sweep of all 24bit values)
i686 (1.6GHz Intel core): 2.36 [times faster]
x86_64 (core2 2.4GHz): 1.63
x86_64 (I3 2.80GHz): 2.03
the execution time of one log10f() averaged over a
sweep of all 24 bit values
i686 (1.6GHz Intel core): 0.131 usec
x86_64 (core2 2.4GHz): 0.033 usec
x86_64 (I3 2.80GHz): 0.044 usec
PeakMeter::run() is called from dedicated non-rt, no harm done.
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@9748 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
intended, and along the way start to rationalize MotionFeedback/VolumeController classes
git-svn-id: svn://localhost/ardour2/branches/3.0@9746 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
mixing). Whitespace changes only.
Vimmers, try let c_space_errors = 1 in your .vimrc to highlight this kind of stuff in red. I don't know the emacs equivalent...
git-svn-id: svn://localhost/ardour2/branches/3.0@5773 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
speed-critical
code. Fixes mantis 2833.
git-svn-id: svn://localhost/ardour2/branches/3.0@5565 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
All #include statements that include a header that is a part of a library
bundled with ardour MUST use quotes, not angle brackets.
Do this:
#include "ardour/types.h"
NOT this:
#include <ardour/types.h>
Rationale:
This is best practice in general, to ensure we include the local version
and not the system version. That quotes mean "local" (in some sense)
and angle brackets mean "system" (in some sense) is a ubiquitous
convention and IIRC right in the C spec somewhere.
More pragmatically, this is required by (my) waf (stuff) for dependencies
to work correctly. That is:
!!! FAILURE TO DO THIS CAN RESULT IN BROKEN BUILDS !!!
Failure to comply is punishable by death by torture. :)
P.S. It's not that dramatic in all cases, but this (in combination with some
GCC flags specific to the include type) is the best way I have found to be
absolutely 100% positive the local ones are being used (and we definitely
want to be absolutely 100% positive on that one).
git-svn-id: svn://localhost/ardour2/branches/3.0@4655 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@3435 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@3432 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/trunk@1535 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/trunk/ardour2@17 d708f5d6-7413-0410-9779-e7cbd77b26cf
|