[DLL] GMThreads

[PsichiX]

Lul, tu sie powoli robi gej-party ;p

[Kofel]

Odrazu gej-party... ja coś do niego czuje <3

[Nobody]

PsichiX maj mastah podziej się swą wiedzą ;D

[PsichiX]

Snake: Musze Ci powiedziec ze Twoj DLL jest nie wydajny na dluzsza mete - uzywajac go zauwazylem ze chyba nie zwalniasz pamieci uzywanej przez watki po ich wykonaniu - po niedlugim czasie pamiec sie strasznie zapelnia :/ dasz rade to naprawic? bo w takiej postaci dll jest niezdolny do dlugiej pracy :/

PS. zeby nie bylo - sprawdzalem w c++ i tam ja calkowicie czyszcze po sobie pamiec ale i tak jest ona zapychana przez tworzone watki.

[Snake]

Serio ? Hmm... może jakieś funkcje z GML nie mogą zwolnić użytej pamięci... później to sprawdzę.

[PsichiX]

Na dodatek chyba blokuje zuzyta pamiec bo z kazdym kolejnym wlaczeniem programu tworzacego watki coraz mniej czasu potrzebuje na wywalenie bledu z brakiem dostepu do pamieci :0

[Snake]

Hmm... znalazłem przyczynę, każda zmienna lokalna zdefiniowana w wątku nie jest zwalniana z pamięci. Będę musiał zwalniać "ręcznie" pamięć z runnera ;o Zauważyłem to dopiero, gdy użyłem tablic ;d

 

Jak byś dopatrzył się jeszcze, czy jakieś funkcje z GM-a nie zapychają czasami pamięci to napisz. Tymczasem muszę pomęczyć się z access violation...

[PsichiX]

Tyle ze ja wogole nie tworze zmiennych lokalnych, tworze same globale - i to jest zastanawiajace.. :0 To wracam do testowania reszty funkcji

[Snake]

Whoah ;o Z GM7 już się uporałem, jeszcze tylko dopisać instrukcje zwracania błędów do thread_last_error() i będzie można się wziąść za GM6. Jeszcze dzisiaj powinien być update ;p

[PsichiX]

podam Ci funkcje jakie uzywam w aplikacji (ich wartosc od razu wyslam do dlla):

 

instance_create(0,0,logo)

keyboard_check(ord('W'))

keyboard_check(ord('S'))

keyboard_check(ord('A'))

keyboard_check(ord('D'))

 

EDIT: przydalo by sie zrobic mozliwosc przypisania watku do danego obiektu (bez zabawy w with()) - zeby mozna bylo uzywac zmiennych lokalnych

 

PS. Chyba jestem jedynym ktory na powaznie zajal sie testowaniem tego dlla xD

[gnysek]

Albo jedynym, który rozumie zasadę jego działania :)

[PsichiX]

Snake: ciagle sprawdzam funkcje i musze powiedziec ze zuzycie procka siega max 25% (co jest dla mnie zadowalajace) ale za to co sekunde zuzycie pamieci wzrasta o 90-110 k :/ a uzywam co stepa wylacznie tych funkcji co podalem

[Snake]

Dzięki, sprawdzimy czy po update nadal będą wycieki pamięci przy tych funkcjach ;d Teraz w sumie usuwam całą pamięć alokowaną przez "kompilator" GM-a więc nie powinno być problemów, ale zawsze lepiej sprawdzić ;D

 

przydalo by sie zrobic mozliwosc przypisania watku do danego obiektu (bez zabawy w with()) - zeby mozna bylo uzywac zmiennych lokalnych

Nad czymś takim raczej nie chce mi się męczyć, nie wiem jakby to wpływało na runnera. Możesz napisać sobie taki skrypt z with żeby nie pisać w kółko ;p

GML

// arg0 - kod gml

// arg1 - wstrzymac?

// arg2 - id obiektu

// zwraca: uchwyt

return external_call( global._thread_create, "with (" + string( argument2 ) + ") {" + argument0 + "}", argument1 );

 

PS. Chyba jestem jedynym ktory na powaznie zajal sie testowaniem tego dlla xD

Nie dziwię się, jak potrzebujesz go do PlayGate ;D

 

btw. teraz zauważyłem, że zapomniałem dopisać w przykładzie gm definiowania i wywołania thread_create z argumentem "suspended?" xd

 

EDIT: Zapomniałem o return w skrypcie ;p

[PsichiX]

btw. teraz zauważyłem, że zapomniałem dopisać w przykładzie gm definiowania i wywołania thread_create z argumentem "suspended?"

z tym od razu sobie poradzilem. Mam nadzieje ze update do gm6.1 wyjdzie w miare szybko bo coraz bardziej przesuwa mi sie koniec roboty z frameworkiem :)

[Snake]

Ok, to testuj PsichiX ;p

 

Nowa wersja:

- Usunąłem ten wyciek pamięci

