Eve Online > Dyskusje ogólne
LAGFIELD vs battlefield
Ellaine:
64 bity moga sie przydac do dlugich zmiennoprzecinkowych wspolrzednych statku w systemie, mnozony, dzielonych, odejmowanych i dodawanych w jednej operacji procesora a nie kilku.
Wielkosc kodu czy pamieciorzernoc raczej nam powinna wisiec. Prote zaalokowanie powyzej 2 giga na proces moze sie przydac. No ale rewolucji to raczej nie ma. Rewolucja to byla przy przejsciu z 8 na 16 bitow :)
Serwery sa w stackless pythonie wiec programisci maja umiarkowana wladze nad takimi rzeczami jak wielkosc wskaznika, alokacja pamieci etc. "przejscie na 64 bity" moze tu oznaczac zainstalowanie innej wersji pythona i sprawdzenie czy dziala :)
Fizyk:
hmm. No właśnie Vril się nie znasz, przejście na 64 bitową platformę jest istotne i może byc niezwykle istotne. Z punktu widzenia asemblera wykonanie jakiejś instrukcji na wskaźniku języka C++ ( naprzykład ) jest wykonaniem określonego rozkazu w określonym trybie adresowania. Wiem że mało kto pisze w asemblerze ale kompilacja kodu C++ do języka maszynowego i tak sprowadza go do takiej postaci ( nie dosłownie ale bardzo blisko ). Fakt 64 bity przydają się do spraw związanych z grafiką itd ( taka jest cecha rozwoju komputerów w ostatnich latach - wrost możliwości obliczeniowych głównie tam gdzie można go stosować w grafice itd. ) i fakt sa to głównie liczby zmiennoprzecinkowe z ich odmienną od stałoprzecinkowej arytmetyką, więc i jednostka zmiennoprzecinkowa ( FPU ) w procesorze ( CPU ) dostaje bonusa. Tak się jednak składa że 64 bitowe rejestry są w jednostce stałoprzecinkowej ( ALU ) i to dzięki nim procesor nazywa sie 64-bitowym. Są to rejestry ogólnego przeznaczenia w jaki sposób je wykorzystasz to akurat procesorowi wisi do operacji zmiennoprzecinkowych ma swoje własne rejestry 80-bitowe ( lub większe )................... Dobra nie ma sensu opisywać tego zbyt szczegółowo, faktem jest że spadek wydaności jeśli istnieje to spowodowany jest prostym przeniesieniem środowiska 32-bitowego na 64-bitowe ( takie środowisko po prostu nie wykorzystuje możliwości jakie daje nowa platforma ). Naprawdę 64-bity mają duże możliwości wystarczy uzmysłowić sobie na jak wielkiej bazie danych wykonuje się obliczenia, w nowym środowiski po prostu każdy rozkaz będzie mógł przerabiać dwa razy więcej danych chociażby były to bajty ( w 32 bitach 4*8 bit w 64 8*8bit )
Racje ma Albi pisząc ze sprowadzi się to do nowej 64-bitowej wersji pythona da to jakiś bonus ale aby wszystko działało jeszcze lepiej, CCP powinno po prostu przepisać całą EVkę i skompilować ponownie pod środowiskiem 64-bitowym właśnie.
adam000 nie dokońca tak jest, gridy też stosują pewną dynamikę. Wyobraźmy sobie taką sytuację: Stawiasz bańkę między bramami wpada na nią flota i ty ze swoimi ludkami warpujesz się na tą bańkę. W tym momencie okolica "staje sie pewnym gridem". Pewnie nie zaczyna jej obsługiwać oddzielny serwer czego jak myślę chciałbyś od CCP ale mimo wszystko. Zastanów się co by się stało gdyby jednak nad okolicą bańki przekazano innemu serverowi, pewnie mogłoby sie spotkać i 1000 statków w tym miejscu ale sam moment przekazywania innemu serverowi takej ilości danych to crash jeśli nie samego servera to połączeń może połowy tej floty. Pewnie można byłoby zastosować rozwiązania z współczesnej informatyki ( np. tablica skoków - to jakaś analogia pewne obiekty np. własnie bańki/posy w "obleganych" systemach są wyróżnione bo wokół nich może się coś dziać. W tym przypadku zaraz pojawiliby sie kumaci ludzie którzy odkryliby na co zwracać uwagę i po prostu wykorzystywali by błędy, niedoróbki w oprogramowaniu. Tak jak w przypadku zachowań goonsów z ich ukochanym logofski manewrem - vidae strata posa z podukowanym prez LV tytanem ) Piszesz że każde zdarzenie ma swoje odbicie w bazach danych i słusznie ale program nie może tego przewidzieć ze 100% pewnością dlatego idea ruchomych gridów o kturych ty piszesz może sie nie sprawdzić. Pewnie aby zrobic to z jak największa dokładnością i fachowścią trzebaby przeanalizować ogromna ilość danych może się wieć okazać że ewentualne zyski są zbyt małe w stosunku do kosztów.
p.s. Wielkość słowa jako taka się nie zmienia bo jest z góry określona ( to tak jak niuton w układzie SI ) i wynosi dwa bajty czyli 16 bitów a 64-bity to po prostu cztery słowa - choć fakt coraz częście słyszy się słowo procesora intel czy coś w tym stylu
p.s.2 Rewolucji nawet przy przejściu z 8 na 16 bitów nie było, współczense procesory nadal noszą twarz procesora 8086 a wszystko przez kompatybilnosc.
p.s.3 Dopiero teraz przyszło mi do głowy że mimo wszystko CCP robi cholernie dobrą robotę i byc może uczesniczymy w symulacji jaka nie miała miejsca w całej historii człowieka.
Sorki za urywane myśli ale na zajęcia mi śpieszno. Pozdrawiam
adam000:
Przerzucanie miedzy serwerami wcale nie musi być takim problemem, przy skakania miedzy systemami się przecież odbywa, warp mógł by działać zupełnie podobnie. A gdyby jakiś "grid" zaczynał "puchnąć" od statków to właśnie nie on by się przerzucał gdzie indziej tylko "wypychał" inne mniej obciążone "gridy" ze swojego serwera, ludziom w nich na chwilę pojawiał by się komunikat o "jakiś zakłuceniach przestrzeni" czy coś równie "kosmicznego" :-) i było by OK
P.S. Piszecie, że serwerowa strona EVE jest napisana w pythonie... trudno mi w to uwierzyć, jeżeli tak jest to tym bardziej nie ma się co dziwić, że to wszystko nie wrabia i po każdej większej zmianie w kodzie wyłazi pełno błędów. Nie wiem czy próbowaliście pisać coś niebanalnego w języku bez statycznej kontroli typów, ja spróbowałem raz i to nawet nic specjalnie wielkiego i można się na prawdę zdziwić. Na początek trzeba się nazgadywać jakich typów (klas) parametrów oczekują jakieś "obce" funkcje/metody, a na koniec się okazuje, że jak coś jest nie tak to wyjdzie to w najmniej odpowiednim momencie kiedy akurat wykona się (i wywali) kod, który zazwyczaj się nie wykonuje. W momencie kiedy projekt ma kilka lat i pracuje nad nim wiele osób a dokumentacja pewnie jest taka jak to zazwyczaj jest :-) to tylko współczuć im można i podziwiać, że jakoś to działa.
P.S.2 A na myki z logowaniem też jest prosty sposób - nie wydaje wam się, że znikające w przestrzeni po wylogowaniu pilota statki to lekkie "przegięcie" rzeczywistości. A można by to załatwić tak prosto, statki nie powinny znikać tylko sobie jak teraz odwarpować gdzieś w przestrzeń, oczywiście gdyby tak sobie wisiały w przestrzeni to były by banalnym łupem więc powinny mieć możliwość bronienia się same, tak jak NPCe ale nie jak NPCe powinny dysponować całym swym ogniowym i obronnym potencjałem i powinny mieć przynajmniej tyle "inteligencji" żeby uciekać jeżeli nie mają szans na wygraną, a może lepiej żeby w ogóle zawsze najpierw uciekały do dopiero złapane walczyły. Do tego można by dołożyć jakiś prosty system wydawania im poleceń przez członków gangu/corpa żeby w wypadkach awaryjnych (ich pilot nie może wrócić do gry) można je było odeskortować do stacji.
Ellaine:
Eve to nie portal w php, gdyby dokumentacja byla tam taka jak zazwyczaj jest, to bysmy teraz grali co najwyzej w karcianke :)
Stackless Python to dosc egzotyczny jezyk w ktorym Eve jest najwiekszym istniejacym projektem. Moze sie roznic od oryginalu w roznych miejscach, bo AFAIK, ktos go napisal od zera.
marcoos:
--- Cytat: adam000 w Maj 17, 2007, 12:02:30 ---P.S. Piszecie, że serwerowa strona EVE jest napisana w pythonie... trudno mi w to uwierzyć, jeżeli tak jest to tym bardziej nie ma się co dziwić, że to wszystko nie wrabia i po każdej większej zmianie w kodzie wyłazi pełno błędów. Nie wiem czy próbowaliście pisać coś niebanalnego w języku bez statycznej kontroli typów, ja spróbowałem raz i to nawet nic specjalnie wielkiego i można się na prawdę zdziwić. Na początek trzeba się nazgadywać jakich typów (klas) parametrów oczekują jakieś "obce" funkcje/metody, a na koniec się okazuje, że jak coś jest nie tak to wyjdzie to w najmniej odpowiednim momencie kiedy akurat wykona się (i wywali) kod, który zazwyczaj się nie wykonuje. W momencie kiedy projekt ma kilka lat i pracuje nad nim wiele osób a dokumentacja pewnie jest taka jak to zazwyczaj jest :-) to tylko współczuć im można i podziwiać, że jakoś to działa.
--- Koniec cytatu ---
Nie wiem w czym pisałeś, że miałeś takie problemy - i nie wiem, w czym programowałeś wcześniej. Ale właśnie python jest jednym z lepiej zaprojektowanych i nadających się do dużych projektów językiem programowania. Faktem jest, że większość dokumentacji jest po angielsku - ale tak niestety jest z większością języków programowania. Eve jest napisana w specjalnej wersji pythona (tzw. bezstosowa) i żeby było ciekawiej działa to po stronie serwera, a także klient też z tego korzysta. Oczywiście język programowania to nie wszystko - Jest duże prawdopodobieństwo, że błędy popełniono podczas projektowania systemu... ale na to już żaden język programowania nie pomoże :). Poniżej wycinek z FAQ ze strony EVE:
How is the game logic implemented in EVE?
EVE uses a special Stackless version of Python for both the server and the client. This makes for a much simpler creation of game logic than what was available in the past. The control structures provided by Stackless allow for a more “procedural syncronous” model, rather than an “event driven asynchronous,” or thread pooling.
In more simplified terms, this means that a large number of actors can perform tiny tasks without the added complexity or overhead of the other two execution models. Our game logic scripters are thereby freed from many of the mundane tasks associated with models that don’t benefit from the control structures provided by Stackless. The creative process of writing interesting game behavior is no longer bogged down by software or system limitations.
This approach also means that making changes to the game is much easier than it has been historically. Many improvements or tweaks can be added even when the world is online and going strong without the need to reboot the servers. This process is called a hot fix.
Nawigacja
[#] Następna strona
Idź do wersji pełnej