XNA i C # vs procesory 360 w kolejności

14

Po przeczytaniu tego stwierdzenia , wydaje mi się, że prawdopodobnie mają rację (ponieważ Xenon i CELL BE są bardzo wrażliwe na rozgałęziony i ignorujący pamięć podręczną kod ), ale słyszałem, że ludzie świetnie sobie radzą z C #.

Czy to prawda, że ​​nie można zrobić nic profesjonalnego z XNA, czy może po prostu brakowało plakatu, co czyni XNA zabójczym API dla tworzenia gier?

Jako profesjonalista nie mam na myśli tego, że można na tym zarabiać, ale bardziej w tym sensie, że bardziej profesjonalne gry mają modele fizyki i systemy animacji, które wydają się poza zasięgiem języka z tak wyraźnymi barierami dla wewnętrznych . Jeśli chciałem napisać system kolizji lub silnik dynamiki płynów dla mojej gry, nie sądzę, że C # daje mi szansę, aby to zrobić, ponieważ generator kodu wykonawczego i brak elementów wewnętrznych przeszkadza w wydajności.

Wydaje się jednak, że wiele osób dobrze sobie radzi z tymi ograniczeniami, tworząc udane gry, ale najwyraźniej omijając problemy. Nie zauważyłem, że żadna z gier XNA robi coś bardziej złożonego niż to, co jest już dostarczane przez biblioteki lub obsługiwane przez shadery. Czy to unikanie bardziej złożonej dynamiki gry z powodu ograniczeń C # , czy po prostu ludzie koncentrują się na tym ?

Szczerze mówiąc, nie mogę uwierzyć, że wojna AI może utrzymać tyle jednostek AI bez pewnego podejścia zorientowanego na dane lub niektórych brudnych hacków C #, aby działało lepiej niż standardowe podejście, i myślę, że to częściowo moje pytanie, jak ludzie włamali się do C #, więc jest w stanie zrobić, co kodery gier robią naturalnie z C ++?

Richard Fabian
źródło
Rant rzeczywiście. Nie znajdując ŻADNEJ informacji o tym facecie i nie widząc, że jest (on?) Startupem, chciałbym zobaczyć wszelkie namacalne informacje na poparcie tego ...
Jonathan Connell
Z powodów, które nie do końca rozumiem, studia nie przyznają się do używania XNA. Istnieje jednak wiele przykładów linków
Tristan Warner-Smith
Cóż, oczywistą informacją do wykonania kopii zapasowej jest fakt, że procesor jest dość z natury zły w rozgałęzionym kodzie, jakim jest C #. Chciałbym wiedzieć, co robią profesjonalni użytkownicy XNA, co oznacza, że ​​nie osiągają miękkiego limitu narzuconego przez C #?
Richard Fabian
3
nie rozumiem głosowania w dół ...
FxIII
3
Myślę, że wiele osób odrzuca pytanie Richarda z powodu (licznych) błędów technicznych w jego powiązanym artykule, a niektórzy dręczą się słowem „profesjonalista”, co oznacza „produkcję na poziomie Halo”, a nie „zarabiają pieniądze”. To drugie jest kiepskim wyborem, ale nie głosuj negatywnie tylko dlatego, że nie zgadzasz się z linkiem - obal go, odpowiadając zamiast tego.

Odpowiedzi:

21

