Poszły konie po betonie

Gdy w 1967 Gene Amdahl pisał artykuł, który dał początek prawu Amdahla, zaczął go z grubej rury: “Przez ponad dekadę prorocy głosili, że osiągnięto kres możliwości organizacji pojedynczego komputera i że prawdziwie znaczące postępy mogą być poczynione tylko łącząc komputery” (tłumaczenie - i uproszczenie - cytatu moje). W 1967. Cóż. Teraz, pół wieku później, faktycznie ciężko się z tymi prorokami nie zgodzić. Moore sam stwierdził, że jego “prawo” umrze w ciągu dekady w marcu 2015., Popatrzmy zatem jak możemy wycisnąć coś z naszych maszyn i co nam może w tym przeszkodzić i dlaczego.

Czyli:

Podstawowe (i nie tylko) informacje o tym jak procesory pracują.
Kod na wiele procków na kilka sposobów.
Paradygmaty takiego kodowania: ich siły i słabości.
Różne języki.
Dobre praktyki.
Ciekawe biblioteki.

Transcript

1. Poszły konie po betonie
   Czyli jak utrzymać lejce gdy ciągniesz na wiele
   procków? Co przeszkadza, co ratuje i co w Jawie
   piszczy.
   @LAFK_pl
   

   View Slide

2. Thank you Joe!
   @LAFK_pl
   1950 - 2019
   

   View Slide

3. Agenda
   ●
   O mnie
   ●
   Najważniejsze
   ●
   Jak co działa
   – Sprzęt, jądro, planista, system, wielowątkowość
   ●
   Co przeszkadza i co z tym zrobić
   ●
   Źródła
   ●
   Podsumowanie
   @LAFK_pl
   

   View Slide

4. O mnie
   @LAFK_pl
   Konsultant @
   Tomasz Borek
   Założyciel @ MITORIDAFI
   Wkrótce: (nie)bezpieczna Jawa!
   https://www.linkedin.com/in/tjborek/
   

   View Slide

5. Agenda
   ●
   O mnie
   ●
   Najważniejsze
   ●
   Jak co działa
   – Sprzęt, jądro, planista, system, wielowątkowość
   ●
   Co przeszkadza i co z tym zrobić
   ●
   Źródła
   ●
   Podsumowanie
   @LAFK_pl
   

   View Slide

6. Najważniejsze
   @LAFK_pl
   TestNG, OpenHFT
   itp., Awaitility,
   JVSTM,
   Quasar/Pulsar, Akka
   ●
   Wątki i zamki
   → STM →
   CSP / Aktory
   ●
   Książki,
   publikacje
   ●
   Linux: lsof,
   pidstat,
   vmstat...
   ●
   Von Neumann
   → Moore →
   Amdahl → USL
   ●
   Sprzęt:
   procki,
   MESI
   

   View Slide

7. Najważniejsze
   @LAFK_pl
   ●
   Kod
   ●
   Dokumentacja
   ●
   Wikipedia
   ●
   man
   ●
   How do it know
   ●
   Jak działa sprzęt
   ●
   Zrozumieć
   programowanie
   ●
   Jak działa Linux
   ●
   JCIP
   ●
   Sztuka programowania
   wieloprocesorowego
   ●
   SCKRK
   

   View Slide

8. Agenda
   ●
   O mnie
   ●
   Najważniejsze
   ●
   Jak co działa
   – Sprzęt, jądro, planista, system, wielowątkowość
   ●
   Co przeszkadza i co z tym zrobić
   ●
   Źródła
   ●
   Podsumowanie
   @LAFK_pl
   @LAFK_pl
   

   View Slide

9. View Slide

10. Architektura von Neumanna
    ●
    Wejście
    ●
    Procesor
    ●
    Pamięć
    ●
    Wyjście
    @LAFK_pl Konsultant @
    Założyciel @ MITORIDAFI
    

    View Slide

