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...
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.
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.