A Unity rendkívül népszerű játékmotorkülönösen átfogó és könnyen használható szerkesztőeszközeivel.
A motornak azonban követnie kell a gépek fejlődését: tíz évig a processzorok nem a frekvencián, hanem a magok számán növekednek. Más szavakkal, Az új elérhető teljesítmény kiaknázásához a játékoknak különböző magokon kell futtatniuk a kódot, különböző szálakon keresztül.
Attól a pillanattól kezdve, hogy a technológia rendelkezésre áll, néhány játék valóban sikeres. Valójában az ilyen kód megírásával számos probléma merül fel.
E hátrányok elkerülése érdekében lehetséges néhány szabályrendelet betartása. Ez az egyik oka annak, hogy a Unity a C # új fordítóján dolgozik, Burst néven amellyel, ha ezeket a szabályokat nem tartják be, fordítási hiba lép fel.
Elérni ezt, a kódot az elvégzendő feladatok gyűjteményeként kell megírni. Ezen feladatok mindegyike végrehajt néhány átalakítást az adatokon.
A programozónak meg kell határoznia azokat a memóriaterületeket, amelyekhez csak olvashatóan férhet hozzá, és azokat, amelyekhez adatokat szeretne írni és olvasni- A fordító megbizonyosodik arról, hogy ezen deklarációkon kívül nem használ semmit.
Ezután az ütemező meghatározza e feladatok valós idejű végrehajtásának legjobb módját ezzel a kiegészítő információval: biztosíthatja, hogy egyetlen feladat se írjon olyan adatokat, ahol például valaki más próbál olvasni vagy írni.
A Burst nemcsak a párhuzamos programozást hivatott elősegíteni: a legkritikusabb részeken is használják (teljesítmény szempontjából) a Unity kódot.
Eddig ezeket C ++ nyelven írták, de a jelenlegi fordítók nem teljesen kielégítőek.
Valójában, ha egy fejlesztő azt akarja, hogy egy ciklus vektorizálódjon, nincs garancia arra, hogy a fordító például két vektor közti összeadás miatt a fordítónak hivatalosan be kell bizonyítania, hogy minden lehetséges és elképzelhető esetben a két vektor nem felel meg ugyanazoknak a memória címeknek).
Miért a Burst és nem egy létező fordító?
A teljesítmény kritikus pont, ha egy ciklust nem vektorizálnak, ez valós probléma, amelyet gyorsan orvosolni kell.
Ezen túlmenően, generált binárisnak biztonságosnak kell lennie, adott puffertúlcsordulási hibák esetén és a veszélyes hivatkozásokat a lehető leghamarabb fel kell fedezni, tényleges hibaüzenetekkel, nem pedig meghatározatlan viselkedéssel (ami sok biztonsági problémát okoz).
Szembesülve ezekkel a felvetett igényekkel, még mindig ki kell választania ennek a fordítónak a beviteli nyelvét- A C, C ++, C # változata vagy részhalmaza, vagy egy új nyelv?
Az új nyelv nem jó lehetőség, mivel eleinte elkerüli, hogy embereket kelljen képeznie ezzel az új eszközzel.
A C # a felhasználók szempontjából előnyben részesíti, Mivel a játékmotor már használja, a játékokkal azonos nyelven lesz kódolva.
Ezen túlmenően, A C # már nagyon nagy ökoszisztémával rendelkezik, éppen ellenkezőleg, a C ++ még mindig szenved C örökségétől, nem mindig nyilvánvaló meghatározandó záradékokkal és hatalmas fordítási időkkel, hibákkal, amelyeket a C ++ 20 részben kijavít, a teljesítmény iránti rögeszméje ellenére.
Úgy döntöttek, hogy folytatják a C # -val, de számos teljesítményt akadályozó elem eltávolításával, például a szokásos könyvtár, többnyire a szemétszállítás és az engedélyek.
A Burst nem igazán működik teljes fordítóként, mivel nem sok kódot vesz be inputként, hanem csak a belépési pontot egy döntő ciklushoz.
Csak függvényként állítja össze, valamint mindent, amit hív. Az optimalizálás szintje rendkívül magas: mivel a Burst a kód egyes részeire összpontosít, időbe telhet.
A Burst első iterációja a HPC # és a feladatrendszerrel együtt a Unity 2018.1 verzióval érkezett.
A létrehozott kód néha gyorsabb, mint az előző C ++ verzió, néha lassabb, de a fejlesztők bíznak abban, hogy mindig legalább ugyanolyan teljesítményt fognak elérni, mint a C ++.
forrás: blogs.unity3d.com