Update ANSWERS.md

hw8/task1/ANSWERS.md

@@ -1,35 +1,54 @@
 # Proof of Work 2.0
 
+### Arten der Synchronisierung und Kommunikation
+
+Neben den MPSC-channels für Rückgabe der Solution und der Zeitstatistik, verwenden wir für mehrere Variablen den Typ [Arc](https://doc.rust-lang.org/std/sync/struct.Arc.html). Jeder Thread bekommt über einen *clone()*-Vorgang eine Referenz auf die selbe, gemeinsame Variable im Heap. Das sync-Flag haben wir über einen [AtomicBool](https://doc.rust-lang.org/std/sync/atomic/struct.AtomicBool.html), welcher von einem *Arc* gehalten wird gelöst. Über store(..) und load(..) lässt sich dann auf diesen 'bool' zugreifen.
+
+###  Performance-Gewinn *Single-Threaded vs Multi-Threaded*
+
+
+
+### Antworten
+
+#### Was ist der Unterschied zwischen einer logischen und einer physikalischen CPU?
+
+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.
 
 #### 1. Wie ist die Ausgabe von time zu interpretieren, wenn mehrere Threads laufen?
 
 Die user-time ist immer deutlich höher als die real-time.
-Das heißt, dass die Threads nicht nebenläufig, sondern parallel laufen.
+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% ist.
 
 #### 2. Welche unterschiedlichen Ergebnisse erhalten Sie bei der Option timings? Wie stehen diese im Zusammenhang mit den Ergebnissen von time?
 
-
-Die Option `timings` variiert stark von den Ergebnissen von **time**. Das unix-Kommando time bezieht die Ausführungszeit des gesamten Codes mt ein.
+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.
 Also auch Aufrufe von *sys-info* oder zum Beispiel das Parsen der Argumente, welches *clap* durchführt.
 
 #### 3. Welche quantitativen Auswirkungen hat die Synchronisierung (Warum)? Welche Auswirkungen haben Ihre zusätzlichen Parameter?
 
+Mit dem Synchronisierungsflag muss nur ein Producer eine Lösung finden, danach brechen die anderen Threads kontrolliert ihre Suche ab. Mit dem Wert hinter dem Parameter `--special` kann man die Häufigkeit dieser Abfrage (ob ein anderer Thread eine Lösung gefunden hat) steuern.
+
 #### 4. Wie variieren -s und -w die Messungen?
 
-Mit `-s` und `-v`:
+Bei der Suche nach Hash mit base = 42 und difficulty = "123456" und 10 threads:
+
+Mit `-s` und `-w`: 
+
+Sobald eim.
   ```text
-  Sum Loops in Producers:       66106870
-  Sum Duration in Producers:    25s / 25160ms / 25160747us
+  Sum Loops in Producers:       19019908
+  Sum Duration in Producers:    55s / 55585ms / 55585423us
   ```
+  
 
-Ohne `-s` und `-v`:
+Ohne `-s` und `-w`:
 
 Wartet der Consumer bis jeder Thread eine *Solution* gefunden hat. Dies ist sehr deutlich an den Loop-anzahl und der Zeit erkennbar.
   ```text
-  Sum Loops in Producers:       147581082
-  Sum Duration in Producers:    37s / 37244ms / 37244327us
+  Sum Loops in Producers:       60340756
+  Sum Duration in Producers:    114s / 114074ms / 114074341us
   ```
  
 #### 5. Welche sonstigen Arten der Synchronisierung bieten sich für die Problemstellung "Lösung gefunden (-s)" an? Was sind deren Vor- und Nachteile gegenüber Ihrer gewählten Lösung?
 
-Man könnte anstatt dem Arc und dem AtomicBool im Consumer aktiv alle Threads töten, sobald eine Lösung gefunden wurde. 
+Man könnte anstatt dem Arc und dem AtomicBool im Consumer aktiv alle Threads töten, sobald eine Lösung gefunden wurde. Das ist zwar schneller, aber es ist nicht mehr möglich auf die Threadlaufzeiten und Threadschleifendurchläufe zuzugreifen.