11. Jak wykonuje się program?
    CPU
    BEGIN
    int a = 0;
    int b = 0;
    readln(”Podaj a: ”, a);
    readln(”Podaj b: ”, b);
    writeln(a+b);
    END.
    @LAFK_pl Konsultant @
    Założyciel @ MITORIDAFI
    

    View Slide

12. Jak wykonuje się program?
    CPU: int a = 0;
    BEGIN
    int a = 0;
    int b = 0;
    readln(”Podaj a: ”, a);
    readln(”Podaj b: ”, b);
    writeln(a+b);
    END.
    @LAFK_pl Konsultant @
    Założyciel @ MITORIDAFI
    

    View Slide

13. Jak wykonuje się program?
    CPU: int b = 0;
    BEGIN
    int a = 0;
    int b = 0;
    readln(”Podaj a: ”, a);
    readln(”Podaj b: ”, b);
    writeln(a+b);
    END.
    Pamięć: a → 0xe13 = 0x00
    @LAFK_pl Konsultant @
    Założyciel @ MITORIDAFI
    

    View Slide

14. Słowo o sprzęcie
    CPU: int b = 0;
    BEGIN
    int a = 0;
    int b = 0;
    readln(”Podaj a: ”, a);
    readln(”Podaj b: ”, b);
    writeln(a+b);
    END.
    SZYNA
    Pamięć: a → 0xe13 = 0x00
    @LAFK_pl Konsultant @
    Założyciel @ MITORIDAFI
    

    View Slide

15. Słowo o sprzęcie
    CPU: wiele komponentów
    Czas dostępu: 1-9ns
    Kolejka instrukcji – rejestr
    Czas dostępu: 1ns
    SZYNA!!!
    Wąskie
    gardło
    Pamięć zdolna do losowego odczytu
    Czas dostępu: ~100ns
    @LAFK_pl Konsultant @
    Założyciel @ MITORIDAFI
    

    View Slide

16. Jak działa sprzęt?
    @LAFK_pl Konsultant @
    Założyciel @ MITORIDAFI
    

    View Slide

17. Prosty procesor a płyta?
    @LAFK_pl Konsultant @
    Założyciel @ MITORIDAFI
    

    View Slide

18. Jak działa wielowątkowość?
    @LAFK_pl
    FF startuje FF dalej
    FF karta 1
    FF karta 2
    FF karta n
    

    View Slide

19. Współbieżność a równoległość
    1. Jakiś wątek idzie do przodu
    2. Możliwość zagłodzenia
    3. W Jawie nie zawsze takie znaczenie
    1. Niezależni wykonawcy
    2. Architektura staje się kluczowa
    3. Wiele możliwych porządków programu
    @LAFK_pl
    

    View Slide

20. Jak działa współbieżność?
    @LAFK_pl
    FF startuje FF dalej
    FF karta 1
    FF karta 2
    FF karta n
    

    View Slide

21. Jak działa równoległość?
    @LAFK_pl
    FF startuje FF dalej
    FF karta 1
    FF karta 2
    FF karta n
    

    View Slide

22. Jak działa równoległość? (2)
    @LAFK_pl
    FF startuje FF dalej
    FF karta 1
    FF karta 2
    FF karta n
    Możliwe są różne porządki programu
    

    View Slide

23. Jak działa przydział zasobów?
    @LAFK_pl
    FF startuje FF dalej
    FF karta 1
    FF karta 2
    FF karta n
    Możliwe są różne porządki programu
    Czemu
    te dwa?
    

    View Slide

24. Jak działa planista?
    ●
    O(n) → O(1) → CFS (kernel 2.6.23, X.2007)
    ●
    Dostajesz kwant czasu
    ●
    Czerwono-czarne drzewo wg czasu
    A priorytet procesu?
    @LAFK_pl
    

    View Slide

25. Planista i priorytet
    ●
    CFS; `man nice` → <-20; 19>
    ●
    Dostajesz kwant czasu zawsze
    ●
    Priorytet obniża czas,
    ●
    Im niższy, tym bardziej: 120 + nice = <100, 139>
    ●
    Czerwono-czarne drzewo wg czasu
    @LAFK_pl
    

    View Slide

26. @LAFK_pl
    

    View Slide

