Autor Wątek: Disney kupił rocket engine  (Przeczytany 4784 razy)

Offline vashpan

  • Użytkownik
    • Strona

# Marzec 04, 2011, 15:59:34
Ja tam nie wiem jaki jest sens pisania obliczen na GPU w JavaScripcie czy w przegladarce... Gmail bedzie tego uzywal czy co ? :)

Sama kompilacja niczego nie zalatwia, istotne sa optymalizacje. C, C++ czy D latwo sie optymalizuje bo sa to jezyki dosc bliskie sprzetowi, w miare prosto mozna stworzyc kod maszynowy a i tak wszyscy widza jak dlugo trwa kompilacja... Jednym slowem - krotka kompilacja, a taka musialaby byc zeby kompilowanie JavaScriptu "na raz" mialo sens, odbywalaby sie kosztem optymalizacji.

Zupelnie inna kwestia jest to ze JS to jezyk dynamiczny, zupelnie nie przystajacy co bliski assemblerowi C... Nie spodziewalbym sie wiec tutaj jakiegos kosmicznego wzrostu wydajnosci.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline skoti

  • Użytkownik

# Marzec 04, 2011, 16:43:56
Ja tam nie wiem jaki jest sens pisania obliczen na GPU w JavaScripcie czy w przegladarce... Gmail bedzie tego uzywal czy co ? :)
W założeniu ten sam co WebGL - do gier.  Czyli jeśli chcesz stworzyć grę z wydajnymi obliczeniami fizyki to bierzesz port pod JS silnika Bullet 3 (który ma liczyć wszystko w OpenCL) i wydajność JS Cię nie rusza.
Ale ogólnie przyda się w wielu obliczeniach i niekoniecznie pod GPU - OpenCL działa praktycznie na wszystkim (również procesorach Intel/AMD gdzie kod OpenCL (bliski C), jest kompilowany przez ich implementacje do x86 (według intela tak wydajny jak z ICC - ale jeszcze daleko do tego ;p), i wykorzystuje świetnie SSE (dużo lepiej niż w wypadku kompilatorów C gdzie nie ma typów wektorowych jak float4 i zdefiniowanych w języku działań dla nich aby kompilator sam bez problemu wiedział, że to ma zrobić na jednostkach wektorowych)).

Sama kompilacja niczego nie zalatwia, istotne sa optymalizacje. C, C++ czy D latwo sie optymalizuje bo sa to jezyki dosc bliskie sprzetowi, w miare prosto mozna stworzyc kod maszynowy a i tak wszyscy widza jak dlugo trwa kompilacja... Jednym slowem - krotka kompilacja, a taka musialaby byc zeby kompilowanie JavaScriptu "na raz" mialo sens, odbywalaby sie kosztem optymalizacji.
Kompilacja nie musi być jakaś mega wydajna w stronach internetowych (tym bardziej, że rzadko na stronach jest tyle kodu JS, aby długo musiał kompilować (na tych stronach gdzie jest go dużo warto poczekać raz, a później w cache będzie już binarny gotowy kod)) - ale pewnie nie byłaby taka jak w C/C++ - jednak wystarczająco dobra aby generować lepszy kod niż AS z Flash czy porównywalny z Silverlight - o wydajności C/C++ raczej nie ma co marzyć (w wypadku JS - w wypadku OpenCL pewnie będzie szybszy niż kod wypluwany przez większość programistów (którzy w życiu ręcznie SSE nie wykorzystają)).

Offline Esidar

  • Użytkownik

# Marzec 04, 2011, 16:48:26
Warto zwrocic uwage na jeszcze jedna technologie Google'a: Native Client, ktora powoli bedzie zmierzala do stabilnego Chrome.
No właśnie ja nie zrozumiałem co przyświeca autorom tego pomysłu. Tzn. ok, sandbox/security/stability, ale jeśli dobrze zrozumiałem, to jest odpowiednik Java JNI, czyli ma ten sam problem, że developer musi sam stworzyć grę/aplikację która jest w wersji x86, x86-64, ARM, Windows, Linux, Mac czyli żeby to działało przynajmniej na desktopie, to trzeba zrobić 6 różnych aplikacji.
IMO z tego powodu nie przyjął się szeroko OpenGL w Java, bo Java nie ma natywnego wsparcia dla GL tylko trzeba się posiłkować kilkoma osobnymi-niezależnymi bibliotekami wczytywanymi przez JNI.

Dużo sensowniejsze jest włożenie 3D do Flash/Silverlight czyli rozwiązanie out-of-box. I podejrzewam że mimo że OGL był możliwy przez JNI w Java od paru lat, to dopiero teraz zobaczymy znaczne zwiększenie się ilości gier 3D przez przeglądarkę.

