Wpis z mikrobloga

  • 1
w 99% przypadków nie ma to dla programisty najmniejszego znaczenia


@Hauleth: Otóż nie! Page faulty potrafią zabić performance Twojej aplikacji. Wcale nie tak trudno zrobić sobie kuku jeśli nie wiesz co czynisz. Przekonałem się o tym w dość bolesny sposób.

zwłaszcza, że to i tak jest platform dependent


To wszystko zależy jak definiujesz platformę. Ponieważ pamięc wirtualna to kombinacja HW & SW, tłumaczenie wirtualnych adresów na fizyczne przebiega mniej więcej
  • Odpowiedz
@groman43: Panieeee to już rocket science dla vibe coderow. Z doświadczenia wiem, że duuuzo problemów rozwiązują te poniższe xd:

- stosując lookup hash strukty, które redukują niektórym ancymonom algorytmy z n^3 na n
- alignowanie struktow do rozmiaru linii cacheu bo wszędzie gdzie nie byłem to n------e false sharingu
- nadsubskrypcje to standardzie
- pobieranie z bazy danych z chunkow danych, zamiast ściągnąć je na strzała (bo
  • Odpowiedz
Page faulty potrafią zabić performance Twojej aplikacji. Wcale nie tak trudno zrobić sobie kuku jeśli nie wiesz co czynisz.


@groman43: z jednej strony tak, ale tutaj ważniejsze jest cache locality niż page fault. Jak masz kod napisany tak, że cache locality jest zachowane, to z automatu page faulty nie są problemem. Przy czym dalej - w 90% programów (estymata zaniżona) to nie ma najmniejszego znaczenia.

Ponieważ pamięc wirtualna to kombinacja
  • Odpowiedz
  • 1
@Hauleth: Jak to powiedział klasyk, to zależy xD Na pewno cache missy będą znacznie częstszym problemem niż page faulty. Ale page faulty będą powodowany znacznie większy performance degradation. Z drugiej strony, każdy głupi może zrobić sobie kuku za pomocą cache missa. Jedyny przypadek, który przychodzi mi do głowy, gdzie można zrobić sobie kuku za pomocą page faulta to operowanie na bardzo dużych buforach (bezpośrednio lub pośrednio - w wielu językach
  • Odpowiedz
@groman43: w jakich sytuacjach miałeś problemy z page faultami? Generalnie jedyny problem jaki widziałem w aplikacji biznesowej był związany ze złą konfiguracją alokatora, który za często zwracał pamięć do systemu przez co przy ponownej alokacji wyskakiwały page faulty
  • Odpowiedz
  • 1
@Saly Pracowałem nad apką, która miała przetwarzać grube gigabity na sekundę (około 64Gb/s). Prealokacja wszystkich buforów podczas start-upu średnio wchodziła w grę, ponieważ musieliśmy wspierać kilka różnych konfiguracji, a nie chcieliśmy zawsze alokować z myślą o najgorszym możliwym przypadku.

No to w pewnym kawałku kodu optymistycznie zaalokowałem sobie bufor na grube megabajty, a potem walnąłem jeszcze memseta na tym buforze. Czas wykonania kodu - około 1ms xD

Cała apka została przepisana
  • Odpowiedz