27. Jak działa pamięć?
    @LAFK_pl
    

    View Slide

28. Adres instrukcji?
    @LAFK_pl Konsultant @
    Założyciel @ MITORIDAFI
    

    View Slide

29. RAMie, gdzie dane?
    @LAFK_pl Konsultant @
    Założyciel @ MITORIDAFI
    

    View Slide

30. Jak działają potoki?
    ●
    Pobierz (fetch)
    ●
    Odcyfruj (decode)
    ●
    Czasem też pobierz argumenty
    (operands fetch) czy rejestry
    ●
    Wykonaj (execute)
    ●
    Zapisz (store, write-back, retire)
    ●
    Im pełniejsza rura, tym szybsze
    przepychanie (prostsze czipy)
    ●
    Intel Core miał 14 etapów, nie 4, Nehalem >30 OIDP
    ●
    Idealnie, 1 instrukcja to 1 cykl
    

    View Slide

31. @LAFK_pl
    Procesor wielordzeniowy?
    1 per czip, wspólne
    wiele per czip
    Intel: QPI, +40ns
    

    View Slide

32. MESI
    Czytaj jak angielskie „messy”
    @LAFK_pl
    ●
    Na wyłączność (E)
    – procek czyta → wciąż
    E
    – procek pisze →
    zmienione (M)
    – szyna czyta →
    dzielone (S)
    

    View Slide

33. MESI
    Czytaj jak angielskie „messy”
    @LAFK_pl
    ●
    Usuwasz gdy:
    – Po zmianie szyna pisze
    – Dzielone i szyna pisze
    – Masz usunąć a szyna
    pisze i czyta
    – Wyłączne a szyna pisze
    ●
    I→E gdy procek pisze
    

    View Slide

34. Intelowskie procesory
    1. Modele: Core i3, i5, i7 (i i9)
    2. Architektury: Nehalem, Sandy/Ivy Bridge,
    Haswell, Broadwell, Skylake, Kaby lake
    3. Bez rewolucji, wciąż monopolista
    4. Kuźnie półprzewodników
    5. OOOE → HyperThreading
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

35. Sandy Bridge
    1. Cykl < ~4 cykle < ~12 cykli < ~40-60 cykli
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

36. Sandy Bridge
    1. Cykl < ~4 cykle < ~12 cykli < ~40-60 cykli
    2. L3 to max ~60 cykli (~20ns, max bo zmienione
    w L3 a nie w pamięci „dirty hit”)
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

37. Sandy Bridge
    1. Cykl < ~4 cykle < ~12 cykli < ~40-60 cykli
    2. L3 to max ~60 cykli (~20ns, max bo zmienione
    w L3 a nie w pamięci „dirty hit”)
    3. Szyna QPI ~40ns
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

38. Sandy Bridge
    1. Cykl < ~4 cykle < ~12 cykli < ~40-60 cykli
    2. L3 to max ~60 cykli (~20ns, max bo zmienione
    w L3 a nie w pamięci „dirty hit”)
    3. Szyna QPI ~40ns
    4. MC per gniazdo, czyli QPI problem przy
    rozmowach między gniazdami
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

39. Sandy Bridge
    1. Cykl < ~4 cykle < ~12 cykli < ~40-60 cykli
    2. L3 to max ~60 cykli (~20ns, max bo zmienione
    w L3 a nie w pamięci „dirty hit”)
    3. Szyna QPI ~40ns
    4. MC per gniazdo, czyli QPI problem przy
    rozmowach między gniazdami
    5. Po Nehalemie (czyli Sandy Bridge i dalsze) na
    czipie jest też PCI-express, 1GB/s przy PCI3
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

40. Sandy Bridge
    1. Cykl < ~4 cykle < ~12 cykli < ~40-60 cykli
    2. L3 to max ~60 cykli
    3. Szyna QPI ~40ns
    4. MC per gniazdo,
    5. PCI-express na czipie
    6. Sandy Bridge NIE jest w pełni potokowy!
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

41. Hiperwątkowość
    1. Udawany procesor dla SO
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