Nie przemawia do mnie też argument że HTML/JS "bo działa wszędzie". Problem w tym że na platformach mobilnych wydajność tego jest tak mała, że nie da się zrobić czegoś porządniejszego. Sunspider na iPad 1 iPad 1 osiągał 8000ms co w porównaniu z desktopem (u mnie na Chrome 200ms) pozostawia wiele do życzenia. iPad 2 już ma "tylko" 2100ms, ale nie zmienia to faktu, że 3D w HTML to rozwiązanie na siłę. Robienie gier 3D w przeglądarce pozostaje nadal pozostaje w domenie desktopu, a tutaj mamy już cały wachlarz rozwiązań.

No i gdyby Google przestało promować słabe rozwiązania i np. Chrome by defaultowo instalował Flash/Java/Silverlight, to byłoby dużo ciekawiej :)

[Edit]
jednak wystarczająco dobra aby generować lepszy kod niż AS z Flash czy porównywalny z Silverlight
Niestety zarówno AS jak i JS to języki dynamiczne. Nie dorównują Silverlight (Java). Tutaj jest całkiem spoko test http://www.timo-ernst.net/misc/riabench-start/ . W kilku testach jest całkiem nieźle, ramię w ramię, ale w zadaniu typowo matematycznym (MD5) JS (na Chrome) poległo zajmując 500ms vs Silverlight 15ms. A wiadomo że gry dość sporo wykorzystują matematyki, czy to do macierzy 3D, czy do fizyki.
« Ostatnia zmiana: Marzec 04, 2011, 16:59:33 wysłana przez Esidar »

Offline lukasyno

  • Użytkownik

# Marzec 04, 2011, 17:30:37
No i gdyby Google przestało promować słabe rozwiązania i np. Chrome by defaultowo instalował Flash/Java/Silverlight, to byłoby dużo ciekawiej :)

flash jest juz dawno domyslnie w chrome
http://webhosting.pl/Flash.Player.bedzie.domyslnie.dolaczany.do.instalacji.Chrome

Offline vashpan

  • Użytkownik
    • Strona

# Marzec 04, 2011, 17:52:31
@Esidar:

Z NativeClient nie mialem do czynienia z punktu widzenia programisty, ale wydaje mi sie ze jest to osobna platforma/target. Nie sa tam odpalane osobne binarki/exeki, ale specjalne binarki przygotowane specjalnie pod NativeClient - a wiec portujemy aplikacje raz, korzystajac z dostepnego wachlarza bibliotek. Oczywiscie portowac trzeba- to fakt. Ale istotne jest jedynie API - jezeli bedzie spojne, sama kompilacja na wiele architektur to juz pikus. Po prostu tworzyc aplikacje bedziemy na jednej platformie, ale kompilator w targecie release bedzie wypluwal kod na n-architektur. Minus tego jest oczywiscie taki, ze biblioteki beda musialy byc przekompilowane pod taka "platforme" Dobrze by bylo jakby Google wydal jakies spojne, wysokopoziomowe API, jako ze ta technologia wydaje mi sie jest przeznaczona glownie na Chrome OS, mozliwosc pisania natywnych aplikacji na ten system calkowicie zmienilaby jego sytuacje.

Tak ja to przynajmniej widze, podobnie robi Apple od ladnych paru lat na kilku plaszczyznach, raz przy przejsciu z PPC na x86 - binarki ( kazdy plik wykonywalny i kazda biblioteka w systemie lacznie z jadrem!) mialy kod na obie platformy i jedyna rzecz o ktora przewaznie trzeba bylo sie martwic bylo wcisniecie przycisku "Build" w Xcode.  Teraz identyczna sytuacja jest z x86 i x86_64, i dzieki temu od paru lat na OS X praktycznie kazda nowa aplikacja z automatu jest 64-bitowa, ten sam system mozna odpalic w trybie 32 i 64bitowym za pomoca jednego przelacznika kernela przy bootowaniu. To samo rozwiazanie jest tez uzywane w iOS, tam kod jest na armv6 i armv7, dzieki czemu mozna korzystac trywialnie z plusow obu platform ( glownie chodzi o tryb Thumb i inne pierdoly - na starszych urzadzeniach dzialal wolniej, na nowszych szybciej - stad pewnie dwie wersje kodu )  Podczas gdy pod Windowsem ze swieca szukac 64bitowych aplikacji ( nie mowiac juz o tym ze sa 2 wersje systemu operacyjnego )

