Link zu Bildern:
Der erste Eindruck war, daß der Prozessor fast immer 100% idle ist (RAM=4%). Wenn mal eine mittlere Aufgabe abläuft, sind es 97% idle. Ein Shell-Skript, das eine Großaufgabe startet, brachte im Mittel
73% idle, in der Last-Spitze 68% idle (s.u.).
Ein Vergleichstest
------------------ /usr: Festplatte /ram: RAM-Disc 20 GB Aufgabe für nur eine CPU. ================================================================================================ set key = 5ea949e19d45ef90b55c08d9689077d57bab4b96de209c9a2f0014d9dae96381 set ini = 6b0c376d2dc9fcdeb1e0143ff1cb80a7592cc787a665e6c36c6907007a0913b9
PC 2006 (4 GB ram, 2 CPUs, 3330 MHz):
------------------------------------- /usr/bin/time tar -cf /usr/u.tar /u 103.12 real 0.90 user 8.78 sys /usr/bin/time bish -c "dragon passwd; dragon $key $ini /usr/u.tar /usr/u.dragon" dragon: 5438935552 Bytes 504.62 real 47.93 user 14.94 sys /usr/bin/time bish -c "sha256 =3; sha256 /usr/u.tar" SHA3-256 (/usr/u.tar) = de33f2613045eb08a9ede459c1f6d6b3135a596584a0c80ea72d62ff05f0c914 406.94 real 403.23 user 2.91 sys
Workstation 2023:
----------------- /usr/bin/time tar -cf /ram/u.tar /u 1.98 real 0.13 user 1.85 sys /usr/bin/time ./bish -c "dragon passwd; dragon $key $ini /ram/u.tar /ram/u.dragon" dragon: 5570669568 Bytes 11.64 real 10.30 user 1.33 sys /usr/bin/time ./bish -c "sha256 =3; sha256 /ram/u.tar" 221.90 real 221.06 user 0.84 sys /usr/bin/time ./bish -c "sha256 =3; sha256 /usr/u.tar" 222.22 real 221.32 user 0.90 sys /usr/bin/time ./bish -c "sha256 =2; sha256 /ram/u.tar" 20.78 real 20.12 user 0.66 sys /usr/bin/time ./bish -c "sha256 =2; sha256 /usr/u.tar" 20.77 real 20.08 user 0.68 sys ================================================================================================
Die ersten beiden Tests weisen eine etwa 50-fache Geschwindigkeit der Workstation aus. Der letzte Test zeigt überraschend eine nur etwa doppelte Geschwindigkeit.
Offensichtlich benötigt der neue Keccak-Algorithmus (=3) eine etwa 11-fach längere Rechenzeit, gegenüber dem verbreiteten Algorithmus (=2). Dies dominiert hier völlig die Vorteile einer RAM-Disc. Der alte Prozessor hat immerhin 3330 MHz, der neue 3100 MHz als Basis. Der Neue ist tatsächlich nur etwa 2-fach schneller!, wenn es um intensivstes Abarbeiten von x86-Instruktionen in einem Kern geht.
Der Prozessor mit 16 Kernen (3100 MHz) gibt maximal und dauerhaft 270 W an Wärme ab. Der Prozessor mit 56 Kernen (1900 MHz) gibt maximal und dauerhaft 350 W an Wärme ab. Letzterer (6200 EUR) ist folglich nur um den Faktor 35/27 = 1,3 leistungsfähiger.
Der nachfolgende Shell-Skript-Inhalt (Großaufgabe) wurde mit dem Argument '12' aufgerufen ($1)(Anzahl Prozesse/CPUs): ================================================================================================ #!./bish
Wait() { ps -o command | grep -qm ' lib[0-9]%{1,3}' && return 0 return 1 }
Split() { local i=000 n=$1 z:09 l:09 c:09 r:09 l=$(list -f All | wc -l) [ $l -le $n ] && return 1 let "z=$l / $n" "r=$l % $n" echo "pkg=$l procore=$z rest=$r" list -f All | { for i to $n repeat do [ $i -eq $n ] && let "z+=r" c=0 >pkg$i while readl Z do echo "$Z" let "++c" "c>=z" && break done >< done } return 0 }
Proz() { local i=000 n=$1 for i to $n repeat do $skript pkg$i lib$i & done return 0 }
set -f set Z:.300 skript=$0 local i=000
[ $# -eq 0 -o $# -gt 2 ] && exit 1 [ $# -eq 1 ] && expr "$1" :: '^[0-9]%{1,3}$' || exit 2
if [ $# -eq 1 ] then Split $1 || exit 3 Proz $1 while Wait; do sleep 3; done >libsx.txt; >< for i to $1 repeat do cat lib$i >>libsx.txt remove pkg$i lib$i done else < $1 > $2 while readl Z do echo "*** $Z:" tar tvf "All/$Z" '*?/lib?*.[sa]*' done ><< fi
: ================================================================================================
Hinter 'then' befindet sich der Code der Manager-Instanz des Skripts. Hinter 'else' befindet sich der Code jedes der 12 Prozesse. Diese Prozesse werden in der Funktion 'Proz()' im Background gestartet. Das Skript ruft sich dazu 12-mal selbst auf ($0 enthält den Skript-Pfad). Die Funktion 'Split()' teilt die notwendigen Komponenten aufgeteilt jedem der 12 Prozesse zu. Die Anzahl der Argumente ($#)(1 oder 2) bestimmt, welche Instanz-Art vorliegt.
Im Verzeichnis 'All' (tar tvf) befinden sich ~33000 Installations-Packages (max 2,5 GB), mit einer Gesamtgröße von ~110 GB! Jede Package ist komprimiert. Kommando 'tar' muß folglich jede Package dekomprimieren und dann mittels eines Suchmusters jeweils alle dazu passenden Pfadnamen der enthaltenen Dateien ausgeben. Diese sind alle Library-Dateien (*.a *.so).
Diese Aufgabe wird bei n Prozessen ziemlich genau n-fach schneller erledigt! Ein Riesenvorteil - 15 Minuten sind weniger als 225 Minuten. Das ist schon eine ganz andere Arbeitsebene! Es bringt aber nichts, die Anzahl Prozesse größer zu wählen, als CPUs exklusiv verfügbar sind. Denn dann müßte der Scheduler unablässig von CPU zu CPU springen.
Zur Runtime war es so, daß 2 Minuten vor Schluß die Prozesse begannen, einzeln abzuspringen. Siehe Funktion 'Wait()'. Wenn das Warten beendet ist, werden alle temporären Dateien angehängt (>>) und gelöscht. Und die Manager-Instanz kann ebenfalls exit machen. Die Verteilung per Anzahl Zeilen ist folglich gut genug. Es muß das Konzept nicht auf andere Aufteilungsarten erweitert werden.