- Poprawka w skrypcie thread_create (drugi argument)

 

Download:

http://www.gmclan.org/up541_4_GMThreads13.html

[PsichiX]

No w końcu dziala jak należy :D teraz pozostała reszta testów

 

EDIT: w c++ nie dziala funkcja last error a plik naglowkowy i ladowanie funkcji z dlla mam dobrze napisane :/ wyglada normalnie jakby wykonywal jakas nieskonczona petle

EDIT2: hmm, ale tak sie dzieje tylko w jednym miejscu w pliku, zaraz to inaczej sprobuje rozwiazac

[Snake]

Poprawiłeś już ? Co było nie tak ? ;p

[PsichiX]

jak wiesz (bo widziales szkielet aplikacji w gm) mam 3 funkcje: jedna wykonywana na starcie, jedna na zakonczeniu a trzecia wykonywana co step i jak umiescilem kod z wykrywaniem bledow w funkcji tworzenia watku i dalem wykonywanie w funkcji na starcie to mi blokowalo aplikacje, ale jak dalem w stepie to spoko dzialalo. wiec po prostu dalem kod z wykrywaniem bledow do osobnej funkcji i dalem jej wykonywanie spowrotem na startup i wszystko o dziwo dzialalo. nadal nie wiem czego wtedy tak blokowalo ale grunt ze juz dziala, jak na razie nie mam zadnych skarg.

 

EDIT: i znalazlo sie cos w koncu - czy ten dll kasuje aby na pewno pamiec zajmowana przez watki? bo do PlayGate'a zwracam pewna wartosc i ta wartosc wyswietla poprawnie, a po wywolaniu innego watku w jakis sposob dane w zmiennej zostaja nadpisane(?) bo wyskakuje mi zupelnie inna wartosc niz byla na poczatku a nigdzie nie reallocowalem zmiennej ani nie zmienialem jej wartosci O.o

[Snake]

czy ten dll kasuje aby na pewno pamiec zajmowana przez watki? bo do PlayGate'a zwracam pewna wartosc i ta wartosc wyswietla poprawnie, a po wywolaniu innego watku w jakis sposob dane w zmiennej zostaja nadpisane(?) bo wyskakuje mi zupelnie inna wartosc niz byla na poczatku a nigdzie nie reallocowalem zmiennej ani nie zmienialem jej wartosci O.o

Wątki na pewno są zwalniane... hmm, zapodaj może jakiś przykład czy cuś gdy to występuje, bo ja nie zauważyłem niczego takiego. ;p

 

Aha, chyba nie próbujesz się dostawać z kilku wątków do jednej zmiennej jednocześnie ?

[PsichiX]

To aplikacja:

https://gmclan.org/up1105_4_PlayGateBeta_unsec_.html

 

A tu jest kod (C++ & GML) (czesc ktora sie dobiera do zmiennej):

 

start:

PlayGate.ExecuteResult(3,"global.player=PlayGateReturnDouble(instance_create(0,0,logo));");
player.id=PlayGate.GetResultDouble();
MessageBox(GMappHandle,"PlayGate Framework: system test.\nPlayGate system start!","PlayGate",MB_OK);
PlayGate.ExecuteResult(3,"PlayGateReturnChar('PlayGate User');");
player.nick=PlayGate.GetResultChar();
player.x=320;
player.y=240;
MessageBox(GMappHandle,player.nick,"PlayGate: Welcome!",MB_OK);

 

gdzie obiekt player ma nastepujaca zawartosc:

double id;
double x;
double y;
char* nick;

 

koniec:

MessageBox(GMappHandle,player.nick,"PlayGate: Good bye!",MB_OK);

 

Tak to sie robi, na starcie zawsze pokazuje dobrze "PlayGate User", ale nie wiem czemu sie tak kaszani - dziwne ze za kazdym razem reaguje inaczej, raz pokazuje na koncu "PlayGate User" a raz nic nie pokazuje albo taki smiec: "240." O.o

 

EDIT: A zaraz, cos mi tu niegra - moze blad jest w tym ze pobieram tylko wskaznik do lancucha znakow w pamieci GMa ("PlayGate User")? Moze jednak to bedzie dzialac jak przepisze to do zmiennej po prostu :D TAAA to chyba musi dzialac - zaraz sprawdze ;D

 

EDIT2: LOL DZIALA! ^^ tak jak myslalem - wystarczylo przepisac ze wskaznika znaki do tablicy w aplikacji

[Snake]

No i jest nowa wersja ;) Teraz jest wsparcie dla procesorów wielordzeniowych :D

 

Dodałem 3 nowe funkcje:

