Mire használjuk a magokat, ha már úgy is vannak? A több szálú adatfeldolgozás architekturális problémái.

1. Scheidler Balázs
“Magvas gondolatok”

2. Tartalom
•Párhuzamos programozás & SMP
•Memória & Cache
•Valós tapasztalatok
•Tipikus problém & trade-off
•Konkrét adatszerkezet gyorsítása

3. Párhuzamos programozás
•Több szálú futás
•Közös memória
•Közös állapottér
(nyitott fájlok, hálózati
kapcsolatok, stb)
•Szálak közötti ütemezés az
OS feladata
•Több CPU/core transzparens
használata

4. SMP
•SMP = Symmetric Multiprocessing
•Több CPU, közös memória, I/O tér
•Minden CPU/core azonos típusú, órajelűű
•Desktop gépekben, szervereken tipikus
•Lehetnek specializált CPU-k, más
rendszert futtatva

5. Memória
•Jelenlegi CPU-k órajele a GHz tartományban
•Egy utasítás végrehajtásához szükséges időő
nanoszekundum nagyságrend
•DRAM memória hozzáféréshez szükséges időő
mikroszekundum nagyságrend (1:1000)
•Ez megegyezik a memória/vinyó közti aránnyal!

6. Cache
DRAM lassú, az SRAM drága
Megoldás:
• kisebb, gyors cache memória
• nagy, lassú központi memória
• 1:1000 arány (méret és sebesség)
• L1, L2, L3 szintek

7. Cache II.
•A cache a CPU és a memória közti gyorsítótár
•CPU által automatikusan menedzselt, program
számára transzparens
•Asszociatív tárolás, 32 byte-os egységekben
(„cacheline”)

8. Cache Hatásai
Egy algoritmus lehet utasítás számban minimális
ÉS
Lassabb, mint a több utasításból álló, de a cache-t
hatékonyabban kihasználó változat.

9. Cache & SMP
•Egy SMP rendszerben minden CPU/core
külön cache-sel rendelkezik
•Memória mindegyik CPU/core számára
közös
•Ugyanazon memória cím eléréséhez a
CPU-k között kommunikációra van
szükség

10. CPU-k közti szinkronizáció
MESI protokoll M E
• Modified
• Exclusive
• Shared S I
• Invalid
local read local write
remote read remote write

11. Kommunikáció Hatásai
Egy látszólag egyszerűű műűvelethez
mögött komplex lépések történnek
A komplexitás időőbe kerül
Egy memória műűvelet:
• lehet 3 nagyságrenddel lassabb
• függhet a CPU-k számától!

12. Tipikus cache probléma
•2 processzor végez ugyanazon a
cacheline-on felváltva atomikus write
műűveletet (pl. egy lock)
sch
•A write műűvelet miatt mindkét CPU
memóriából húzza be a cacheline-t,
miközben a másik cache tartalmat
invalidálja.
•Aka. cache ping-pong

13. Valós tapasztalatok: syslog-ng

14. syslog-ng
•Naplózó szerver, üzeneteket
fogad TCP és UDP
csatornákon
•Egy üzenet egy sor
•Minden sor kb 3-500 byte
•~ ezer kapcsolat,
•~ néhány száz ezer msg/sec

15. Mérés, reprodukció
„Premature optimization is the root of
all evil.” - Donald Knuth
Mérés és a reprodukálható testcase
fontos!
• ne kezdjünk bele nélküle
• ismerjük meg az eszközeinket
• perf, cachegrind, gprof

16. syslog-ng műűködése
Bejövőő üzenetek feldolgozása:
• beolvasás, parse-olás, szűűrés/módosítás,
kiküldés egy outputra
Kimenőő üzenetek feldolgozása:
• üzenet megformázása, kiírás egy fájlba/
hálózati kapcsolatra

17. syslog-ng korábban
• 1 szál, poll() ciklus
• minden esemény kezelése aszinkron
callbackekkel
• kb 100k msg/sec

