Silnik TorchSpigot z obsługą wielu rdzeni zamiast sektorów - to dobry plan?

[macjoker007]

tak jak w temacie

torchspigot to fork ( czyli adaptacja ) silnika paperspigot z wieloma poprawkami i systemem multi-thread ( czyli obsługą wielu rdzeni )

 

link do listy build'ów dla wersji 1.11.2

https://circleci.com/gh/TorchSpigot/Torch/tree/master

link do pobierania bezpośredniego bez rejestracji, build #260

https://260-61716775-gh.circle-artifacts.com/0/tmp/circle-artifacts.vI3rcGl/Torchpowered-1.11.2.jar

skan

https://www.virustotal.com/pl/file/a1093276a20ec330e8ec3ff15a96cffc2e30418ea757333ed00f443530e6adc4/analysis/1501315107/

git projektu

https://github.com/TorchSpigot/Torch

gif przedstawiający czym są sektory ( wiele osób o to pyta )

http://i.imgur.com/JVMZ7vj.gifv

[MarcinWieczorek]

Spigot jest sam w sobie wielowątkowy, a jak wiadomo jeden rdzeń procesora potrafi dzielić się czasem i zasobami pomiędzy wątkami. Czy rozwiązanie z TorchSpigota faktycznie kładzie jakiś nacisk na wykorzystywanie kilku procesorów i współdzielenie zasobów (np korzystanie jednocześnie z FPU i ALU przez dwa różne wątki)? Przyznam, że nie wiem jak wygląda natywny support JVM dla takich rozwiązań.

[GotoFinal]

@macjoker007 @MarcinWieczorek @Wielki Posejdon

To ja ostrzegam że projekt to gnój, autor kompletnie nie ogarnia tematu, tylko usłyszał że wątki są dobre i wpierdziela je wszędzie gdzie się da, jedyne co to przyniesie to bugi, crashe i... gorszą wydajność.

 

Ale jak już zaczynam temat to polecę trochę dalej, bo ctrl napisał że spigot jest wielowątowy - no i jest to tak właściwe prawda, jednak odbiega to znacznie od takiej idealnej wielowątkowości jaka przyniosłaby nam porządną wydajność.

Wielowątkowość w spigoie...

są wątki od połączeń, dzięki czemu sam odczyt danych od klientów nie zamula serwera + jest tam też pierwszy etap logowania, więc spam botami bez premek na serwerach online-mode nie jest mocno odczuwalny bo boty są w innych wątkach. (jest też w zwykłym minecrafcie, ale warto dodać że spigot miał to pierwszy)

jest wątek od czatu, dzięki czemu spam wiadomościami też nie wpływa na wydajność. (też jest w zwykłym mc)

jest też osobny wątek od światła (nie ma w mc)

mamy też oczywiście pluginy używające tasków w async - pool z innymi wątkami.

jest też wątek pilnujący serwera - zgłasza i ubija serwer jeśli ten przez X sekund nie wykonał ani jednego ticku - czyli prawdopodobnie się zaciął. (chyba też jest w mc)

 

No i jest wątek główny... ten który ogarnia wszystkie ruchy entity, graczy, wszystkie interakcje, aktualizacje bloków, fizykę, wszystko, co jednak jest znacznym problemem, bo sam ogarnia prawie całą grę. Każdy event pluginu też leci w tym wątku, komendy itd itp. (no są też wątki async)

 

 

 

Idealnym rozwiązaniem by było gdyby wiele wątków potrafiło obsługiwać te czynności i same się dzielić robotą, tworzyć nowe, usuwać nadmiarowe - taki plan jest w diorite, ale czy kiedyś powstanie to uj wie.

W diorite mapa ma być dzielona na sektory, tyle że zamiast każdy sektor być osobnym serwerem, to sektory są niewidoczne, to dalej jeden serwer, a sektory są dzielona dynamicznie, w zależności od obciążenia to inne chunki stanowią sektor - tak by żaden z sektorów nie zostawał w tyle i nie spowalniał innych, a jednocześnie by nie nawalić 400 wątków kiedy nie ma takiej potrzeby.

 

A torch spigot... nawiał dziwnych wątków, np osobny wątek od pakietów, kiedy to i tak ma już osobny wątek.

Do tego zamiast robić to jak spigot i inne rzeczy, an zasadzie patchy i mappingów, on ma cały kod mc w repo i go aktywnie edytuje, co oznacza że aktualizowanie tego na nową wersję MC będzie bardzo trudne i kosztowane, wręcz niemożliwe.

Chyba najgorsza klasa w całości: https://github.com/TorchSpigot/Torch/blob/master/sources/src/main/java/org/torch/server/Regulator.java osobny wątek do którego wysyla zadania, i tyle... żadnego skalowania itd, ot taki jeden dziwny wątek.

[macjoker007]

@ref

[macjoker007]

@ref

[macjoker007]

@ref