Wielowątkowość w Go: CPU, pamięci podręczne i wydajność | Analiza

Wielowątkowość w Go: jak CPU, pamięć podręczna i planista wpływają na wydajność

Współczesne aplikacje Go intensywnie wykorzystują równoległość, ale wielu programistów nie do końca rozumie, co dzieje się pod maską podczas pracy z wieloma rdzeniami CPU. Ten artykuł omawia niskopoziomowe mechanizmy wpływające na wydajność programów wielowątkowych: od osobenności przełączania kontekstu po spójność pamięci podręcznej. Wyjaśnimy, dlaczego istnieją operacje atomowe i bariery pamięci, oraz jak ich cechy objawiają się w rzeczywistych scenariuszach.

Mechanizmy wielozadaniowości: kooperacyjna vs wywłaszczająca

Główny problem systemów jednordzeniowych to konieczność jednoczesnego wykonywania wielu zadań. Rozwiązanie pojawiło się w dwóch wariantach:

• Wielozadaniowość kooperacyjna — zadania dobrowolnie ustępują CPU za pomocą wywołań systemowych typu sched_yield(). Słabość takiego podejścia jest oczywista: zawieszenie się jednego zadania paraliżuje cały system (jak w Windows 3.1).

• Wielozadaniowość wywłaszczająca — przymusowe przerywanie zadań za pomocą timera. Kluczowe etapy:

- Generowanie przerwania sprzętowego

- Zapisanie kontekstu bieżącego zadania do RAM

- Wybór nowego zadania przez planistę

- Przywrócenie kontekstu

Krytycznie ważne jest zrozumienie, że kontekst zadania obejmuje:

• Wartości rejestrów (RAX, RBX itp.)
• Wskaźnik instrukcji (RIP)
• Wskaźnik stosu (RSP)
• Rejestr flag (RFLAGS)
• Dane stosu

Przełączanie kontekstu wymaga zapisania tych danych do pamięci operacyjnej, co generuje narzut. Na współczesnych CPU operacja context switch zajmuje 200–300 taktów — równowartość wykonania dziesiątek instrukcji.

Architektura systemów wielordzeniowych i hierarchia pamięci podręcznej

Z przejściem na procesory wielordzeniowe pojawił się nowy problem: jak synchronizować dostęp do wspólnej pamięci. Aby zrozumieć rozwiązania, trzeba omówić hierarchię pamięci podręcznej:

Pamięć podręczna L1

• Rozmiar: 32–64 KB
• Opóźnienie: ~4 takty
• Podzielona na instrukcje (L1i) i dane (L1d)
• Powiązana z fizycznym rdzeniem

Pamięć podręczna L2

• Rozmiar: 256 KB – 1 MB
• Opóźnienie: 10–15 taktów
• Zazwyczaj powiązana z rdzeniem

Pamięć podręczna L3

• Rozmiar: 8–40 MB
• Opóźnienie: 30–50 taktów
• Wspólna dla wszystkich rdzeni

Kluczowa kwestia: procesor samodzielnie zarządza pamięcią podręczną za pomocą sprzętowego kontrolera. System operacyjny i aplikacje nie mogą bezpośrednio wpływać na umiejscowienie danych. To prowadzi do sytuacji, w której różne rdzenie mogą pracować ze nieaktualnymi kopiami danych.

Protokół MESI i spójność pamięci podręcznej

Aby rozwiązać problem spójności, stosowany jest protokół MESI (Modified, Exclusive, Shared, Invalid). Każda linia pamięci podręcznej (zazwyczaj 64 bajty) ma jeden z czterech stanów:

• Modified: dane zmienione w tej pamięci podręcznej i różniące się od RAM
• Exclusive: dane zgodne z RAM, dostępne tylko dla tego rdzenia
• Shared: dane zgodne z RAM i możliwe w innych pamięciach podręcznej
• Invalid: dane nieaktualne i niemożliwe do użycia

Przykład działania przy zapisie:

• Rdzeń A odczytuje zmienną → stan Shared
• Rdzeń B odczytuje tę samą zmienną → stan Shared
• Rdzeń A zapisuje nową wartość → wysyła żądanie invalidate
• Rdzeń B odbiera żądanie i przechodzi linię do stanu Invalid

Ten mechanizm generuje ukryte opóźnienia: przy konkurencyjnych zapisach rdzenie muszą wymieniać sygnały przez magistralę, co może zająć 100–300 taktów.

Praktyczne konsekwencje dla programistów Go

Zrozumienie tych mechanizmów jest kluczowe przy pracy z:

• Operacjami atomowymi: instrukcje LOCK XCHG gwarantują atomowość poprzez blokadę magistrali
• Barierami pamięci: mfence kontroluje kolejność wykonywania instrukcji
• CPU affinity: przypinanie gorutyn do konkretnych rdzeni za pomocą GOMAXPROCS

Przykład problemu fałszywego współdzielenia (false sharing):

var data [2]int64

// Gorutyna 1
for {
    data[0]++
}

// Gorutyna 2
for {
    data[1]++
}

Mimo pracy z różnymi elementami tablicy, trafiają one do jednej linii pamięci podręcznej (64 bajty). Przy zapisie do data[0] linia staje się Invalid dla drugiego rdzenia, powodując ciągłą synchronizację. Rozwiązanie — dodać padding:

var data [2]struct{
    value int64
    _     [56]byte // Wypełniacz do 64 bajtów
}

Co ważne

• Przełączanie kontekstu wymaga zapisania stanu do RAM, co generuje opóźnienia ~200 taktów
• Spójność pamięci podręcznej przez MESI dodaje narzut przy konkurencyjnych zapisach
• Fałszywe współdzielenie (false sharing) może obniżyć wydajność o 2–3 rzędy wielkości
• Operacje atomowe działają poprzez blokadę magistrali lub protokoły pamięci podręcznej (w zależności od architektury)
• Zrozumienie hierarchii pamięci podręcznej pozwala optymalizować struktury danych pod rozmiar linii pamięci podręcznej

Programiści Go często napotykają te problemy przy tworzeniu usług o wysokim obciążeniu. Na przykład w systemach rozproszonych nieprawidłowa praca z pamięcią podręczną może prowadzić do nieoczekiwanych opóźnień przy obsłudze tysięcy żądań na sekundę. Kluczowy wniosek: efektywna równoległość wymaga uwzględnienia nie tylko logiki aplikacji, ale i cech sprzętu.

Do dalszego studiowania polecamy analizę wyjścia asemblera kompilatora Go za pomocą flagi -S, a także profilerów typu perf do mierzenia chybów pamięci podręcznej i context switchy. Te dane pomogą wykryit wąskie gardła niewidoczne na poziomie kodu źródłowego.

— Editorial Team