Wpis z mikrobloga

Witam, mam taką rozkminę.
1. Na ile przydatny jest cache procesora (L1, L2, L3) skoro na jednym rdzeniu działają setki procesów? Przecież poza docelowym programem działa też również sam system który spawnuje mnóstwo procesów. Na ile instrukcji wystarcza jeden slot czasowy na CPU zanim zostanie przełączony na inny proces? 10? 100? 1000? 10000? Czy jak nastąpi przełączenie i się dzieje context switching to wszystkie cache lecą do kosza? Co z TLB ? Też leci na śmietnik?
2. Czy OS jakoś to uwzględnia i np jak ma proces który zabiera 95% czasu procesora a ma do dyspozycji ma wiele rdzeni, to będzie starał się go trzymać na jednym rdzeniu właśnie ze względu na cache? Czy będzie nim losowo rzucał po corach w zależności od tego co się pierwsze zwolni? Jaką władzę ma tutaj systemowy scheduler? Zakładam że jest w stanie nadzorować rdzenie indywidualnie?
3. Jaka jest polityka cachowania danych i instrukcji? Wystarczy że jakaś dana/instrukcja jest ładowana raz z pamięci i już ląduje w cachu? Czy musi być często czytana z pamięci żeby to się stało? I potem jest promowana L3->L2->L1 ? Kiedy z cache wylatuje? Kto w ogóle za to odpowiada? Ośrodek decyzyjny jest w CPU? W MMU? Czy cache same w sobie mają jakaś logike i same się tym zajmują? Przecież rozmiar cacha jest w kilobajtach więc musi być bardzo selektywny.
4. W przypadku języków z maszyną wirtualną typu Java/C#: skoro maszyna wirtualna sama jest programem który wykonuje inny program, to czy to nie ma mega złego wpływu na cache? Czy to nie zwiększa niemożebnie presji na cache instrukcji? Nię mowiąc o tym jak się odpali garbage collector i skanuje całą stertę, czy to nie zabrudza cache'a programowai który właśnie działał na tym corze?
#programowanie #cpp #java #dotnet #informatyka
  • 8
@Passer93: 1. W zależności od architektury CPU, niektóre levele cache są współdzielnone pomiędzy poszczególne cory, a niektóre (te najbliżej procesora) są dedykowane per core. To, na ile instrukcji wystarcza jeden slot czasowy na CPU, zależy od kodu, który decyduje który core co wykonuje. Podobnie, to co się dzieje po context switchu zależy od tego, co było wykonane przed nim oraz od tego, co będzie wykonane po nim. Może się zdarzyć, że
@Passer93: > skoro na jednym rdzeniu działają setki procesów

@Passer93: Nawet jak działają to przez 99% czasu są uśpione. Aktywnych procesów będzie góra kilka.

Na ile instrukcji wystarcza jeden slot czasowy na CPU zanim zostanie przełączony na inny proces?


@Passer93: jeśli przełączanie będzie co 0.1s to to będzie 400mln cykli czyli z milliard instrukcji

Czy jak nastąpi przełączenie i się dzieje context switching to wszystkie cache lecą do kosza?
@Passer93: nie znam się więc się wypowiem

Czy jak nastąpi przełączenie i się dzieje context switching to wszystkie cache lecą do kosza?


Do momentu meltdown i spectre odpowiedź była 'nie'. Teraz na Intelu jest to wymuszane i był o to straszny ból dupy bo niektóre serwerowe benchmarki potraciły po 50%.

Czy OS jakoś to uwzględnia i np jak ma proces który zabiera 95% czasu procesora a ma do dyspozycji ma wiele
3. Jaka jest polityka cachowania danych i instrukcji? Wystarczy że jakaś dana/instrukcja jest ładowana raz z pamięci i już ląduje w cachu? Czy musi być często czytana z pamięci żeby to się stało? I potem jest promowana L3->L2->L1 ? Kiedy z cache wylatuje? Kto w ogóle za to odpowiada? Ośrodek decyzyjny jest w CPU? W MMU? Czy cache same w sobie mają jakaś logike i same się tym zajmują? Przecież rozmiar cacha
4. W przypadku języków z maszyną wirtualną typu Java/C#: skoro maszyna wirtualna sama jest programem który wykonuje inny program, to czy to nie ma mega złego wpływu na cache? Czy to nie zwiększa niemożebnie presji na cache instrukcji? Nię mowiąc o tym jak się odpali garbage collector i skanuje całą stertę, czy to nie zabrudza cache'a programowai który właśnie działał na tym corze?


tu nie ma magii - Java nie różni się