H
Helmut Schellong
Guest
Link zu Bildern: https://magentacloud.de/s/5dzanoPdLwKaoS9
Prozessor: Xeon 3435X, 16 Kerne, 32 CPUs, Basis= 3100 MHz.
RAM: 128 GB
Das UEFI-BIOS verhält sich leider nicht deterministisch!
Ich vermute, der Speicher-Chip des UEFI ist defekt.
Ich habe einen Umtausch des Mainboards initiiert.
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
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
:
================================================================================================
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.
--
Mit freundlichen GrüÃen
Helmut Schellong
Prozessor: Xeon 3435X, 16 Kerne, 32 CPUs, Basis= 3100 MHz.
RAM: 128 GB
Das UEFI-BIOS verhält sich leider nicht deterministisch!
Ich vermute, der Speicher-Chip des UEFI ist defekt.
Ich habe einen Umtausch des Mainboards initiiert.
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
}
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
:
================================================================================================
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.
--
Mit freundlichen GrüÃen
Helmut Schellong