42. Hiperwątkowość
    1. Udawany procesor dla SO
    2. W rzeczywistości duplikowana infra, nie procek
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

43. Hiperwątkowość
    1. Udawany procesor dla SO
    2. W rzeczywistości duplikowana infra, nie
    procek:
    1. Flagi procka
    2. Rejestry ogólnego przeznaczenia
    3. Rejestry kontrolne
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

44. Hiperwątkowość
    1. Udawany procesor dla SO
    2. W rzeczywistości duplikowana infra, nie
    procek:
    1. Flagi procka
    2. Rejestry ogólnego przeznaczenia
    3. Rejestry kontrolne
    3. Dzięki temu można ładować do procków z
    dwóch kolejek, czyli potoki poza kolejnością
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

45. Hiperwątkowość
    1. Udawany procesor dla SO
    2. W rzeczywistości duplikowana infra, nie
    procek:
    1. Flagi procka
    2. Rejestry ogólnego przeznaczenia
    3. Rejestry kontrolne
    3. Dzięki temu można ładować do procków z
    dwóch kolejek, czyli potoki poza kolejnością
    @LAFK_pl
    Założyciel @ MITORIDAFI
    M
    oże
    obniżyć
    w
    ydajność!
    

    View Slide

46. @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

47. @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

48. Jak co działa: sprzęt
    ●
    Procek jest szybki, pamięć wolna (główna mniej niż dyskowa)
    ●
    Wąskie gardło von Neumanna
    – Pytanie pamięci gdzie dane a potem o dane
    – Wielowątkowość czy pamięć podręczna pozwala to ukryć
    – Potoki, hiperwątki, makro- i mikroinstrukcje itp. też
    ●
    Pamięci podręczne:
    – Per rdzeń (tylko rdzeń widzi)
    – Per czip (wszyscy widzą)
    – Różne wielkości
    – Jednostką danych są linie! Nie bajty.
    – Wymiana danych wg MESI, instrukcje barier sygnałem
    @LAFK_pl
    

    View Slide

49. Jak co działa: system
    ●
    System:
    – Proces ma stan (bity w pamięci)
    – Program użytkownika→ Jądro → Sprzęt
    – Planista wywłaszcza / przydziela
    ●
    Wielowątkowość
    – Współbieżnie lub równolegle, zależnie od ilości
    wykonawców
    – Problem widoczności
    @LAFK_pl
    

    View Slide

50. Agenda
    ●
    O mnie
    ●
    Najważniejsze
    ●
    Jak co działa
    – Sprzęt, jądro, planista, system, wielowątkowość
    ●
    Co przeszkadza i co z tym zrobić
    ●
    Źródła
    ●
    Podsumowanie
    @LAFK_pl
    

    View Slide

51. Wąskie gardło von Neumanna
    CPU: wiele komponentów
    Czas dostępu: 1-9ns
    Kolejka instrukcji – rejestr
    Czas dostępu: 1ns
    SZYNA!!!
    Wąskie
    gardło
    Pamięć zdolna do losowego odczytu
    Czas dostępu: ~100ns
    @LAFK_pl Konsultant @
    Założyciel @ MITORIDAFI
    

    View Slide

52. https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html
    Czas dostępu do danych
    

    View Slide

53. Hiperwątkowość
    1. Udawany procesor dla SO
    2. W rzeczywistości duplikowana infra, nie
    procek:
    1. Flagi procka
    2. Rejestry ogólnego przeznaczenia
    3. Rejestry kontrolne
    3. Dzięki temu można ładować do procków z
    dwóch kolejek, czyli potoki poza kolejnością
    @LAFK_pl
    Założyciel @ MITORIDAFI
    M
    oże
    obniżyć
    w
    ydajność!
    

    View Slide

54. Hiperwątkowość
    1.W skrócie: dwa źródła instrukcji dla procka
    2.Mając mocno matematyczne obliczenia
    3.Nie pomaga! Kontestacja, rywalizacja o zasoby
    4.Dobre przy rozgałęzionym kodzie
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

