uebung2017-10/README.md

88 lines
4.2 KiB
Markdown
Raw Normal View History

2017-07-12 09:38:06 +00:00
Übungszettel 10
==============
Parallelismus & Nebenläufigkeit
Issue 1
-------
Im Modul `Parallel` finden Sie eine Funktion, die Sie noch von Zettel 3 kennen.
Zur Erinnerung: Die Funktion `nBesteEingaben` gibt Ihnen mit beliebiger numerischer Genauigkeit
diejenigen Eingaben (4-Tupel, jeweils mit Werten aus [-10,10]) zurück, für die eine
`komlizierteFunktion` maximal wird. Hierfür wird der komplizierten Funktion mithilfe von
List-Applicative (kartesisches Produkt) eine lange, beliebig dichte Liste möglicher Eingabewerte
2017-07-12 10:04:32 +00:00
zwischen `(-10,-10,-10,-10)` und `(10,10,10,10)` übergeben.
Bei einem Abstand von 0.5 ergeben sich damit 41^4 = 2 825 761 Berechnungen. Diese lohnt es sich zu parallelisieren!
2017-07-12 09:38:06 +00:00
2017-07-12 10:04:32 +00:00
Parallelisieren Sie die Funktion `nBesteEingaben`, mit mindestens drei verschiedenen Strategien für Lists (bzw. Lazy Lists) aus
2017-07-12 09:38:06 +00:00
[`Control.Parallel.Strategies`](https://hackage.haskell.org/package/parallel-3.2.1.1/docs/Control-Parallel-Strategies.html#v:evalList).
Um ihre Parallelisierung zu testen, verwenden Sie die folgenden Terminalbefehle:
```bash
stack exec -- MainParallel1 +RTS -N1 -s
stack exec -- MainParallel1 +RTS -N2 -s
stack exec -- MainParallel1 +RTS -N4 -s
stack exec -- MainParallel1 +RTS -N8 -s
```
2017-07-12 10:04:32 +00:00
`-Nx` steht für die Verwendung von x Kernen.
`MainParallelx` steht für die Verwendung der Strategie x.
2017-07-12 09:38:06 +00:00
Eine sinnvolle Parallelisierung erkennen Sie daran, dass die Berechnung schneller wird,
2017-07-12 10:04:32 +00:00
je mehr echte Kerne Sie für zur Verfügung stellen. Mindestens eine Strategie sollte in diesem
Sinne sinnvoll sein.
2017-07-12 09:38:06 +00:00
Notieren sie die Laufzeiten ihrer Versuche in einer Tabelle und geben sie den Speedup (`-N1`-Zeit/`-Nx`Zeit) an.
2017-07-12 10:04:32 +00:00
Nützliche Funktion: [`using :: a -> Strategy a -> a`](https://hackage.haskell.org/package/parallel-3.2.1.1/docs/Control-Parallel-Strategies.html#v:using)
2017-07-12 09:38:06 +00:00
Issue 2
-------
Sie werden bemerkt haben, dass der Speedup sich nicht linear mit der Anzahl der Kerne steigern lässt.
Nach [Amdahls Gesetz](https://de.wikipedia.org/wiki/Amdahlsches_Gesetz) ist bei vielen Kernen der nicht-parallelisierte Part
(in unserem Fall das sortieren) für die schlechte Performance verantwortlich.
2017-07-12 10:04:32 +00:00
Da wir uns nur für die Top `n` eingaben interessieren, schreiben Sie eine Funktion
2017-07-12 09:38:06 +00:00
```haskell
topn :: Int -> [a] -> [a]
```
welche nach `n` Einsortierungsversuchen das zu sortierende Element verwirft (z.B. als Liste oder Array) und somit die Sortierung
frühestmöglich abbricht.
Füllen sie die Speedup-Tabelle erneut aus. Was ändert sich?
Issue 3
-------
Sie besitzen eine Bank und sollen Überweisungen programmieren. Sie finden in `Banking.hs` alles fertig. Nur noch die `debit`-Funktion muss geschrieben werden,
2017-07-12 10:04:32 +00:00
die von dem ersten auf das zweite Konto überweist.
2017-07-12 09:38:06 +00:00
Im Szenario der Main-Funktionen hat die Bank 10 verschiedene Server, die gleichzeitig dieselbe Transaktion auf der Datenbank ausführen wollen
(also haben sie mehrere "Banken" in der Main, die auch alle etwas ausgeben, aber alle zeigen denselben Kontostand, da die Konten selbst nur 1x existieren).
2017-07-12 10:04:32 +00:00
Führen Sie anschließend `MainBanking1` und `MainBanking2` aus. Was können sie beobachten? Wie kommt es zu den Ergebnissen?
2017-07-12 09:38:06 +00:00
2017-07-12 10:04:32 +00:00
Hint (optional!): Mittels `stack exec -- MainBanking1 +RTS -ls` können Sie ein eventlog ausgeben lassen, welches Sie mittels `threadscope` (`stack install threadscope`) ansehen können.
2017-07-12 09:38:06 +00:00
2017-07-12 10:04:32 +00:00
Was passiert, wenn Sie dies mit `-N1` ausführen? Wieso?
2017-07-12 09:38:06 +00:00
Issue 4
-------
2017-07-12 10:04:32 +00:00
Da Sie in Aufgabe 3 in Probleme gelaufen sind (sind Sie doch, oder? ;) ), benutzen Sie hier statt `MVar`s die STM-eigenen `TMVar`s.
2017-07-12 09:38:06 +00:00
2017-07-12 10:04:32 +00:00
In `STMBanking.hs` finden Sie die gleiche Situation vor - nur müssen Sie hier mit `STM` statt mit `MVar` arbeiten.
2017-07-12 09:38:06 +00:00
2017-07-12 10:04:32 +00:00
Führen Sie anschließend MainSTMBanking1 und MainSTMBanking2 aus. Was können Sie beobachten? Inwiefern unterscheiden sich die Ergebnisse zu den `MVar`s?
2017-07-12 09:38:06 +00:00
2017-07-12 10:04:32 +00:00
Hint (optional!): Mittels `stack exec -- MainBanking1 +RTS -ls` können Sie ein eventlog ausgeben lassen, welches Sie mittels `threadscope` (`stack install threadscope`) ansehen können.
2017-07-12 09:38:06 +00:00
2017-07-12 10:04:32 +00:00
Was passiert, wenn Sie dies mit `-N1` ausführen? Wieso?
2017-07-12 09:38:06 +00:00
2017-07-12 10:04:32 +00:00
Wo sind die Unterschiede zu `MVar`s (Performance, Einfachheit der Programmierung, Resistenz gegen Programmierfehler, ..)? Beschreiben Sie kurz wie sich ihre Probleme mit
der jeweiligen Implementation anfühlten und wieso Sie welche Lösung selbst bevorzugen würden.
2017-07-12 09:38:06 +00:00