Zawsze uważałem, że termin „mikrooptymalizacja” jest dość niejednoznaczny. Jeśli jakieś zmiany na poziomie instrukcji w układzie pamięci i wzorcach dostępu sprawiają, że coś 80-krotnie przyspiesza od zdyscyplinowanego profesjonalisty mierzącego swoje punkty aktywne bez zmniejszania złożoności algorytmicznej, to czy jest to „mikrooptymalizacja”? Dla mnie jest to „mega optymalizacja”, by zrobić coś 80 razy szybciej w przypadku użycia w świecie rzeczywistym. Ludzie zwykle mówią o takich rzeczach, ponieważ takie optymalizacje mają efekty mikroskopowe.
Nie pracuję już w gamedev, ale pracuję w VFX w obszarach takich jak śledzenie ścieżek, i widziałem wiele implementacji BVH i drzew KD, które przetwarzają ~ 0,5 miliona promieni na sekundę na złożonej scenie (i to z ocena wielowątkowa). Z grubsza mówiąc, zwykle widzę prostą implementację BVH w kontekście raytracingu przy prędkości poniżej 1 miliona promieni / s, nawet przy ocenie wielowątkowej. Z wyjątkiem Embree ma BVH, który może przetwarzać ponad 100 milionów promieni na tej samej scenie przy użyciu tego samego sprzętu.
Wynika to całkowicie z „mikrooptymalizacji”, że Embree jest 200 razy szybszy (ten sam algorytm i struktura danych), ale oczywiście powodem, dla którego jest o wiele szybszy, jest to, że programiści w firmie Intel to profesjonaliści, którzy opierają się na swoich profilach i pomiarach oraz naprawdę dostroił obszary, które miały znaczenie. Nie zmieniali kodu nie chcąc wyjść z przeczuć i nie wprowadzali zmian, które wprowadziły ulepszenia o 0,000000001% kosztem znacznego pogorszenia łatwości konserwacji. Były to bardzo precyzyjne optymalizacje zastosowane w rozsądnych rękach - mogły być mikroskopijne pod względem skupienia, ale makroskopowe pod względem efektu.
Oczywiście w zależności od wymagań dotyczących szybkości klatek w czasie rzeczywistym w grach, w zależności od tego, w jaki sposób pracujesz z silnikiem gry na wysokim lub niskim poziomie (nawet gry wykonane przy użyciu UE 4 są często implementowane przynajmniej częściowo w skrypcie wysokiego poziomu, ale nie powiedzmy najbardziej krytycznych części silnika fizyki), mikrooptymalizacje stają się praktycznym wymogiem w niektórych obszarach.
Innym bardzo podstawowym obszarem, który nas otacza na co dzień, jest przetwarzanie obrazu, takie jak rozmycie zdjęć w wysokiej rozdzielczości w czasie rzeczywistym i być może wykonywanie na nich innych efektów w ramach przejścia, które prawdopodobnie wszyscy gdzieś widzieliśmy, być może nawet efekt systemu operacyjnego. Nie zawsze można zaimplementować takie operacje na obrazie od zera do pętli przez wszystkie piksele obrazu i oczekiwać takich wyników w czasie rzeczywistym przy pasujących częstotliwościach klatek. Jeśli chodzi o procesor, zwykle patrzymy na SIMD i mikro-tuning, lub na shadery GPU, które zwykle wymagają sposobu myślenia na poziomie mikro do skutecznego pisania.
Jeśli tak, to w miarę jak poprawia się sprzęt, czy możemy oczekiwać, że języki wyższego poziomu przejmą przemysł gier?
Wątpię raczej, aby postępy w zakresie samego sprzętu były w stanie to zrobić, ponieważ wraz z postępem sprzętu rosną również instrukcje i technologia (np. Fizyka na GPU), techniki i oczekiwania klientów w zakresie tego, co chcą zobaczyć, i konkurencji w sposoby, które często powodują, że programiści znów przechodzą na niski poziom, tak jak nawet w przypadku twórców stron internetowych, którzy teraz piszą niskopoziomowe moduły cieniujące GLSL w WebGL (tego rodzaju tworzenie stron internetowych jest prawdopodobnie nawet niższe niż dziesięć lat temu, ponieważ GLSL jest językiem C o bardzo niskim poziomie, a dziesięć lat temu nigdy bym nie zgadł, że niektórzy twórcy stron internetowych chcieliby pisać takie cieniujące moduły GPU).
Jeśli będzie sposób na przejście do obszarów wyższego poziomu w obszarach krytycznych pod względem wydajności, będzie musiał uzyskać więcej z oprogramowania, kompilatorów i narzędzi, które mamy, tak jak ja to widzę. Problemem w najbliższej przyszłości nie jest to, że sprzęt nie jest wystarczająco silny. Ma to więcej wspólnego z tym, że nie możemy znaleźć sposobu, aby najskuteczniej z nim rozmawiać za każdym razem, gdy zmienia się i rozwija, bez powrotu do swojego własnego języka. W rzeczywistości to szybkie tempo zmian sprzętowych sprawia, że programowanie na wysokim poziomie jest raczej nieuchwytne dla tych obszarów, jak widzę, ponieważ jeśli hipotetycznie nasz sprzęt przestanie się pojawiać niespodziewanie przez następne dziesięciolecia,
Zabawne jest to, że w dzisiejszych czasach, gdy pracuję w obszarach krytycznych pod względem wydajności, muszę nieco myśleć o niskim poziomie, niż zacząłem (mimo że zacząłem w erze Borland Turbo C DOS). Ponieważ wtedy pamięć podręczna procesora prawie nie istniała. Były to głównie pamięci DRAM i rejestry, co oznaczało, że mogłem skupić się bardziej na złożoności algorytmicznej i pisać powiązane struktury, takie jak drzewa, w bardzo prosty sposób, bez większego uszczerbku dla wydajności. Obecnie szczegóły niskiego poziomu pamięci podręcznej procesora dominują w moim prawie tak samo, jak sam algorytm. Podobnie mamy maszyny wielordzeniowe, które zmuszają nas do myślenia o wielowątkowości, atomach i muteksach oraz bezpieczeństwie wątków i współbieżnych strukturach danych itd., Co powiedziałbym, pod wieloma względami, o wiele niższym poziomie zainteresowania (ponieważ w, nie po ludzku intuicyjnie) niż wtedy, gdy zaczynałem.
Dziwne, wydaje mi się to teraz bardzo prawdziwe. Wydaje mi się, że bardziej wpływają na mnie niżej złożone 30 lat temu złożoności i szczegóły sprzętu, niż starałem się 30 lat temu, starając się zdjąć okulary nostalgiczne. Oczywiście moglibyśmy tutaj porozmawiać o asemblerze i musieliśmy poradzić sobie z pewnymi krwawymi szczegółami, takimi jak XMS / EMS. Ale w przeważającej części powiedziałbym, że wymagałem mniej złożoności i świadomości sprzętu i kompilatora niż wtedy, gdy pracuję w obszarach krytycznych pod względem wydajności. I wydaje się to prawie prawdziwe w całej branży, jeśli odłóżmy na bok jak pisanieif/else stwierdzenia w nieco bardziej czytelny dla człowieka sposób i zastanów się, ile osób obecnie myśli więcej o szczegółach niższego poziomu sprzętu (od wielu rdzeni przez procesory graficzne, przez SIMD po pamięć podręczną procesora i wewnętrzne szczegóły tego, jak ich kompilatory / tłumacze / biblioteki działają itd.).
Wysoki poziom! = Mniej wydajny
Wracając do tego pytania:
Jeśli tak, to w miarę jak poprawia się sprzęt, czy możemy oczekiwać, że języki wyższego poziomu przejmą przemysł gier?
Dla mnie nie chodzi o sprzęt. Chodzi o optymalizatory i narzędzia. Kiedy zaczynałem, ludzie praktycznie pisali wszystkie gry konsolowe w asemblerze, a wtedy istniała prawdziwa przewaga wydajności, szczególnie biorąc pod uwagę brak wysokiej jakości kompilatorów generujących 6502.
Gdy optymalizatory kompilatory C stały się inteligentniejsze w swoich optymalizacjach, zaczęły osiągać punkt, w którym kod wyższego poziomu napisany w C konkurował, a czasami nawet przewyższał kod napisany przez najlepszych ekspertów w wielu dziedzinach (choć nie zawsze), i to sprawiło, że przyjęcie C było przynajmniej bezproblemowe, przynajmniej w przypadku kodowania gry. Podobna zmiana stopniowo nastąpiła w pewnym momencie w C ++. Przyjęcie C ++ było wolniejsze, ponieważ uważam, że wzrost wydajności przejścia od montażu do C mógłby prawdopodobnie osiągnąć jednomyślne porozumienie ze strony gamedevów piszących nietrywialne gry całkowicie w ASM, w przeciwieństwie do przejścia z C do C ++.
Ale te zmiany nie wynikały z tego, że sprzęt stał się bardziej wydajny, ponieważ optymalizatory dla tych języków powodują, że obniżenie poziomu jest w dużej mierze (choć nie zawsze całkowicie, są pewne niejasne przypadki) przestarzałe.
Jeśli potrafisz sobie wyobrazić hipotetyczny scenariusz, w którym moglibyśmy napisać kod w kodzie najwyższego poziomu, jaki można sobie wyobrazić, bez obawy o wielowątkowość, procesory graficzne lub błędy pamięci podręcznej itp. (A może nawet o określone struktury danych), a optymalizator był jak sztuczna inteligencja inteligentny i potrafiłby wymyślić najbardziej efektywne układy pamięci, przestawiając i kompresując nasze dane, wymyśliłby, że może korzystać z niektórych GPU tu i tam, zrównoleglać trochę kodu tu i tam, użyć trochę SIMD, może sam się profilować i dalej optymalizować IR jako nas, ludzi odpowiadając na hotspoty profilerów, i zrobiło to w sposób, który pokonuje najlepszych na świecie ekspertów, to nie byłoby problemu, nawet dla osób pracujących w obszarach najbardziej krytycznych pod względem wydajności, aby go przyjąć ... i to jest postęp pochodzące z absurdalnie inteligentnych optymalizatorów, a nie szybszego sprzętu.