Casey Muratori giving his thoughts on smart-pointers, RAII, OOP, briefly the Rust borrow checker etc, and why you should avoid them and instead focus on lear...
On nie kieruje tego do “większości współczesnych projektów”. Backend webowy to zupełnie inna warstwa abstrakcji.
Mnie to rozśmieszyło, bo kiedyś żartowałem, że aplikacja powinna na starcie alokować 64k i się tego trzymać do końca.
Rozważ to pisząc sewer, lub bazę danych. Wtedy pewnie masz zarządzanie dużą ilością stringów.
Rozważ to pisząc coś na kontroler, gdzie używasz za dużo dynamicznej pamięci i masz ciągle problemy z fragmentacją. Przez co alokator nie może znaleźć odpowiednio długiego pustego obszaru.
Zobacz jakie problemy mieli i mają twórcy przeglądarek.
Pewnie rozbudowane aplikacje na stację roboczą mają podobnie.
To wymaga zmiany podejścia do zarządzania pamięcią.
Pod Linuksem to chyba sprawa sztuczki w glibc, który ma własny alokator i leniwe zwracanie pamięci do jądra. Ale też były problemy skoro proszono o huge pages i rozwiązania z brakiem jawnej ochrony.
Jeśli chodzi o budowę gier. Dzisiaj to jest podzielone między GPU i CPU. W najbardziej wydajnych rozwiązaniach CPU pewnie przetwarza ciągle jakąś strukturę tablic z atrybutami. Co jakiś czas się ją sortuje, żeby zadowolić przewidywanie rozgałęzień. GPU pewnie możliwie dużo z tego stara się wizualizować na podstawie atrybutów i własnych danych.
Ja nie mam problemu z tymi technikami, tylko ze sposóbem ich prezentacji jako “programowanie N+1”. Muratori nie zastrzegł, że to są techniki specyficzne dla gamedevu, embedded czy kodu high-performance.
On po prostu wartościuje na zasadzie “jeśli piszesz tak kod, jesteś lepszym programistą”.
W praktyce, dla 80% współczesnych developerów pracujących w “biznesowych” projektach, takie porady nie są przydatne. Co gorsze, mogą budować u ludzi poczucie winy, że nie potrafią tego wdrożyć w swoim kodzie i przejść na “wyższy poziom programowania”.
Rzecz w tym, że takie projekty są optymalizowane pod kątem łatwej rozbudowy, a nie wyciśnięcia 100% możliwości ze specyficznego hardware’u.
Niektóre z tych technik byłyby w wielu projektach wręcz szkodliwe. Zwracanie współdzielonego obiektu (stubu) w przypadku wyczerpania zasobów to prosta droga do utraty albo wycieku danych.
Microsoft też zrobił później normalny alokator (mimalloc). Nic nie stało na przeszkodzie, żeby zaimplementować lepsze zarządzanie pamięcią w domyślnym runtime.
Jeśli obawiali się, że popsuje to aplikacje, wystarczyło warunkowo włączać nową implementacją jakimś API albo zmienną środowiskową.
Zresztą MS robił odważniejsze fikołki w tej bibliotece. Parę lat temu zmienili sposób alokacji pamięci z prywatnej sterty dla każdej biblioteki na współdzieloną przez cały proces.
Z huge pages jeśli dobrze pamiętam chodziło raczej o wyczerpywanie TLB nadmierną liczbą stron i koszt obsługi pagefaultów.
Bo on chce, żeby każdy program był traktowany jako wydajny. On chce, żeby programiści mieli poczucie winy. Bo zdaniem tego ruchu kod (jak kiedyś pisaliśmy) “ęnterprajs”, przenika na niższe warstwy. Przez co programy od których powinieneś oczekiwać więcej, oferują mniej, są powolne i zabierają dużo zasobów.
Jeśli ktoś pracuje w “biznesowym” projekcie, niech koduje jak mu przełożony zagra. Niech się potem nie dziwi, że pół internetu szydzi z projektu w którym uczestniczy.
Jeśli ktoś sili się na rzemiosło, powinien dać z siebie wszystko. Ale jeśli ktoś uważa, że powinien w rzemiośle stosować strategie biznesowe rozwoju oprogramowania, to raczej niszczy. Przecież są ludzie, którzy przekonują cały świat, że tak powinno być. Szydzą z ambitnych projektów. Szydzą z innych strategii rozwoju. Szydzą z innego podejścia do kontroli wersji.
Zawsze byliśmy dumni z tego, że otwarty kod oferuje więcej możliwości. Bo to wtedy było rzemiosło.
On nie kieruje tego do “większości współczesnych projektów”. Backend webowy to zupełnie inna warstwa abstrakcji.
Mnie to rozśmieszyło, bo kiedyś żartowałem, że aplikacja powinna na starcie alokować 64k i się tego trzymać do końca.
Rozważ to pisząc sewer, lub bazę danych. Wtedy pewnie masz zarządzanie dużą ilością stringów. Rozważ to pisząc coś na kontroler, gdzie używasz za dużo dynamicznej pamięci i masz ciągle problemy z fragmentacją. Przez co alokator nie może znaleźć odpowiednio długiego pustego obszaru. Zobacz jakie problemy mieli i mają twórcy przeglądarek. Pewnie rozbudowane aplikacje na stację roboczą mają podobnie. To wymaga zmiany podejścia do zarządzania pamięcią.
Pod Linuksem to chyba sprawa sztuczki w glibc, który ma własny alokator i leniwe zwracanie pamięci do jądra. Ale też były problemy skoro proszono o huge pages i rozwiązania z brakiem jawnej ochrony.
Jeśli chodzi o budowę gier. Dzisiaj to jest podzielone między GPU i CPU. W najbardziej wydajnych rozwiązaniach CPU pewnie przetwarza ciągle jakąś strukturę tablic z atrybutami. Co jakiś czas się ją sortuje, żeby zadowolić przewidywanie rozgałęzień. GPU pewnie możliwie dużo z tego stara się wizualizować na podstawie atrybutów i własnych danych.
Ja nie mam problemu z tymi technikami, tylko ze sposóbem ich prezentacji jako “programowanie N+1”. Muratori nie zastrzegł, że to są techniki specyficzne dla gamedevu, embedded czy kodu high-performance.
On po prostu wartościuje na zasadzie “jeśli piszesz tak kod, jesteś lepszym programistą”.
W praktyce, dla 80% współczesnych developerów pracujących w “biznesowych” projektach, takie porady nie są przydatne. Co gorsze, mogą budować u ludzi poczucie winy, że nie potrafią tego wdrożyć w swoim kodzie i przejść na “wyższy poziom programowania”.
Rzecz w tym, że takie projekty są optymalizowane pod kątem łatwej rozbudowy, a nie wyciśnięcia 100% możliwości ze specyficznego hardware’u.
Niektóre z tych technik byłyby w wielu projektach wręcz szkodliwe. Zwracanie współdzielonego obiektu (stubu) w przypadku wyczerpania zasobów to prosta droga do utraty albo wycieku danych.
Microsoft też zrobił później normalny alokator (mimalloc). Nic nie stało na przeszkodzie, żeby zaimplementować lepsze zarządzanie pamięcią w domyślnym runtime.
Jeśli obawiali się, że popsuje to aplikacje, wystarczyło warunkowo włączać nową implementacją jakimś API albo zmienną środowiskową.
Zresztą MS robił odważniejsze fikołki w tej bibliotece. Parę lat temu zmienili sposób alokacji pamięci z prywatnej sterty dla każdej biblioteki na współdzieloną przez cały proces.
Z huge pages jeśli dobrze pamiętam chodziło raczej o wyczerpywanie TLB nadmierną liczbą stron i koszt obsługi pagefaultów.
Bo on chce, żeby każdy program był traktowany jako wydajny. On chce, żeby programiści mieli poczucie winy. Bo zdaniem tego ruchu kod (jak kiedyś pisaliśmy) “ęnterprajs”, przenika na niższe warstwy. Przez co programy od których powinieneś oczekiwać więcej, oferują mniej, są powolne i zabierają dużo zasobów.
Jeśli ktoś pracuje w “biznesowym” projekcie, niech koduje jak mu przełożony zagra. Niech się potem nie dziwi, że pół internetu szydzi z projektu w którym uczestniczy.
Jeśli ktoś sili się na rzemiosło, powinien dać z siebie wszystko. Ale jeśli ktoś uważa, że powinien w rzemiośle stosować strategie biznesowe rozwoju oprogramowania, to raczej niszczy. Przecież są ludzie, którzy przekonują cały świat, że tak powinno być. Szydzą z ambitnych projektów. Szydzą z innych strategii rozwoju. Szydzą z innego podejścia do kontroli wersji.
Zawsze byliśmy dumni z tego, że otwarty kod oferuje więcej możliwości. Bo to wtedy było rzemiosło.
Pagefault odpowiada za wiele rzeczy.