55. Potoki poza kolejnością
    ●
    W kolejności za wolno, zatem poza
    ●
    Cały czas wąskie gardło von Neumanna
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

56. Potoki poza kolejnością
    ●
    W kolejności za wolno, zatem poza
    ●
    Cały czas wąskie gardło von Neumanna
    ●
    Ale czasem też kwestia długotrwałej operacji
    ●
    Dzielenie, zmiennoprzecinkowość, gniazda
    procków i wymiana danych via QPI...
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

57. Potoki poza kolejnością
    ●
    W kolejności za wolno, zatem poza
    ●
    Cały czas wąskie gardło von Neumanna
    ●
    Ale czasem też kwestia długotrwałej operacji
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

58. Potoki w kolejności?
    ●
    W kolejności za wolno, zatem poza
    ●
    Cały czas wąskie gardło von Neumanna
    ●
    Ale czasem też kwestia długotrwałej operacji
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

59. Potoki poza kolejnością!
    ●
    W kolejności za wolno, zatem poza
    ●
    Cały czas wąskie gardło von Neumanna
    ●
    Ale czasem też kwestia długotrwałej operacji
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

60. 3 typy problemów z danymi
    ●
    WAW – write after write (I
    2
    →I
    4
    )
    ●
    RAW – read after write (I
    2
    →I
    3
    )
    ●
    WAR – write after read (I
    3
    →I
    4
    )
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

61. 3 typy problemów z danymi
    ●
    WAW – write after write (I
    2
    →I
    4
    )
    ●
    RAW – read after write (I
    2
    →I
    3
    )
    ●
    WAR – write after read (I
    3
    →I
    4
    )
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

62. 3 typy problemów z danymi
    ●
    WAW – write after write (I
    2
    →I
    4
    )
    ●
    RAW – read after write (I
    2
    →I
    3
    )
    ●
    WAR – write after read (I
    3
    →I
    4
    )
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

63. @LAFK_pl
    Widoczność
    NIE
    widać
    L3: MESI i widać
    Wiele gniazd opóźni
    MESI!
    

    View Slide

64. Ratunkiem dla OOOE i widoczności
    ●
    Sprzęt:
    ●
    Bąbel, zmiana nazw rejestrów, `forwarding`
    ●
    Algorytm szeregujący (Tomasulo)
    ●
    BUFORY i BARIERY – model spójności pamięci
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

65. Ratunkiem dla OOOE i widoczności
    ●
    Sprzęt:
    ●
    Bąbel, zmiana nazw rejestrów, `forwarding`
    ●
    Algorytm szeregujący (Tomasulo)
    ●
    BUFORY i BARIERY – model spójności pamięci
    ●
    Program:
    ●
    Model spójności pamięci: happens-before, final, synchronized,
    volatile
    ●
    Synchronizacja: zamki, atomowość, inne konstrukty
    ●
    Czekanie, powiadomienia
    ●
    Zmiana programu: uniezależnienie operacji, MVCC
    @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

66. @LAFK_pl
    Prawo Amdahla
    

    View Slide

67. @LAFK_pl
    Matma prawa Amdahla
    ●
    program potrzebuje 100 minut (1 wykonawca)
    ●
    część nie do zrównoleglenia zajmuje 5 minut
    ●
    czyli MOŻNA zrównoleglić 95% programu
    ●
    ile procków nie rzucimy, 5 minut nie
    przeskoczymy
    ●
    przyspieszenie =< 1/(1 -
    ułamekNieszeregowy)
    Tutaj: 1/(1-95%)=100/5=20
    

    View Slide

68. Ratunkiem...
    ●
    Struktura danych: HashMap →
    ConcurrentHashMap → wyspecjalizowana
    mapa (z Koloboke czy OpenHFT czy...)
    @LAFK_pl
    

    View Slide

69. Ratunkiem...
    ●
    Struktura danych: HashMap →
    ConcurrentHashMap → wyspecjalizowana
    mapa (z Koloboke czy OpenHFT czy...)
    ●
    Algorytm: A* czy sort przez scalanie → w-
    wątkowe wersje → test algorytmu +CALem
    @LAFK_pl
    

    View Slide