OK, po prostu wybić kilka dziur w tym rant, który połączyłeś:

  • „C # korzysta z interpretera„ Just In Time ” - źle - jest to kompilator JIT . Po jednokrotnym zastosowaniu metody JIT skompilowany kod jest ponownie wykorzystywany dla każdego wywołania. Skompilowany kod jest bardzo podobny do natywnego, wstępnie skompilowanego kodu.
  • „Procesor ksenonowy to„ procesor ”na miejscu - czy on ma na myśli„ w porządku ”? - I: „Procesor ksenonowy nie ma przewidywania gałęzi” . Sugeruje to, że oznacza to, że kompilacja JIT w naturalny sposób wytwarza zły kod, który musi być ponownie uporządkowany przez CPU i powoduje wiele rozgałęzień - co jest absolutnym nonsensem . Te same porady dotyczące wydajności dla tej architektury procesora dotyczą zarówno C ++, jak i C #.
  • „[JIT] wymaga ciągłego opróżniania na 360” - źle, skompilowany kod może być przechowywany w pamięci podręcznej, jak każdy normalnie skompilowany kod. (Jeśli ma na myśli spłukanie rurociągu, patrz powyższy punkt).
  • „generics [...] używają generowania kodu” - generics są JITowane jak wszystko inne i, podobnie jak wszystko inne, kod JITted jest szybki. Nie ma ograniczenia wydajności za używanie leków generycznych.
  • „wszystkie seksowne fragmenty języka [...] wymagają przewidywania gałęzi ...” - jak to nie dotyczy również C ++? - „... lub [...] generowanie kodu w miejscu” - czy on ma na myśli JITting? Czy wspomniałem, że jest szybki? (Nie będę wchodził we wszystkie miejsca, w których CLR na komputerze używa faktycznego generowania kodu - funkcja nie obsługiwana przez Xbox 360!)
  • „[C # nie ma] ogromnych bibliotek [C ++]” - oprócz, powiedzmy, samego XNA? I wiele więcej . (Mimo to jest to dość słuszna kwestia).

XNA na Xbox 360 działa na zmodyfikowanej wersji .NET Compact Framework CLR. Nie mam wątpliwości, że nie odpowiada standardowi wersji komputerowej. JITter prawdopodobnie nie jest tak dobry - ale nie sądzę, żeby był zły . Dziwię się, że nie wspomniał o śmietniku, który jest okropny w porównaniu do CLR na komputery.

(Oczywiście - nie powinno być uderzenie śmieciarza w profesjonalnie opracowanej grze i tak , jak trzeba być ostrożnym z alokacji w każdej grze profesjonalnej jakości).

(W celu faktycznej dyskusji technicznej na temat .NET Compact Framework, być może zacznij od serii artykułów: Omówienie , Kompilator JIT oraz GC i sterty .)

To, że jest całkowicie nieokreślony w swojej terminologii, utrudnia nawet zrozumienie, co ma na myśli. Albo jest w trybie maksymalnego wyrażenia opinii, albo nie wie, o czym mówi.


Teraz, gdy mamy, że z drogi, oto kilka rzeczy, które nie przegapić za pomocą XNA na 360, raczej niż ojczysty :

  • Dostęp do jednostki SIMD / Vector do wykonywania naprawdę, bardzo szybkich obliczeń zmiennoprzecinkowych procesora
  • Możliwość użycia kodu języka ojczystego, który prawdopodobnie będzie trochę szybszy niż C #
  • Możliwość być trochę nieco leniwi w jaki sposób alokować pamięć
  • Gry XBLIG mają dostęp tylko do 4 z 6 rdzeni (ale wciąż otrzymujemy wszystkie 3 procesory i nie są też pełnymi rdzeniami, więc nie tracimy wiele) - nie jestem pewien, czy dotyczy to XNA innych niż XBLIG Gry
  • Pełny dostęp do DirectX do robienia naprawdę niejasnych podstępów graficznych

Warto również zauważyć, że są to tylko ograniczenia po stronie procesora. Nadal masz całkowicie darmowy dostęp do GPU.

Opisałem te rzeczy w tej odpowiedzi na to, co faktycznie jest tym samym pytaniem, co to. Jak wspomniałem w tej odpowiedzi, XNA jest absolutnie odpowiedni do „profesjonalnego” rozwoju .

Jedynym powodem, dla którego należy unikać, jest to, że nie można zatrudnić talentów C #, licencjonować silników C # i ponownie użyć istniejącego kodu C # w taki sam sposób, jak w przypadku istniejącej bazy wiedzy C ++. Lub ponieważ możesz również kierować reklamy na platformę, która nie obsługuje C #.

Oczywiście dla wielu z nas, którzy nie są „profesjonalnymi” programistami, XNA jest naszą jedyną opcją wejścia na konsolę Xbox 360, co sprawia, że ​​jest to kwestia sporna.


Aby odpowiedzieć na inne pytania:

Nic w języku C # nie powstrzymuje cię przed podejściem zorientowanym na dane w dokładnie ten sam sposób, w jaki używasz ich w języku C ++.

C # nie ma możliwości automatycznego wstawiania kodu w czasie kompilacji i (bez ruszania się w celu sprawdzenia) jestem prawie pewien, że JITter kompaktowego CLR nie umie wstawiać metod (może to zrobić CLR na pulpicie). Dlatego w przypadku kodu krytycznego dla wydajności może być konieczne ręczne wstawienie w języku C #, gdzie C ++ zapewnia pewną pomoc.

Prawdopodobnie większym powodem, dla którego nie często widuje się matematyki procesora, takich jak wykrywanie kolizji i symulacje płynów w języku C #, jest brak dostępu do jednostki wektorowej (jak wspomniano powyżej).

Andrew Russell
źródło
Nie pamiętam siebie, ale czy C # nie powstrzymuje cię przed iterowaniem prostych tablic? Pamiętam coś o tym, że zestawia on typy pierwszej klasy, takie jak int, float, char, i dlatego niektóre podejścia zorientowane na dane nie działają tak szybko, jak mogłyby. Czy to prawda? Co ja pamiętam
Richard Fabian
2
C # umieści typy wartości (nie tylko wewnętrzne - możesz tworzyć własne typy wartości), jeśli przypiszesz je do objecttypu. W wersji 1 (przed generics) nie można było umieścić ich w pojemniku innym niż tablica bez ich zapakowania. Ale w dzisiejszych czasach bardzo łatwo jest napisać kod bez pudełka. Profil CLR pozwala wykryć dowolne miejsce, w którym możesz boksować.
Andrew Russell
Czy w ogóle można mieć tłumacza JIT? Brzmi paradoksalnie.
Kaczka komunistyczna
Widziałem kilka technik kodu wątkowego, które klasyfikowałbym jako interpretację JIT. To zdecydowanie przypadek na krawędzi.
1
@ Roy T. „ XNA Math Library ” (część DirectX) i „ XNA Framework ” to dwie zupełnie różne rzeczy z bardzo niefortunnym zderzeniem nazw. Dokumentacja, do której prowadzą linki, nie ma zastosowania do XNA Framework. Typy matematyczne XNA Framework nie używają jednostki SIMD / Vector .
Andrew Russell,
5

Musisz zdefiniować „profesjonalista”. Czy możesz zrobić Angry Birds, Plants vs. Zombies itp.? Absolutnie. Czy możesz zrobić Crysis 2, COD, Halo? Wątpię. Używanie C # ma naprawdę wpływ tylko na gry, które są bardzo obciążające procesor, a także muszą wycisnąć każdy ostatni bajt pamięci (przegrywasz do wyrzucania elementów bezużytecznych), więc jest jeszcze bardzo dużo do zrobienia.

Jako narzędzie do nauki dla osób rozpoczynających pracę, narzędzie do tworzenia prototypów, platforma do pisania gier, które mogą poradzić sobie z kompromisem itp. Jest fantastyczny i ma dużą moc i prostotę, po prostu nie jest zaprojektowany do robienia tego, co koniecznie trzeba nazywaj grami „AAA”. Usuwa również wiele bólu i cierpienia, o które ludzie muszą się martwić dzięki przenoszeniu i kompatybilności między platformami.

Jeśli wymyślisz niesamowitą grę i napotkasz ograniczenia tego, co możesz zrobić z XNA, sugerowałbym bezpośredni kontakt ze stwardnieniem rozsianym, jeśli pomysł jest naprawdę wystarczająco dobry, mogą po prostu pozwolić ci uzyskać pełny rozwój. zestaw.

Roger Perkins
źródło
Czy mógłbyś jednak zrobić kiepską kontynuację Duke Nukem? ;)
Jonathan Connell
1
Większość testów porównawczych stwierdza, że ​​kod C # działa gdzieś pomiędzy 30% a 70% wolniej niż równoważny kod C (na PC). Jeśli weźmiesz pod uwagę, że większość gier nie jest związana z procesorem, a także, że krytyczne części kodu C # można napisać przy użyciu niebezpiecznego kodu, który może działać prawie tak szybko lub szybciej niż równoważny kod C (szybciej, ponieważ JIT ma znacznie więcej informacji dostępnych dla to niż kompilator, więc może dokonywać lepszych wyborów optymalizacyjnych) , widać, że C # doskonale nadaje się do gier AAA.
BlueRaja - Danny Pflughoeft
@BlueRaja: Niebezpieczny kod nie jest opcją dla większości
1
@BlueRaja: Warto zauważyć, że unsafekod jest często wolniejszy niż bezpieczny odpowiednik, ponieważ zmniejsza liczbę optymalizacji, które może wykonać CLR. Musisz to zmierzyć.
Andrew Russell
2
@Blueraja „Kiedy uważasz, że większość gier nie jest związana z procesorem”, cytowanie jest bardzo potrzebne? Nie pracowałem nad profesjonalnie opracowaną grą, która nie jest związana we wszystkich osiach. gdyby nie było, znaleźlibyśmy sposób, aby przenieść ładunek na tę część maszyny!
Richard Fabian
3