Jak komus sie jednak zaparai zrobienie 64bitowej wersji aplikacji pod Windowsem, to wszystko wymaga podwojenia ( libki, dll, exeki, do tego przydalby sie jakis launcher ktory to sklei -> za duzo roboty wiec wiekszosc odpuszcza ). MS spartolil tutaj sprawe po calosci, po czesci jednak to tkwi w srodku systemu ktory nie przewidywal takich rozwiazan.
« Ostatnia zmiana: Marzec 04, 2011, 17:58:47 wysłana przez vashpan »

Offline Dab

  • Redaktor
    • blog

# Marzec 04, 2011, 19:21:14
Cytuj
Zupelnie inna kwestia jest to ze JS to jezyk dynamiczny, zupelnie nie przystajacy co bliski assemblerowi C... Nie spodziewalbym sie wiec tutaj jakiegos kosmicznego wzrostu wydajnosci.

Ja dalej twierdzę, że ludzie gadający o Javascripcie na GPU nie widzieli na oczy albo Javascriptu albo pisania na GPU.

Offline skoti

  • Użytkownik

# Marzec 04, 2011, 19:43:27
Nie przemawia do mnie też argument że HTML/JS "bo działa wszędzie". Problem w tym że na platformach mobilnych wydajność tego jest tak mała, że nie da się zrobić czegoś porządniejszego. Sunspider na iPad 1 iPad 1 osiągał 8000ms co w porównaniu z desktopem (u mnie na Chrome 200ms) pozostawia wiele do życzenia. iPad 2 już ma "tylko" 2100ms, ale nie zmienia to faktu, że 3D w HTML to rozwiązanie na siłę. Robienie gier 3D w przeglądarce pozostaje nadal pozostaje w domenie desktopu, a tutaj mamy już cały wachlarz rozwiązań.
Teraz telefony i tablety osiągają taką wydajność (m.in dlatego, że silniki są optymalizowane pod x86), ale ten rynek szybko zyskuje na wydajności - dziś królują tam 2x core 1.0 GHz procki, ale w połowie roku mają już być w sprzedaży 4x core 1.5GHz (Tegra 3) z jednostkami wektorowymi NEON.
Co do iPad2 to on poza prockiem standardowym jak na nowe smartfony/tablety (2x 1GHz ARM Cortex A9), ma kilka rdzeni PowerVR SGX543 (nie pamiętam dokładnie ile), a one są dosyć wydajnymi GPU obsługującymi OpenCL (co twórca OpenCL czyli Apple wykorzysta z pewnością), i mogą zawstydzić nie jeden procesor w obliczeniach (tym bardziej, że może liczyć to GPU i CPU razem z jednostkami NEON równolegle).

Niestety zarówno AS jak i JS to języki dynamiczne. Nie dorównują Silverlight (Java). Tutaj jest całkiem spoko test http://www.timo-ernst.net/misc/riabench-start/ . W kilku testach jest całkiem nieźle, ramię w ramię, ale w zadaniu typowo matematycznym (MD5) JS (na Chrome) poległo zajmując 500ms vs Silverlight 15ms. A wiadomo że gry dość sporo wykorzystują matematyki, czy to do macierzy 3D, czy do fizyki.
Nie wiem na czym robiłeś ten test JS, ale mi w FF4 słaby C2D osiąga 210ms, a Opera 140ms - Flex osiąga 50ms, Silverlight przez mono 20ms, ale to nic nie zmienia - wszystko zależy od jakości kodu binarnego generowanego przez kompilator (nie jest ważne jaki to język).
Co do wydajności w wypadku matmy związanej z grami to tu najszybszy będzie właśnie OpenCL dostępny z JS (WebCL) dzięki wykorzystaniu optymalnym jednostek wektorowych na których większość takich obliczeń powinna być wykonywana.

Offline vashpan

  • Użytkownik
    • Strona

# Marzec 04, 2011, 20:12:50
Ciezko porownywac rozne przegladarki i rozne silniki webowe. U mnie w Chrome wyniki podobne jak u Dab'a. Intel E5200, FF4 moze byc lepszy rzeczywiscie w tym tescie...

Miniaturyzacja ma swoja cene, cene wydajnosci. Zawsze bedzie prawdziwy podobny schemat szybkosci: Mainframe > Workstation > Desktop > Laptop > Netbook > Tablet >= Smartphone, procenty sie za bardzo nie zmienia...

Dodatkowo zawsze w informatyce nowa wydajnosc wykorzystywano bardziej na kolejne warstwy abstrakcji niz przyspieszenie istniejacych rozwiazan... Przez co realny postep jest raczej nikly :)

