+ und auch steady_clock statt system_clock verwendet, sowie einen Adapter um das Test-Subjekt gelegt (um flexibler zu sein in den akzeptierten Signaturen) +
+ ++ commit 28b39002846aba9ef3dab18dae10f67fa8b063dd +
++ Author: Ichthyostega <prg@ichthyostega.de> +
++ Date: Sat Jul 22 01:54:25 2023 +0200 +
++ +
++ Block-Flow: final adjustments from performance test (closes: #1311) +
++ +
++ Further extensive testing with parameter variations, +
++ using the test setup in `BlockFlow_test::storageFlow()` +
++ +
++ - Tweaks to improve convergence under extreme overload; +
++ sudden load peaks are now accomodated typically < 5 sec +
++ +
++ - Make the test definition parametric, to simplify variations +
++ +
++ - Extract the generic microbenchmark helper function +
++ +
++ - Documentation +
+ + ++ ___Microbenchmark____ +
++ noAlloc : 57.1625 +
++ heapAlloc : 68.9836 +
++ sharedAlloc : 243.961 +
++ blockFlow : 386.459 +
++ _____________________ +
++ +
++ instances.... 360000 +
++ fps.......... 200 +
++ Activities/s. 2000 +
++ Epoch(expect) ≺225ms≻ +
++ Epoch (real) ≺224ms≻ +
++ cnt Epochs... 3 +
++ alloc pool... 10 +
+ + ++ ___Microbenchmark____ +
++ noAlloc : 9.52497 +
++ heapAlloc : 22.5513 +
++ sharedAlloc : 96.7604 +
++ blockFlow : 11.2576 +
++ _____________________ +
++ +
++ instances.... 360000 +
++ fps.......... 200 +
++ Activities/s. 2000 +
++ Epoch(expect) ≺225ms≻ +
++ Epoch (real) ≺226ms≻ +
++ cnt Epochs... 4 +
++ alloc pool... 10 +
+ + ++ inzwischen kann die GATE-Activity den Deadline-Check für eine Epoch machen; das kann ich nicht so ohne weiteres backporten +
+ + ++ ___Microbenchmark____ +
++ noAlloc : 58.0486 +
++ heapAlloc : 72.2743 +
++ sharedAlloc : 231.007 +
++ blockFlow : 245.747 +
++ _____________________ +
++ +
++ instances.... 360000 +
++ fps.......... 200 +
++ Activities/s. 2000 +
++ Epoch(expect) ≺225ms≻ +
++ Epoch (real) ≺224ms≻ +
++ cnt Epochs... 4 +
++ alloc pool... 10 +
+ + ++ ___Microbenchmark____ +
++ noAlloc : 9.49421 +
++ heapAlloc : 23.7542 +
++ sharedAlloc : 97.4423 +
++ blockFlow : 10.7804 +
++ _____________________ +
++ +
++ instances.... 360000 +
++ fps.......... 200 +
++ Activities/s. 2000 +
++ Epoch(expect) ≺225ms≻ +
++ Epoch (real) ≺224ms≻ +
++ cnt Epochs... 3 +
++ alloc pool... 10 +
+ + ++ ___Microbenchmark____ +
++ noAlloc : 0.0551005 +
++ heapAlloc : 0.0653065 +
++ sharedAlloc : 0.222995 +
++ blockFlow : 0.251686 +
++ _____________________ +
++ +
++ instances.... 360000 +
++ fps.......... 200 +
++ Activities/s. 2000 +
++ Epoch(expect) ≺225ms≻ +
++ Epoch (real) ≺224ms≻ +
++ cnt Epochs... 4 +
++ alloc pool... 10 +
+ + ++ ___Microbenchmark____X +
++ noAlloc : 0.00914207 +
++ heapAlloc : 0.0227815 +
++ sharedAlloc : 0.0985881 +
++ blockFlow : 0.140562 +
++ _____________________ +
++ +
++ instances.... 360000 +
++ fps.......... 200 +
++ Activities/s. 2000 +
++ Epoch(expect) ≺225ms≻ +
++ Epoch (real) ≺224ms≻ +
++ cnt Epochs... 4 +
++ alloc pool... 10 +
+ + ++ ___Microbenchmark____ +
++ noAlloc : 0.0540774 +
++ heapAlloc : 0.0709439 +
++ sharedAlloc : 0.226855 +
++ blockFlow : 0.401036 +
++ _____________________ +
++ +
++ instances.... 360000 +
++ fps.......... 200 +
++ Activities/s. 2000 +
++ Epoch(expect) ≺225ms≻ +
++ Epoch (real) ≺226ms≻ +
++ cnt Epochs... 4 +
++ alloc pool... 10 +
+ + ++ ___Microbenchmark____ +
++ noAlloc : 0.00942346 +
++ heapAlloc : 0.0220902 +
++ sharedAlloc : 0.0973145 +
++ blockFlow : 0.130734 +
++ _____________________ +
++ +
++ instances.... 360000 +
++ fps.......... 200 +
++ Activities/s. 2000 +
++ Epoch(expect) ≺225ms≻ +
++ Epoch (real) ≺224ms≻ +
++ cnt Epochs... 3 +
++ alloc pool... 10 +
+ + ++ sowohl die Umstellung des Threadwrappers, alsauch das automatische Adaptieren der Test-Lambdas betrifft nur die anderen Funktionen; auch damals habe ich bereits per std::Chrono gemessen, und der Unterschied system_clock vs. steady_clock scheint keinen Einfluß zu haben +
+ + ++ bestätigt: mit komplettem Release-Build läuft auch der aktuelle Code schnell(er) +
+ + ++ ___Microbenchmark____ +
++ noAlloc : 0.00916021 +
++ heapAlloc : 0.0228476 +
++ sharedAlloc : 0.0984637 +
++ blockFlow : 0.0174424 +
++ _____________________ +
++ +
++ instances.... 360000 +
++ fps.......... 200 +
++ Activities/s. 2000 +
++ Epoch(expect) ≺225ms≻ +
++ Epoch (real) ≺224ms≻ +
++ cnt Epochs... 4 +
++ alloc pool... 10 +
+ + ++ ___Microbenchmark____ +
++ noAlloc : 0.00926561 +
++ heapAlloc : 0.0232462 +
++ sharedAlloc : 0.0964142 +
++ blockFlow : 0.0314077 +
++ _____________________ +
++ +
++ instances.... 360000 +
++ fps.......... 200 +
++ Activities/s. 2000 +
++ Epoch(expect) ≺225ms≻ +
++ Epoch (real) ≺223ms≻ +
++ cnt Epochs... 3 +
++ alloc pool... 10 +
+ + ++ die neuerlichen Änderungen führen zu einer deutlichen Verbesserung +
+ + ++ ___Microbenchmark____ +
++ noAlloc : 0.00921847 +
++ heapAlloc : 0.0234061 +
++ sharedAlloc : 0.0969127 +
++ blockFlow : 0.0240378 +
++ _____________________ +
++ +
++ instances.... 360000 +
++ fps.......... 200 +
++ Activities/s. 2000 +
++ Epoch(expect) ≺225ms≻ +
++ Epoch (real) ≺226ms≻ +
++ cnt Epochs... 4 +
++ alloc pool... 10 +
+ + ++ jetzt (nur noch) +22% Performance-Gewinn +
+ + ++ denn im regulären Betrieb sollen Jobs immer aus einem Planungs-Job heraus eingestellt werden +
+ + +