70. Ratunkiem...
    ●
    Struktura danych: HashMap →
    ConcurrentHashMap → wyspecjalizowana
    mapa (z Koloboke czy OpenHFT czy...)
    ●
    Algorytm: A* czy sort przez scalanie → w-
    wątkowe wersje → test algorytmu +CALem
    @LAFK_pl
    

    View Slide

71. Ratunkiem...
    ●
    Struktura danych: HashMap →
    ConcurrentHashMap → wyspecjalizowana
    mapa (z Koloboke czy OpenHFT czy...)
    ●
    Algorytm: A* czy sort przez scalanie → w-
    wątkowe wersje → test algorytmu +CALem
    ●
    API: Random → ThreadLocalRandom, Date →
    LocalDate…
    @LAFK_pl
    

    View Slide

72. Ratunkiem...
    ●
    Struktura danych: HashMap →
    ConcurrentHashMap → wyspecjalizowana
    mapa (z Koloboke czy OpenHFT czy...)
    ●
    Algorytm: A* czy sort przez scalanie → w-
    wątkowe wersje → test algorytmu +CALem
    ●
    API: Random → ThreadLocalRandom, Date →
    LocalDate…
    @LAFK_pl
    

    View Slide

73. View Slide

74. Ratunkiem...
    ●
    Nie miej stanu, bezstanowość
    ●
    Niezmienność, niemutowalność
    ●
    Nie dziel stanu (aktory, MVCC)
    ●
    Kodzenie bezpieczne wątkowo
    ●
    Zmienne lokalne dla wątku
    ●
    ThreadLocal
    @LAFK_pl
    

    View Slide

75. @LAFK_pl
    Prawo Uniwersalnej Skalowalności
    

    View Slide

76. Matma za USL?
    P(N) = N / (1 + α(N – 1) + ((β* N) * (N – 1)))
    P = przepustowość
    N = ilość procesorów (użytkowników w apce)
    α = cena rywalizacji (np. kolejkowanie)
    β = cena spójności (synchro i opóźnienia)
    @LAFK_pl
    

    View Slide

77. @LAFK_pl
    ●
    Wątki i zamki nie skalują się tak dobrze
    ●
    MapReduce alias ForkJoin
    ●
    STM i CSP – Quasar, Pulsar, Clojure, Haskell
    ●
    Aktorzy alias Akka, Quasar, Pulsar (Clojure) lub
    Erlang
    ●
    Korutyny – Go
    ●
    Równoległość danych, architektura lambda...
    Ratunkiem inne paradygmaty
    

    View Slide

78. Model Aktorowy
    ●
    Wszystko jest aktorem
    ●
    Niech się pali, niech się wali
    ●
    Asynchroniczny przekaz wiadomości
    ●
    Nie ważne GDZIE jest aktor
    ●
    Ważne, czy mam jego adres
    ●
    Sposób rozumowania, model obliczeniowy,
    sposób komunikacji
    @LAFK_pl
    

    View Slide

79. Aktor?
    ●
    Jednostka obliczeniowa – może procesować
    ●
    Ma pamięć – może coś przechować
    ●
    Rozmawia z innymi – są jak mrówki, zawsze wiele
    ●
    Ma adres, nie do podrobienia
    ●
    Ma skrzynkę pocztową, tam trafiają wiadomości
    ●
    Kompletna izolacja, nie współdzieli pamięci, ma
    prywatny stan, nie do zmiany przez innego aktora
    (bezpośrednio)
    @LAFK_pl
    

    View Slide

80. @LAFK_pl
    Aktor: skrzynka i listy
    

    View Slide

81. Aktor ma wiadomość...
    ●
    Sekwencyjne procesowanie wiadomości
    ●
    Współbieżnie? To do różnych aktorów
    ●
    Znasz adres, możesz gadać
    ●
    Wysyłka asynchroniczna
    ●
    Masz wiadomość!
    – Prześlij dalej do innego aktora
    – Stwórz aktora
    – Dla następnej wiadomości, stan będzie wyglądać...
    @LAFK_pl
    

    View Slide