• thread_affinity_mask( UchwytWatku, Maska ) - ustawia maskę affinity (typ wektora bitowego) podanego wątku. Jak to działa ?

  Każdy bit podanej wartości (maski) rozprezentuje procesor (rdzeń) czyli np.

  3 w postaci binarnej to 0000 0011, więc wątek z taką maską będzie korzystał z pierwszego i drugiego rdzenia

  10 w postaci binarnej to 0000 1010, więc wątek będzie korzystał z 2 i 4 rdzenia.

  Żeby sobie dopasować taką wartość możecie użyć kalkulatora windowsowego w trybie naukowym.

  Jeśli funkcja zawiedzie - zwraca 0, w innym wypadku zwraca poprzednia maskę.

  more info: <a href="http://msdn.microsoft.com/en-us/library/ms686247(VS.85).aspx" target="_blank">http://msdn.microsoft.com/en-us/library/ms686247(VS.85).aspx</a>

• thread_ideal_processor( UchwytWatku, NumerProcesora ) - ustawia preferowany procesor (rdzeń) dla wątku. Numer procesora ustawiany jest od 0, czyli 0 = pierwszy rdzeń, 1 = drugi itd.

  Zwraca -1 gdy wystąpi błąd, inaczej zwróci poprzedni ustawiony numer procesora.

  more info: <a href="http://msdn.microsoft.com/en-us/library/ms686253(VS.85).aspx" target="_blank">http://msdn.microsoft.com/en-us/library/ms686253(VS.85).aspx</a>

• thread_num_of_processors() - Zwraca ilość rdzeni/procesorów.

Download:

http://www.gmclan.org/up541_4_GMThreads14.html

 

Podziękowania dla Maxpayna, za testowanie nowej wersji na swoim procku (Quad) :D

[Pieter]

no nieźle nieźle ;) oby tak dalej :D miejmy nadzieje, że yoyo wprowadzą wątki do gma po tym dll'u i miejmy nadzieje, że twój dll dalej będzie wydajniejszy :D

[Snake]

Oby wprowadzili ;D

Tylko że na pewno te wbudowane wątki działały by szybciej niż z GMThreads ;p Tzn, wątek tworzony przez GMThreads jest nieco opóźniony przy starcie, bo musi kompilować podany kod (kompilacja też odbywa się w wątku, więc to nie przerywa głównego wątku gry). Ale interpretacja odbywa się z taką samą szybkością, co w GM.

[Dawidds]

Nieźle, nieźle :P

 

I pytanie: W jakich sytuacjach te 2 pierwsze funkcje mają wywalać błąd? Jak niepoprawną wartość podam? Czy może jak Windows nawali? Bo nie do końca rozumiem :P

 

Hmmm... czyli teraz gra napisana przy udziale twojego dll'a będzie szybsza niż w samym GM'ie :P?

[Snake]

W thread_affinity_mask wystąpi błąd gdy podasz nieprawidłową maskę (nie odpowiadającą procesorom/rdzeniom, np. na komputerze z procesorem single-core dasz maskę dla dual-core), albo uchwyt wątku będzie nieprawidłowy.

W thread_ideal_processor wystąpi błąd gdy podasz nieprawidłową wartość w ProcessorNum, lub nieprawidłowy uchwyt wątku.

 

I tak, dzięki GMThreads gry mogą działać szybciej na procesorach wielordzeniowych. (właściwie to system operacyjny decyduje na którym procku/rdzeniu ma być wykonywany jakiś wątek i nie trzeba używać tych funkcji, bo mogą zostać przydzielone automatycznie, ale dzięki nim można lepiej tym zarządzać [w ogóle zarządzać ;D])

[Nobody]

WindowsXP o ile się orientuję przydziela wątki tylko jednemu rdzeniowi... Chyba, że w jakimś nowszym service packu to zmienili.

[Pieter]

jest też windows xp 64... ;p więc się mylisz ;)

[Nobody]

No dobra :P A żeby napisać coś na temat, to praca na kilku rdzeniach to naprawdę wypas. Dzięki temu będzie można o wiele przyspieszyć grę :P Niech się wszystko kisi na pierwszym rdzeniu, a gra będzie pracować na drugim ^^,

[Will]

Jakby to było takie proste to gier używających możliwości wielowątkowości było by około 90% a tak nie jest. Nawet bardzo doświadczeni programiści zastanowią się 40 razy zanim do swojego projektu zastosują multithreading. Tak więc zastanów się przez krótką chwile dlaczego.

[Marmot]

Dobra, ale ja mam takie pytanie - rozdzieli się prace na 4 rdzenie, spoko. A co jak ktoś ma tylko 2, albo tak jak ja, 1? Co wtedy? Połowa lub 3/4 instrukcji nie zostanie wykonana, czy to będzie jakoś rozdzielone na rdzenie istniejące? Jakby się programowało na konsolę, to tak można dawać, bo tam jest jeden i ten sam procesor, nikt go nie wymieni, i można zoptymalizować grę na maxa pod sprzęt konkretny, a w PC takiej możliwości nie ma, dlatego się pytam z tym przypadkiem, jak ktoś nie ma tylu rdzeni ile gra wykorzystuje.