|
|
@@ -1,8 +1,8 @@
|
|
1
|
|
-Proof of Work 2.0
|
|
|
1
|
+# Proof of Work 2.0
|
|
2
|
2
|
|
|
3
|
3
|
### Performance-Gewinn *Single-Threaded vs Multi-Threaded*
|
|
4
|
4
|
|
|
5
|
|
-In der folgenden Tabelle sieht man sehr deutlich den Geschwindikeitsgewinn durch das Multithreading. Je länger die Difficulty ist, desto besser sieht man, dass durch verdopplung der Threads die reale Zeit ungefähr halbiert wird.
|
|
|
5
|
+In der folgenden Tabelle sieht man sehr deutlich den Geschwindigkeitsgewinn durch das Multithreading. Je länger die Difficulty ist, desto besser sieht man, dass durch Verdopplung der Threads die reale Zeit ungefähr halbiert wird.
|
|
6
|
6
|
|
|
7
|
7
|
| Difficulty | Single Threaded* | 2 Threads* | 4 Threads* |
|
|
8
|
8
|
| ---------- | -------------------------- | ------------------------- | ------------------------ |
|
|
|
@@ -24,16 +24,16 @@ Neben den MPSC-channels für Rückgabe der Solution und der Zeitstatistik, verwe
|
|
24
|
24
|
|
|
25
|
25
|
#### Was ist der Unterschied zwischen einer logischen und einer physikalischen CPU?
|
|
26
|
26
|
|
|
27
|
|
-Logische CPU-Kerne sind nur virtuell vorhanden und werden auf die physikalische CPU 'umgeleitet'. Sie werden vom Betriebssystem, insbesondere vom Scheduler gesehen und verwendet. Deshalb spielt es beim Multithreading bzw. auch beim Scheduling ein Rolle wie das Verhältnis von logischen und phsyikalischen CPUs ist.
|
|
|
27
|
+Logische CPU-Kerne sind nur virtuell vorhanden und werden auf die physikalische CPU 'umgeleitet'. Sie werden vom Betriebssystem, insbesondere vom Scheduler, gesehen und verwendet. Deshalb spielt es beim Multithreading bzw. auch beim Scheduling ein Rolle wie das Verhältnis von logischen und physikalischen CPUs ist.
|
|
28
|
28
|
|
|
29
|
29
|
#### Wie ist die Ausgabe von time zu interpretieren, wenn mehrere Threads laufen?
|
|
30
|
30
|
|
|
31
|
|
-Im Gegensatz zu einem Thread ist bei mehreren Threads die user-time immer deutlich höher als die real-time. (siehe Tabelle)
|
|
|
31
|
+Im Gegensatz zu einem Thread ist bei mehreren Threads die user-time immer deutlich höher als die real-time (siehe Tabelle).
|
|
32
|
32
|
Das heißt, dass die Threads nicht nebenläufig, sondern echt parallel laufen. Wenn man mit `-p` die Prozentangaben einschaltet, dann sieht man auch, dass die user-time deutlich über 100% liegt.
|
|
33
|
33
|
|
|
34
|
34
|
#### Welche unterschiedlichen Ergebnisse erhalten Sie bei der Option timings? Wie stehen diese im Zusammenhang mit den Ergebnissen von time?
|
|
35
|
35
|
|
|
36
|
|
-Die Option `timings` variiert unterschiedlich stark von den Ergebnissen von **time**. Das unix-Kommando time bezieht die Ausführungszeit des gesamten Codes mt ein. wenn man das Programm über `time cargo run --release...` aufruft, statt das erstellte binary, dann wird sogar die Compilezeit miteinberechnet.
|
|
|
36
|
+Die Option `timings` variiert unterschiedlich stark von den Ergebnissen von **time**. Das unix-Kommando time bezieht die Ausführungszeit des gesamten Codes mit ein. wenn man das Programm über `time cargo run --release...` aufruft, statt das erstellte binary, dann wird sogar die Compilezeit miteinberechnet.
|
|
37
|
37
|
Also auch Aufrufe von *sys-info* oder zum Beispiel das Parsen der Argumente, welches *clap* durchführt.
|
|
38
|
38
|
|
|
39
|
39
|
#### Welche quantitativen Auswirkungen hat die Synchronisierung (Warum)? Welche Auswirkungen haben Ihre zusätzlichen Parameter?
|
|
|
@@ -55,7 +55,7 @@ Der Thread, der die erste gültige *number* findet, setzt den gennanten AtomicBo
|
|
55
|
55
|
|
|
56
|
56
|
Ohne `-s` und `-w`:
|
|
57
|
57
|
|
|
58
|
|
-Wartet der Consumer bis jeder Thread eine *Solution* gefunden hat. Dies ist sehr deutlich an den Loop-anzahl und der Zeit erkennbar.
|
|
|
58
|
+Wartet der Consumer bis jeder Thread eine *Solution* gefunden hat. Dies ist sehr deutlich an Loopanzahl und Zeit erkennbar.
|
|
59
|
59
|
```text
|
|
60
|
60
|
Sum Loops in Producers: 60340756
|
|
61
|
61
|
Sum Duration in Producers: 114s / 114074ms / 114074341us
|