Ja wciaz nie wyobrazam sobie programistow JavaScript dlubiacych optymalizacje w OpenCL... :)

Offline skoti

  • Użytkownik

# Marzec 04, 2011, 21:36:05
Miniaturyzacja ma swoja cene, cene wydajnosci. Zawsze bedzie prawdziwy podobny schemat szybkosci: Mainframe > Workstation > Desktop > Laptop > Netbook > Tablet >= Smartphone, procenty sie za bardzo nie zmienia...
Tak - z pewnością mobilne urządzenia nie osiągną szybko mocy jaką mają GPU z Desktopów... ale za to w obliczeniach jak fizyka nawet mobilne karty graficzne powinny być co najmniej takie szybkie jak Desktopowe procesory i już da się dzięki temu nie jedno wykonać (to, że nie będzie można robić tego co mogą robić Desktopowe GPU (np. symulacja płynów/dymu w RT), da się przeżyć).

Ja wciaz nie wyobrazam sobie programistow JavaScript dlubiacych optymalizacje w OpenCL... :)
Raczej nie będą z tym mieli większych problemów jak z pisaniem w OpenGL i shaderów GLSL - czyli do tego typu zadań będą zatrudniane osoby znające te Api niekoniecznie z JS.

Offline Esidar

  • Użytkownik

# Marzec 04, 2011, 23:47:07
wszystko zależy od jakości kodu binarnego generowanego przez kompilator (nie jest ważne jaki to język).
Język ma znaczenie. Jeśli w specyfikacji jest że "wywołanie metody z obiektu null rzuca wyjątek", to kod run-time musi przy każdym wywołaniu sprawdzać czy obiekt jest null'em. Jeżeli język jest dynamiczny, jak np. JS, to przy kompilacji nie da się sprawdzić typ parametrów wchodzących do funkcji, więc trzeba to zrobić w run-time, itd
Wróćmy do Quake II na JS. Na Mac'u kolesie osiągneli 20fps na GPU. Mało imponujący wynik jak na grę która miała 400fps działając na Pentium 3 i na GeForce 2. Ten port to jest chyba najlepszy test wydajności JS (bo GPU raczej nie jest tutaj problemem). Znacznie bardziej miarodajny niż latająca w kółko jedna funkcja. Kolesie z Google którzy zrobili ten port Quake II na JS, podsumowali go jako "ciekawostkę żeby zobaczyć ile JS potrafi, ale jeśli ktoś myśli o robieniu gier to warto się zainteresować NaCL".


Offline vashpan

  • Użytkownik
    • Strona

# Marzec 04, 2011, 23:52:02
@skoti

Nigdy nie osiagna mocy GPU z Desktopow, na przeszkodzie stoi zwykla zasada zachowania energii :) Nie ma szans zbudowac w tej samej technologii GPU ktore pobierajac 1W pradu przescignie taki co pobiera 100W

Narazie wciaz silniki fizyczne nie wykorzystuja GPU sensownie, z prostego powodu - najbardziej powszechna czesc silnika fizycznego - czyli symulacja bryly sztywnej - nie jest trywialna do zrobienia na GPU, a nawet jezeli bedzie zroionia - wcale nie musi byc duzo szybsza niz ta na CPU

Obecnie fizyka liczona z pomoca GPU to lekkie nieporozumienie, co najwyzej mozemy sobie popatrzec na zwisajace szmaty i wieksza ilosc czasteczek, przy duzym spadku wydajnosci graficznej... Mialem nadzieje na wiecej.

Offline skoti

  • Użytkownik

# Marzec 05, 2011, 09:42:38
Język ma znaczenie. Jeśli w specyfikacji jest że "wywołanie metody z obiektu null rzuca wyjątek", to kod run-time musi przy każdym wywołaniu sprawdzać czy obiekt jest null'em. Jeżeli język jest dynamiczny, jak np. JS, to przy kompilacji nie da się sprawdzić typ parametrów wchodzących do funkcji, więc trzeba to zrobić w run-time, itd
I co z tego? Niby inaczej jest z Javą czy C#, że starasz się tym argumentem powiedzieć, że JS nie da się zrobić szybszego kodu niż generują one?

