Silvet Note Transcription

h1. Speed

h2. Aims

We want to make the plugin as fast as possible, but I think there's a case to be made for providing fast and slow modes (see [[Possibilities for Plugin Parameters]]).

In "fast" mode we should have the aim of producing a reasonable transcription in faster than real-time on any computer from the past 5 years or so. "Slow" mode has no particular speed constraint, simply as fast as possible an implementation of the best results we can easily do.

See the "timing":/projects/silvet/repository/show/testdata/timing directory in the repo for timing tests. These are all carried out on a Thinkpad T540p with Intel i5-4330M under 64-bit Linux.

h2. Work so far

 * commit:ce64d11ef336, pre-optimisation (release build) takes 104 seconds to process a 43.5-second file. (For reference, a debug build takes over 850 seconds.)

 * Experiments to test where the time is spent:

 ** commit:78a7bf247016 removing the unused Vamp plugin outputs: no more than 1% difference

 ** commit:f3bf6503e6c6 removing debug printouts: no more than 1% difference

 ** Adjusting the CQ resampler parameters to allow a lower SNR: no more than 1% difference

 ** commit:5314d3361dfb halving the number of EM iterations: reduces runtime by 43% (to 59 sec). If this is linear, then EM must be taking around 86% of the total.

 * Optimising EM:

 ** commit:97b77e7cb94c storing the templates as double instead of single-precision floats saves around 4% overall, for 100 sec

 ** (Alternatively, commit:840c0d703bbb storing them as floats and using single-precision arithmetic throughout saves around 14%, but presumably produces different results -- not pursued at this point)

 ** commit:19f6832fdc8a using bqvec library for raw vector allocation and manipulation instead of std::vector saves a further 10%, for 89 sec

 ** A couple of experiments to try to get the template arrays better aligned failed

 ** commit:6890dea115c3 factoring out a further loop saves another 11%, for 78 sec

 * Multi-threading:

 ** commit:df05f855f63b using OpenMP for the loop through columns when calling out to EM halves the runtime again (for 41s total), though now consuming 122s "user" time

 ** the same code with OMP_NUM_THREADS=1 now runs in 78 sec

That work was merged to default, for a new baseline time of 41s.

 * Optimising EM again:

 ** commit:f25b8e7de0ed not processing templates that are out of range for an instrument: saves 58% for 24 sec

h2. Other possibilities

 * Compare the quality of results using float arithmetic to those using doubles

 * Adaptively select the number of EM iterations -- if the process is converging more quickly, break off sooner (how to measure convergence?)

 * Optimise the constant-Q -- it wasn't a significant part of the runtime to start with, but is presumably becoming more significant now