Mercurial > hg > silvet
view testdata/timing/results.txt @ 107:16d6e2f6f159 bqvec-openmp
Report on latest
author | Chris Cannam |
---|---|
date | Tue, 06 May 2014 16:38:39 +0100 |
parents | ac750e222ad3 |
children | 2169e7a448c5 |
line wrap: on
line source
Thinkpad T540p i5-4330M @2.80GHz with 16GB RAM, plugged in Arch Linux, gcc 4.8.2 Using sonic-annotator v1.0 (commit:41c4de1e05d8), release build Debug flags: -g -fPIC Release flags: -O3 -ffast-math -msse -mfpmath=sse -ftree-vectorize -fPIC Release flags for qm-dsp also include -fomit-frame-pointer The input file is 1-channel 16-bit PCM at 44100Hz, duration 0m43.5s. DEBUG/RELEASE: commit:ce64d11ef336, release build of Silvet, release build of qm-dsp real 1m44.456s user 1m44.343s sys 0m0.210s commit:ce64d11ef336, debug build of Silvet, release build of qm-dsp real 14m16.124s user 14m16.907s sys 0m0.217s commit:ce64d11ef336, release build of Silvet, debug build of qm-dsp real 1m55.204s user 1m55.053s sys 0m0.253s Subsequent tests use release builds of both. VAMP FEATURE SUPPRESSION: commit:7133f78ccbf6, as commit:ce64d11ef336 but with CQ output feature return commented out real 1m46.162s user 1m46.093s sys 0m0.157s commit:78a7bf247016, as commit:ce64d11ef336 but with CQ output and FCQ output feature return commented out real 1m45.206s user 1m45.153s sys 0m0.147s conclusion: no advantage in removing these DEBUG PRINTOUTS: commit:f3bf6503e6c6, as commit:ce64d11ef336 but with debug printouts removed real 1m43.744s user 1m43.657s sys 0m0.203s conclusion: obviously we want to remove these eventually, but might as well keep in during testing EM ITERATIONS: commit:5314d3361dfb, as commit:ce64d11ef336 but with only 6 EM iterations instead of 12 real 0m59.055s user 0m58.897s sys 0m0.193s conclusion: EM dominates the time taken, not CQ or note forming CQ DECIMATOR CONFIGURATION: Uncommitted revision (because changes are in CQ subrepo) that is as commit:ce64d11ef336 but with resampler SNR=30 and BW=0.04 instead of SNR=60 and BW=0.02 real 1m43.176s user 1m43.067s sys 0m0.190s conclusion: supports the previous test OPENMP: commit:62b7be1226d5, as commit:ce64d11ef336 but with OpenMP parallel "for" in the main EM iteration loop (4 cores) real 0m56.400s user 2m59.740s sys 0m0.237s EM TWEAKS: commit:a0dedcbfa628, as commit:ce64d11ef336 but with variables hoisted out of loops and consts added wherever applicable real 1m44.548s user 1m44.460s sys 0m0.183s conclusion: compiler already knows this stuff commit:64b08cc12da0, as commit:ce64d11ef336 but with loops merged so as theoretically to reduce intermediate calculations real 3m46.969s user 3m46.850s sys 0m0.220s commit:6075e92d63ab, as commit:64b08cc12da0 but with innermost loop reverted to three loops with simple bodies instead of one with a more complex body real 1m44.767s user 1m44.490s sys 0m0.190s commit:97b77e7cb94c, as commit:6075e92d63ab but with templates stored as doubles instead of floats (doubling the size of the plugin binary) real 1m40.135s user 1m39.820s sys 0m0.230s commit:a6e136aaa202, as commit:97b77e7cb94c but with target vectors & grids initialised to epsilon instead of copied & then overwritten (this one also makes the intention clearer I think so is worth doing) real 1m39.277s user 1m39.000s sys 0m0.183s BQVEC: commit:81eaba98985b, as commit:a6e136aaa202 but converted to use bqvec for basic allocation etc; processing logic unchanged real 1m37.320s user 1m36.863s sys 0m0.240s commit:891cbcf1e4d2, as commit:81eaba98985b but with some calculations vectorised [note: has silly bug] real 1m24.961s user 1m24.663s sys 0m0.177s commit:853b2d750688, as commit:891cbcf1e4d2 but with silly bug fixed real 1m26.876s user 1m26.387s sys 0m0.267s commit:9ecad4c9c2a2, as commit:853b2d750688 but using a couple of bqvec calls in expectation function real 1m9.153s user 1m8.837s sys 0m0.187s (this seems unlikely -- what have I broken?) commit:8259193b3b16, as commit:9ecad4c9c2a2 but avoiding some allocations real 1m10.631s user 1m10.327s sys 0m0.180s (still broken?) commit:19f6832fdc8a, as commit:9ecad4c9c2a2 but with the arguments to v_add_with_gain supplied in the right order (that's what I'd broken!) real 1m28.957s user 1m28.437s sys 0m0.213s BQVEC and OPENMP commit:ac750e222ad3, result of merging openmp branch commit:62b7be1226d into bqvec branch commit:19f6832fdc8a real 0m44.650s user 2m19.997s sys 0m0.343s