Wróćmy do Quake II na JS. Na Mac'u kolesie osiągneli 20fps na GPU. Mało imponujący wynik jak na grę która miała 400fps działając na Pentium 3 i na GeForce 2. Ten port to jest chyba najlepszy test wydajności JS (bo GPU raczej nie jest tutaj problemem). Znacznie bardziej miarodajny niż latająca w kółko jedna funkcja. Kolesie z Google którzy zrobili ten port Quake II na JS, podsumowali go jako "ciekawostkę żeby zobaczyć ile JS potrafi, ale jeśli ktoś myśli o robieniu gier to warto się zainteresować NaCL".
Nie wiem po co chcesz wracać do Quake II testowanym na wcześnej wersji wsparcia dla OpenGL ES 2.0 (WebGL), który w kartach desktopowych jest w OpenGL 4.1 dopiero, a przeglądarki działają na OpenGL 2.1 robiąc własny wrapper na OpenGL (Mozilla ze względu na stery AMD/Intel do OpenGL na windowsie ma wrapper z OpenGL ES do DX), w silniku JS, który jest wolny (co nie znaczy, że nie da się go przyspieszyć) - tym bardziej jeśli matma będzie robiona na jednostkach SIMD tego co sobie wybierzesz, a w wypadku Flash/Silverlight na CPU bez dostępu nawet do SSE.

Nigdy nie osiagna mocy GPU z Desktopow, na przeszkodzie stoi zwykla zasada zachowania energii :) Nie ma szans zbudowac w tej samej technologii GPU ktore pobierajac 1W pradu przescignie taki co pobiera 100W
 
Osiągną moc dzisiejszych GPU (ale wtedy GPU już będą dużo wydajniejsze ;]). Tu jednak nie chodzi o dogonienie GPU z desktopów, ale o dogonienie desktopowych CPU przez GPU mobilne w specyficznych dla gier i grafiki obliczeniach (które bardzo GPU pasują).

Narazie wciaz silniki fizyczne nie wykorzystuja GPU sensownie, z prostego powodu - najbardziej powszechna czesc silnika fizycznego - czyli symulacja bryly sztywnej - nie jest trywialna do zrobienia na GPU, a nawet jezeli bedzie zroionia - wcale nie musi byc duzo szybsza niz ta na CPU
Nie jest trywialne, ale nawet testowa implementacja CUDA z końca 2008 w Bullet, której daleko do optymalnego działania na GPU działa bardzo dobrze (zresztą po tym teście zdecydowano się na przepisanie całego Bullet do OpenCL, a nie zrobieniu wersji takiej jak PhysX gdzie część jest CPU-only).

Obecnie fizyka liczona z pomoca GPU to lekkie nieporozumienie, co najwyzej mozemy sobie popatrzec na zwisajace szmaty i wieksza ilosc czasteczek, przy duzym spadku wydajnosci graficznej... Mialem nadzieje na wiecej.
Dziś jedynym silnikiem który pozwala na obliczenia na GPU działa tylko na Nvidii i właśnie jedyne co można dodawać to nieistotne dla rozgrywki powiewające flagi itp. (bo gra musi działać też na CPU only na kartach Ati). Nie ma spadku wydajności generowania grafiki (Grafika generowana jest tyle samo - tylko fizyka liczy się dłużej i dłużej czekasz na klatkę).

Offline Esidar

  • Użytkownik

# Marzec 05, 2011, 12:15:49
I co z tego? Niby inaczej jest z Javą czy C#, że starasz się tym argumentem powiedzieć, że JS nie da się zrobić szybszego kodu niż generują one?
Stwierdzam że "język ma znaczenie". I tak, w wielu przypadkach JS nie wygeneruje tak szybkiego kodu jak Java/C#. Chyba że nadal będziesz udowadniać że JS jest równie dobre bo "a+b" jest równie szybkie co w C#.

Nie wiem po co chcesz wracać do Quake II testowanym na wcześnej wersji wsparcia dla OpenGL ES 2.0
Powtórzę: GPU/GPUAPI nie ma tu żadnego znaczenia. Wrapper GL/DX czy jakikolwiek inny, nie spowalnia kodu 30x. PIII - 400fps, C2D - 20fps. Do the math. SSE też nie jest tutaj cudownym lekarstwem. Nie przyśpieszy kodu 2x, bo żeby osiągnąć te minimum 2x, trzeba też reorganizować dane, a tego kompilator nie zrobi.

Zresztą nie rozumiem o co kruszysz kopie ? Gry w JS to ciekawostka, z której niektórzy skorzystają. Ani Flash ani Silverlight nie znikną nagle, ani też nie przestaną się rozwijać. Java jest w sieci od wielu lat, ale to Flash zyskał miano platformy do gier. JS ma jeszcze przed sobą wiele problemów do rozwiązania (sam o nich pisałeś) i nie stanie się to w przeciągu 1 roku.