Zaskakujący jest dla mnie ponowny wzrost wskaźnika skalowalności jeśli rozmiar pamięci roboczej zaczyna być znacznie większy od L3. Tak jakby dostęp do cache’u był wtedy pomijany?
Nie znałem tego frameworku X-ray do instrumentacji. Bawiłem się niedawno opcją “-finstrument-functions” z GCC, ale w innym celu.
Chciałem zrobić logowanie wywołań funkcji z nazwą pasującą do określonego wzorca.
Spróbowałem też użyć frameworku Frida, ale okazało się, że nie działa z kodem rzucającym wyjątki C++.
Wyjątek z hookowanej funkcji jest rzucany drugi raz, co skutkuje ubiciem procesu przez std::terminate.
Będę musiał chyba wrócić do oryginalnej koncepcji z instrumentacją z kompilatora.
Nie wiem czy pomijalny. Raczej coś zaczyna być wykorzystywane w pełni. Może L3 się zaczyna odpowiednio dzielić zasobami. Może kontroler DDR5 zaczyna lepiej paralelizować rozkazy.
Ok, pomyślałem jeszcze nad tym wykresem i doszedłem do wniosku, że to może być związane z NUMA.
Może topologia wyglądała tak, że każdy procesor miał przydzielone tylko 2 kanały i dla przypadku z jednym workerem odczytywał z RAMu tyle samo danych, co każdy z 6 procesów w drugim scenariuszu.
Czyli system był skonfigurowany tak, że wydajność RAMu dla pojedynczego procesora była sztucznie zaniżona.
Uruchomienie dodatkowych procesów mogło w tym przypadku poprawić wynik.
Na L3 nie miało to wpływu, bo ta warstwa działa z maksymalną przepustowością (pomijając przypadki gdzie trzeba synchronizować dostęp do danych).
Na 图4 (Rysunek 4) masz schemat budowy chipletu i/o. Wygląda na to, że w dalszym ciągu jest RAM bliższy i dalszy. By trzeba zrobić twój benchmark by to zweryfikować.
Wcześniej byłem przekonany, że skoro zrobili jeden chiplet do komunikacji to obsługa pamięci jest mniej rozproszona i CPU mają do niej bardziej zrównoważony dostęp.
Zaskakujący jest dla mnie ponowny wzrost wskaźnika skalowalności jeśli rozmiar pamięci roboczej zaczyna być znacznie większy od L3. Tak jakby dostęp do cache’u był wtedy pomijany?
Nie znałem tego frameworku X-ray do instrumentacji. Bawiłem się niedawno opcją “-finstrument-functions” z GCC, ale w innym celu.
Chciałem zrobić logowanie wywołań funkcji z nazwą pasującą do określonego wzorca.
Spróbowałem też użyć frameworku Frida, ale okazało się, że nie działa z kodem rzucającym wyjątki C++.
Wyjątek z hookowanej funkcji jest rzucany drugi raz, co skutkuje ubiciem procesu przez
std::terminate.Będę musiał chyba wrócić do oryginalnej koncepcji z instrumentacją z kompilatora.
Nie wiem czy pomijalny. Raczej coś zaczyna być wykorzystywane w pełni. Może L3 się zaczyna odpowiednio dzielić zasobami. Może kontroler DDR5 zaczyna lepiej paralelizować rozkazy.
Ok, pomyślałem jeszcze nad tym wykresem i doszedłem do wniosku, że to może być związane z NUMA.
Może topologia wyglądała tak, że każdy procesor miał przydzielone tylko 2 kanały i dla przypadku z jednym workerem odczytywał z RAMu tyle samo danych, co każdy z 6 procesów w drugim scenariuszu.
Czyli system był skonfigurowany tak, że wydajność RAMu dla pojedynczego procesora była sztucznie zaniżona.
Uruchomienie dodatkowych procesów mogło w tym przypadku poprawić wynik.
Na L3 nie miało to wpływu, bo ta warstwa działa z maksymalną przepustowością (pomijając przypadki gdzie trzeba synchronizować dostęp do danych).
To dobra teoria. Trzeba się zapoznać z budową chipletu i/o. Gdzieś widziałem jego schemat blokowy.
Mam chiński art: https://zhuanlan.zhihu.com/p/629392033
Na 图4 (Rysunek 4) masz schemat budowy chipletu i/o. Wygląda na to, że w dalszym ciągu jest RAM bliższy i dalszy. By trzeba zrobić twój benchmark by to zweryfikować.
Wcześniej byłem przekonany, że skoro zrobili jeden chiplet do komunikacji to obsługa pamięci jest mniej rozproszona i CPU mają do niej bardziej zrównoważony dostęp.