82. @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

83. @LAFK_pl
    Założyciel @ MITORIDAFI
    Duża tablica
    Arrays.parallelSort(ints); // szybciej, na wielu prockach,
    UWAGA: OOME przy -Xmx12G (zwykłe sortowanie przeszło)
    UWAGA 2: pula wątków brana z forkJoin!
    

    View Slide

84. @LAFK_pl
    Założyciel @ MITORIDAFI
    Duża tablica - htop
    

    View Slide

85. @LAFK_pl
    Założyciel @ MITORIDAFI
    Duża tablica - htop
    

    View Slide

86. @LAFK_pl
    Założyciel @ MITORIDAFI
    Duża tablica zrównoleglona!
    ●
    API JDK
    ●
    Rozkłada na wiele procków, gotowy algorytm
    ●
    Te same parametry startowe (-Xmx12G)
    

    View Slide

87. @LAFK_pl
    Założyciel @ MITORIDAFI
    Duża tablica zrównoleg… ups!
    

    View Slide

88. @LAFK_pl
    Założyciel @ MITORIDAFI
    Równoległe strumienie
    ●
    Pula wątków ForkJoin
    ●
    Metody parallelStream, parallelSort
    ●
    Biblioteki i inne zależności?
    ●
    ForkJoin po prostu
    ●
    Nie wszystko dobrze się strumieniuje
    równolegle! (Paul Sandoz, Java One
    I have a Java 8 Stream)
    

    View Slide

89. @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

90. @LAFK_pl
    Założyciel @ MITORIDAFI
    

    View Slide

91. @LAFK_pl
    Założyciel @ MITORIDAFI
    Zagadka – SMP vs NUMA?
    

    View Slide

92. TestNG
    ●
    invocationCount
    ●
    timeOut
    ●
    invocationTimeOut
    ●
    singleThreaded
    ●
    threadPoolSize
    ●
    dependsOnMethods
    ●
    dataProvider
    @LAFK_pl
    

    View Slide

93. ThreadAffinity
    ●
    Kontra na wywłaszczanie wątków
    ●
    Przypina wątek do procka
    ●
    Jak?
    – Wymaga biblioteki JNA w systemie
    – Zczytuje z /proc układ / topologię
    – Szuka odizolowanego, tam przypina
    ●
    @LAFK_pl
    

    View Slide

94. JVSTM
    ●
    STM dla JVMa
    ●
    Adnotacja @Atomic
    ●
    Pojemniki synchronizowane
    ●
    Współdzielona pamięć z transakcyjną
    semantyką
    – Dodajcie MVCC i jazda!
    ●
    Albo idźcie w Clojure, Akkę, Quasara, też mają
    @LAFK_pl
    

    View Slide

95. Quasar
    ●
    Fiber – włókna, czyli lekkie wątki
    ●
    Fiber i Thread to Strand (wymienne użycie)
    ●
    Reaktywne strumienie
    ●
    Disruptor Channels
    ●
    STM
    ●
    Aktory
    ●
    Dla Clojure: Pulsar
    @LAFK_pl
    

    View Slide

96. Agenda
    ●
    O mnie
    ●
    Najważniejsze
    ●
    Jak co działa
    – Sprzęt, jądro, planista, system, wielowątkowość
    ●
    Co przeszkadza i co z tym zrobić
    ●
    Źródła
    ●
    Podsumowanie
    @LAFK_pl
    

    View Slide

97. Książki
    ●
    Gynvael Coldwind, Zrozumieć programowanie
    ●
    Brian Ward, Jak działa Linux. Podręcznik administratora
    ●
    J. Scott, How do it know
    ●
    Woolfe, Jak działa sprzęt
    ●
    Brian Goetz i inni, JCIP
    ●
    Maurice Herlihy, Nir Shavit, Sztuka programowania
    wieloprocesorowego
    ●
    Wikibooks, Designing microprocessors
    ●
    Ulrich Drepper, What every programmer should know about memory
    ●
    Paul Butcher, 7 modeli współbieżności w 7 tygodni
    @LAFK_pl
    

    View Slide