18. syslog-ng ma
•főő szál + worker threadek •Nonblocking I/O
•a főő szál figyeli az összes nyitott •Worker threadek száma
kapcsolatot (epoll), I/O esemény megegyezik a CPU-k
esetén annak teljes feldolgozását számával
átadja a worker threadnek
•Egy taszk 1-4 msec időő
•I/O események: alatt végez (1-4000
üzenet feldolgozása)
•input adat érkezett (fetch,
process, enqueue loop)
•output írhatóvá vált (dequeue,
format, write loop)

19. Szűűk keresztmetszetek, problémák

20. Thread váltás
Drága, mert:
• kihűűl a cache,
• scheduler,
• context switch: regiszterek, TLB
Elkerülés módja:
• kevés thread (=CPU-k száma),
nonblocking I/O
• egy feladat kb. egy időőszeletig
fut, se hosszabban, se
rövidebben

21. Késleltetés
A latency önmagában nem okoz CPU használatot, de
• egy feldolgozásba beépülve okozhatja annak
jelentőős lassulását
• 1 msec késleltetés önmagában nem sok, de 1000
tranzakció esetén már 1 mp-cel nyújtja az időőt!
Latency források:
• lockok és szinkronizációs primitívek
• OS események (epoll)

22. Dinamikus memória
malloc/free jelentős időrablás 500k/sec tranzakciónál
• threadek közti szinkronizáció
• láncolt listák
• tipikus: egyik szál lefoglal, másik felszabadít
Elkerülés módja:
• alloca() ill. fixen méretezett változók
• per-thread allokációk, hosszú távon megőőrizve, igény
esetén növelve
• LogMessage adatszerkezet „tömörítése”, ideális esetben
1 malloc/msg

23. Lock contention
Tipikus cache ping-pong:
• N szál ugyanazt a mutexet lockolja, egymást váltva
• a reader-writer locknál és az atomikus referencia számlálónál is
előőfordul!
Cél:
• egy egység hasznos munkára esőő szinkronizációs időő csökkentése
Elkerülés módja:
• per-thread változók
• adatszerkezet módosítása, nagyobb felbontású mutexek használata
• több munkát végzünk egy lock védelme alatt,
ld. skálázható queue-k

24. A nem triviális költségek miatt egy szekvenciális
program párhuzamos változata gyakran lassabb
lesz elsőő alkalommal.

25. Tipikus trade-off-ok
Konzisztencia, sorrendiség vs. sebesség
• az abszolút sorrend sok szinkronizációt követel meg,
ezek közül nem mind fontos
Használt memória mennyiség vs. sebesség
• pl. per-thread változók, párhuzamos objektum
példányok

26. Skálázható queue
Az input és az output közti összekötést biztosítja:
• input taszkok (N): beteszik az eseményeket
• output taszk (1): kiveszi az eseményeket,
majd kiküldi

27. Triviális megoldás

28. Mutex
...
Üzenetenként 4 szinkronizációt igénylőő
műűvelet (input/output x lock-unlock)

29. Hogyan lehetne javítani?

30. per-thread
input queue
...
Mutex
...
...
...
...
Konzisztencia/memória vs. performance
Atomikus műűveletek száma kb felezőődik.

31. per-thread
input queue
. Lockolatlan
.
. Mutex output queue
.
. ...
.
.
.
.
.
.
.
Atomikus műűveletek másik fele is
nagyságrendekkel csökken.

32. Lockless?

33. Lockless veszélyek
Compiler reordering
CPU reordering (cache és memória miatt)
Stale adatok jelenléte miatt:
• nehezen debuggolható, ritkán előőforduló hibák
Mielőtt ilyenbe kezdesz:
• memory ordering
• memory barriers
• compiler reordering barriers

34. Összefoglalás
•Párhuzamos programozás okozhat
Ʃ
meglepetéseket
•Egy algoritmus párhuzamosítása
gyakran lassulást eredményez elsőőre!
•Mérés & megértés

35. VÉGE
lwn.net/Articles/250967/
rdrop.com/users/paulmck/perfbook/perfbook.2011.08.28a.pdf