Speed » History » Version 5
Version 4 (Chris Cannam, 2014-05-07 01:38 PM) → Version 5/29 (Chris Cannam, 2014-05-07 01:48 PM)
h1. Speed
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.
Work so far:
* Pre-optimisation, commit:ce64d11ef336 (release build) takes 104 seconds to process a 43.5-second file. (For reference, a debug build takes over 850 seconds.)
* Experiments to test Testing where the time is spent:
** Removing the unused Vamp plugin outputs: no more than 1% 1 second difference
** Removing debug printouts: no more than 1% 1 second difference
** Adjusting the CQ resampler parameters to allow a lower SNR: no more than 1% 1 second difference
** Halving the number of EM iterations: reduces runtime by 43% (to dramatically, to 59 sec). sec. If this is linear, then EM (rather than CQ etc) must be taking around 86% of the total.
* Optimising EM:
** Storing the templates as double instead of single-precision floats saves around 4% overall, for 100 sec
** (Alternatively, storing them as floats and using single-precision arithmetic throughout saves around 14%, but presumably produces different results -- not pursued at this point)
** 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
** Factoring out a further loop saves another 11%, for 78 sec
* Multi-threading:
** 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
total time.
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.
Work so far:
* Pre-optimisation, commit:ce64d11ef336 (release build) takes 104 seconds to process a 43.5-second file. (For reference, a debug build takes over 850 seconds.)
* Experiments to test Testing where the time is spent:
** Removing the unused Vamp plugin outputs: no more than 1% 1 second difference
** Removing debug printouts: no more than 1% 1 second difference
** Adjusting the CQ resampler parameters to allow a lower SNR: no more than 1% 1 second difference
** Halving the number of EM iterations: reduces runtime by 43% (to dramatically, to 59 sec). sec. If this is linear, then EM (rather than CQ etc) must be taking around 86% of the total.
* Optimising EM:
** Storing the templates as double instead of single-precision floats saves around 4% overall, for 100 sec
** (Alternatively, storing them as floats and using single-precision arithmetic throughout saves around 14%, but presumably produces different results -- not pursued at this point)
** 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
** Factoring out a further loop saves another 11%, for 78 sec
* Multi-threading:
** 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
total time.