98. Publikacje autorów
    ●
    Leslie Lamport
    ●
    Sarita Adve
    ●
    Martin Thompson
    ●
    Gene Amdahl
    – i Rock
    – i Little
    – i Gustafsson…
    ●
    Neil J. Gunther
    @LAFK_pl
    

    View Slide

99. Tomasulo i inne źródła
    ●
    https://www.cs.umd.edu/~meesh/cmsc411/website/
    projects/dynamic/tomasulo.html
    ●
    https://www.youtube.com/watch?v=zS9ngvUQPNM
    ●
    https://www.youtube.com/watch?v=GRiw40MApi8
    ●
    http://berb.github.io/diploma-thesis/original/
    054_actors.html
    ●
    https://www.coursera.org/learn/concurrent-
    programming-in-java?action=enroll
    @LAFK_pl
    

    View Slide

100. Planiści: CFS, O(1), O(n)
     ●
     https://developer.ibm.com/tutorials/l-completely-fair-scheduler/
     ●
     https://people.redhat.com/mingo/cfs-scheduler/sched-design-
     CFS.txt
     ●
     https://kernelnewbies.org/LinuxVersions?
     action=fullsearch&context=180&value=scheduler
     ●
     https://www.ibm.com/developerworks/library/l-scheduler/index.html
     ●
     https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-decade-
     of-wasted-cores/
     ●
     https://www.linuxjournal.com/article/3910
     ●
     https://martin-thoma.com/linux-scheduler/
     @LAFK_pl
     

     View Slide

101. Quasar
     ●
     http://docs.paralleluniverse.co/quasar/
     ●
     http://blog.paralleluniverse.co/2013/05/02/quasar-
     pulsar/
     ●
     http://docs.paralleluniverse.co/comsat/
     ●
     Dla Clojure jest Pulsar
     ●
     Loom w nowej Javie jest robiony na bazie tej
     biblioteki (włókna – Fibers)
     ●
     https://github.com/puniverse/quasar
     @LAFK_pl
     

     View Slide

102. JVMSTM
     ●
     http://inesc-id-esw.github.io/jvstm/
     ●
     http://inesc-id-esw.github.io/jvstm/maven-repo/
     jvstm/jvstm/2.0/
     ●
     https://github.com/inesc-id-esw/jvstm/tree/
     master/src/main/java/jvstm
     ●
     Oraz powiązane:
     https://pveentjer.wordpress.com/2009/03/19/mu
     ltiverse-and-mvcc/
     @LAFK_pl
     

     View Slide

103. Intel
     ●
     Wikipedia (intelowskie mikroarchitektury)
     ●
     WFCTech, Materiały promocyjne Intela
     ●
     ArsTechnica, opis architektury Skylake
     ●
     7th Generation Intel Processor Families for S Platforms and Intel
     CoreTM X-Series Processor Family
     ●
     Intel Architecture Introduction Basics whitepaper
     ●
     Intel Architecture Instruction Set Extensions Programming
     Reference
     ●
     Slideshare, Sssuhasa prezentacja o prockach Intela
     ●
     Strona Intela o HT
     @LAFK_pl
     

     View Slide

104. Agenda
     ●
     O mnie
     ●
     Najważniejsze
     ●
     Jak co działa
     – Sprzęt, jądro, planista, system, wielowątkowość
     ●
     Co przeszkadza i co z tym zrobić
     ●
     Źródła
     ●
     Podsumowanie
     @LAFK_pl
     

     View Slide

105. Najważniejsze
     @LAFK_pl
     JVSTM,
     Quasar/
     Pulsar
     ●
     Wątki i zamki
     → STM →
     CSP / Aktory
     

     View Slide

106. Temat prezentacji na licencji Creative Commons
     Attribution-ShareAlike 3.0 Unported License.
     Korzysta z dzieł Mateusa Machado Luny.
     @LAFK_pl
     

     View Slide