Prostym faktem jest to, że nie potrzebujesz dużej liczby wielokątów, pełnego oświetlenia HDR lub najciekawszej fizyki na świecie, aby stworzyć interesującą grę, a jeśli twój plan gry nie zawiera żadnej z nich, to dlaczego nie wybrać szybszej rozwiązanie czasu rozwoju?

bardziej profesjonalne gry mają modele fizyki i systemy animacji

Po prostu źle. Profesjonalne gry mają wszystko, czego potrzebują, aby wdrożyć swoją rozgrywkę i osiągnąć swój artystyczny wygląd, i nic więcej, a nawet nic mniej. Gra nie jest bardziej profesjonalna, ponieważ wygląda bardziej realistycznie lub ma bardziej szczegółową fizykę. Gra, która jest profesjonalna, osiąga cele gry i cele wizualne na czas, w ramach budżetu itp., A także dostarcza i przynosi zysk.

DeadMG
źródło
1
Wysoka liczba wielokątów i HDR spadłyby na kartę graficzną, prawda? Więc powinieneś spodziewać się dokładnie takiej samej wydajności w C # i C ++.
BlueRaja - Danny Pflughoeft
@BlueRaja: Dla nich też jest koszt procesora i pamięci - szczególnie na 360.
DeadMG
Mniej więcej w przypadku wywołań lib grafiki jest nieco więcej kosztów niż w przypadku kodu natywnego. Z drugiej strony współczesne biblioteki graficzne bardzo BARDZO starają się zmniejszyć liczbę wywołań w sterowniku na ramkę, ponieważ jest to jedno z głównych wąskich gardeł.
drxzcl