From 3674d82bdf43008b292cff8618b1829ba49ee4e6 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Tue, 9 Jan 2024 23:34:05 +0100 Subject: [PATCH] Scheduler-test: next goal -- massively parallel work jobs Search processing pattern for massive parallel test. The goal is to get all cores into active processing most of the time, thus we need a graph with low dependency management overhead, which is also consistently wide horizontally to have several jobs in working state all of the time. The investigation aims at finding out about systematic overheads in such a setup. --- tests/vault/gear/scheduler-stress-test.cpp | 9 +- wiki/thinkPad.ichthyo.mm | 133 ++++++++++++++++++++- 2 files changed, 139 insertions(+), 3 deletions(-) diff --git a/tests/vault/gear/scheduler-stress-test.cpp b/tests/vault/gear/scheduler-stress-test.cpp index a67ebda7f..2e64aa9e8 100644 --- a/tests/vault/gear/scheduler-stress-test.cpp +++ b/tests/vault/gear/scheduler-stress-test.cpp @@ -328,7 +328,14 @@ namespace test { void generalFuckup() { - UNIMPLEMENTED("tbd"); + TestChainLoad<8> testLoad{64}; + testLoad.seedingRule(testLoad.rule().probability(0.6).maxVal(2)) + .pruningRule(testLoad.rule().probability(0.44)) + .setSeed(60) + .buildTopology() + .printTopologyDOT() + .printTopologyStatistics() + ; } diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 10bb80173..59837e57b 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -95887,8 +95887,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - + + @@ -95969,6 +95969,10 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + + + @@ -95982,6 +95986,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 + + + @@ -110766,6 +110773,128 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + + + + + + + + +

+ die ganzen Test zur Integration und zum Aufbau der Testanordnung haben die »chained load bursts« verwendet, ein hochgradig unregelmäßiges und abschnittsweise stark verknüpftes Pattern. Damit konnte ich in etwa die erwartete Parallelisierung beobachten, aber die Computational Load ist typischerweise doppelt so lang gelaufen wie kalibriert, während gleichzeitig permanent Koordinations-Aufwand zu leisten war. Deshalb wähle ich nun einen anderen Blickwinkel: Wie gut können wir die theoretisch vorhandene »Rechenkapazität« zum Einsatz bringen? Dafür braucht es ein möglichst einfaches Pattern, das aber hinreichend breit sein muß, um alle Kerne auszulasten. Ziel ist es, einen gleichmäßigen »Flow« von länger laufenden Rechen-Jobs zu generieren +

+ + + + + + + + + + + + + + +

+           TestChainLoad<8> testLoad{64}; +

+

+           testLoad.seedingRule(testLoad.rule().probability(0.6).maxVal(2)) +

+

+                   .pruningRule(testLoad.rule().probability(0.44)) +

+

+                   .setSeed(62) +

+

+                   .buildTopology() +

+

+                   ; +

+ + + + + + + + + + + + + + + +

+           TestChainLoad<8> testLoad{64}; +

+

+           testLoad.seedingRule(testLoad.rule().probability(0.6).maxVal(2)) +

+

+                   .pruningRule(testLoad.rule().probability(0.44)) +

+

+                   .setSeed(60) +

+

+                   .buildTopology() +

+

+                   ; +

+ + + + + + + + + + + + + + + +

+           TestChainLoad<8> testLoad{64}; +

+

+           testLoad.seedingRule(testLoad.rule().probability(0.6).minVal(2)) +

+

+                   .pruningRule(testLoad.rule().probability(0.44)) +

+

+                   .setSeed(55) +

+

+                   .buildTopology() +

+

+                   ; +

+ + + + + + + + + + + +