Wykorzystanie oraz użyteczność WebAssembly

0

Jest nowy wynalazek jak WebAssembly. Ma służyć do programowania klienta webowego.
No ale to jest rodzaj asemblera w swojej maszynie wirtualnej - rzecz bardzo niskopoziomowa.

Jak to ma być użyteczne, jeśli nie powstają jakieś libki, klasy, obiektyw, frameworki wyższego rzędu?

Drugie, pochodne: da się pisać w niemal każdym języku, i kompilować do webassembly, np w C (he, he).
No dobra, wyrażenia arytmetyczne (mam nadzije, ze bez arytmetyki pointerów), if'y, pętle.
Ten kod w (dajmy na to) w C musiałby być zrobiony wobec jakiejś przeznaczonej do tego kontekstu biblioteki (by nie nazwać jej standardową), gdzie będą texEdity, DateEdity, Comba, taki HTML itd .... Dlaczego nie trafiam na takie wprowadzenia?

3

Przykładem takich już istniejących wysokopoziomowych libek i frameworków są wszelkiej maści silniki gier. Praktycznie każdy porządny silnik obsługuje teraz kompilację do WASM-a dzięki czemu można uruchamiać gry w przeglądarce (albo chociaż pokazywać w działaniu przykłady z dokumentacji).

2

Jak to ma być użyteczne, jeśli nie powstają jakieś libki, klasy, obiektyw, frameworki wyższego rzędu?

Powstają przecież nowe języki kompilowane do WebAssembly tudzież do istniejących języków się dorabia opcje kompilacji do Wasm(polecam Rust) A frameworki tez mogą powstawać - patrz Blazor do C# czy Yew dla Rust. Nie chodzi o to, żeby pisać bezpośrednio w Wasm, tylko żeby był to target kompilacji.

Ten kod w (dajmy na to) w C musiałby być zrobiony wobec jakiejś przeznaczonej do tego kontekstu biblioteki (by nie nazwać jej standardową), gdzie będą texEdity, DateEdity, Comba, taki HTML itd .... Dlaczego nie trafiam na takie wprowadzenia?

Zauważ, ze z Wasm można korzystać w ten sposób, ze cała apke piszesz w Wasm, a można tez zrobić tak ze Np. GUI apki w JS, a w Wasm tylko robić różne obliczenia (można nawet tak robić, ze Wasm ci wystawi obrobione dane w specjalnym buforze i to sobie odczytasz z poziomu JSa)

No i jeśli mam aktualne informacje (bo Wasm ciagle się rozwija, a były jakieś dyskusje o tym, żeby to zmienić ), to Wasm i tak nie ma dostępu do DOM, wiec jakiekolwiek GUI w Wasm i tak musiałoby by być obsługiwane tak naprawdę przez JS (można to zrobić w sposób przezroczysty dla aplikacji przez bindingi, wtedy wywołujesz jakaś funkcje w swoim kompilowany do Wasm języku i automatycznie się wywołuje funkcja JSowa, która robi faktyczna robote)

Dlaczego nie trafiam na takie wprowadzenia?

Przerób sobie jakieś tutoriale z Wasm, spróbuj skompilować jakiś prosty program pisany w języku który się kompiluje do Wasm, spróbuj zintegrować kod JS z modułem Wasm. Ogolnie warto w praktyce zobaczyć, na czym to polega.

0

@LukeJL:

Bez DOM ????
To tym bardziej nie rozumiem, po co taki zamiar ....

Czytam o Blazorze, namierzałem go sobie w głowie od dawna....

2
ZrobieDobrze napisał(a):

Czytam o Blazorze, namierzałem go sobie w głowie od dawna....

W blazor masz dwie możliwości: server site i client site. I Cilent site to Webassembly.

Ogólnie to chodzi o to, żeby odpalić kod w dowolnym języku (np skompilowane DLL) w przeglądarce. Na to chwilę i tak to trzeba jeszcze w większości obudować jakimś JS.

1
ZrobieDobrze napisał(a):

@LukeJL:

Bez DOM ????
To tym bardziej nie rozumiem, po co taki zamiar ....

Wyobraź sobie, że masz jakąś binarkę, która ma jakieś funkcje i możesz odpalać te funkcje w tej binarce.

Koncepcyjnie trochę jak używanie bibliotek DLL, nie wiem, czy używałeś (ja dawno temu, jak pisałem coś na Windowsach). Oczywiście moduły Wasm, a DLL to dwie różne rzeczy, ale koncepcyjnie podobna idea.

Albo wyobraź sobie backend. Na backendzie też nie masz DOMu, czy to znaczy, że nie jest potrzebny? No nie (z tą różnicą, że Wasm będzie sobie w przeglądarce i nie będzie miał kontaktu ze światem, ale podobnie jak backend, będzie mógł robić ci jakieś obliczenia i przetwarzanie danych - a moduły Wasm mają swoją pamięć i mogą trzymać jakieś dane. Możesz też te dane pobierać z Wasma albo przekazywać do Wasm).

0
S4t napisał(a):
ZrobieDobrze napisał(a):

Czytam o Blazorze, namierzałem go sobie w głowie od dawna....

W blazor masz dwie możliwości: server site i client site. I Cilent site to Webassembly.

Ogólnie to chodzi o to, żeby odpalić kod w dowolnym języku (np skompilowane DLL) w przeglądarce. Na to chwilę i tak to trzeba jeszcze w większości obudować jakimś JS.

Skupmy się na Blazor Client. To wobec tego ma jakieś znaczne zalety? Czy tylko IT-marketing na "nowe" ?
Np miałem nadzieję nie klepiemy klienta we frameworkach JS, a w ludzkim języku, ale jednak widzę że jednak bez JS się nie da ...

update: bo jak do niezgodności (np niezgodności walidacji, bo ktoś zapomniał po frontowca zadzwonić) server-side / client-side, ma dojść kolejny sprzęg, który trzeba utrzymywać ...

LukeJL napisał(a):
ZrobieDobrze napisał(a):

@LukeJL:

Bez DOM ????
To tym bardziej nie rozumiem, po co taki zamiar ....

... z tą różnicą, że Wasm będzie sobie w przeglądarce i nie będzie miał kontaktu ze światem, ale podobnie jak backend, będzie mógł robić ci jakieś obliczenia i przetwarzanie danych - a moduły Wasm mają swoją pamięć i mogą trzymać jakieś dane. Możesz też te dane pobierać z Wasma albo przekazywać do Wasm).

No ale jakie obliczenia - oprócz 1% nietypowych przypadków (CAD w przeglądarce? Gra?) - by się miało robić na kliencie weba?

0
ZrobieDobrze napisał(a):

No ale jakie obliczenia - oprócz 1% nietypowych przypadków (CAD w przeglądarce? Gra?) - by się miało robić na kliencie weba?

Dlatego do zwykłej webówki (gdzie na frontendzie trzeba po prostu wyklepać SPA) się tego nie używa. Ale jak ktoś robi coś, co wymaga dużej liczby obliczeń / działań na danych, to już okazuje się, że to jest przydatne. Podobnie jak ktoś chce przekompilować kod np. w C/C++, żeby dało się użyć na stronie (wcześniej była taka możliwość za pomocą Emscripten, ale Wasm jest szybszy, bo kompiluje do niskopoziomowego bajtkodu, a nie do JSa).

Może to być gra, renderer grafiki, baza danych, biblioteka do machine learning itp. Coś co wymaga dużej wydajności. Obstawiam, że w przyszłości również autorzy frameworków mogliby uznać, że napiszą część frameworka w Wasm dla większej wydajności (frameworki też muszą robić różne obliczenia, np. diffować wirtualny DOM)

Ew. po prostu normalna apka albo biblioteka, ale napisana nie w JS, a w języku, który da się skompilować do Wasm (C, C++, Rust itp. https://github.com/appcypher/awesome-wasm-langs ), którą chcesz przeportować i odpalić na stronie. Wasm jako coś, co ułatwia przenoszenie programów, wieloplatformowość.

0
ZrobieDobrze napisał(a):

No ale jakie obliczenia - oprócz 1% nietypowych przypadków (CAD w przeglądarce? Gra?) - by się miało robić na kliencie weba?

Wszystko? Pętlę, ify, regexy, parsowanie struktur danych z/do JSONa, jakieś sortowania, budowanie tablic, obliczenia służące do zbudowania widoku np. słynny virtual dom. Odpal profiler w dev toolsach na dowolnej stronie i zobacz ile zajmuje "scripting"

0

Plus specyfika JSa jest taka, że bardzo łatwo zrobić coś niewydajnie, bo nie ma ręcznego zarządzania pamięcią, tylko tworzysz obiekty na potęgę, a one się potem usuną w GC (co może samo w sobie spowodować spadek wydajności, jak będzie GC czyścił te obiekty), ew. zostaną w pamięci, czyli apka będzie zżerała o wiele więcej pamięci niż to potrzebne.

A przeciętny użytkownik JSa ma to w d...

2

można wywoływać jsa z wasma i wasma z jsa. wasm może być wyprodukowany z dowolnego języka, js także. przykład z rustem kompilowanym do wasma i współdziałającym z jsem: https://github.com/rustwasm/wasm-bindgen

mikrobenchmarki frontendowe: https://krausest.github.io/js-framework-benchmark/current.html

  • vanillajs to czysty javascript, bez vdoma i innych abstrakcji i jest najszybszy (ale z zastrzeżeniem 772)
  • wasm-bindgen to rust kompilowany do wasma i używający vdoma - prawdopodobnie konstrukcja jest bardzo podobna do vanillajs, ale dochodzi (de)serializacja danych i dlatego jest ciutkę wolniejszy niż vanillajs (i też ma zastrzeżenie 772)
  • blazor-wasm-aot-v6.0.1 to blazor webassembly z włączoną kompilacją ahead-of-time (to chyba oznacza, że nie ma tam interpretera bajtkodu) - jest jednym z najwolniejszych i najbardziej zasobożernych rozwiązań, jakieś 2x wolniejszy od angulara czy reacta
  • blazor-wasm-v6.0.1 to blazor webassembly bez włączonej kompilacji ahead-of-time (to chyba oznacza, że bajtkod .netowy przechodzi przez interpreter skompilowany do wasma, ale mogę się mylić) - jest jeszcze trochę wolniejszy niż blazor-wasm-aot

Known issues and notes
772 Note: Implementation uses manual DOM manipulations

co do:

Drugie, pochodne: da się pisać w niemal każdym języku, i kompilować do webassembly, np w C (he, he).
No dobra, wyrażenia arytmetyczne (mam nadzije, ze bez arytmetyki pointerów), if'y, pętle.

arytmetyka wskaźników w wasmie w pewnym sensie jest, tzn. wasm ma do dyspozycji tablice bajtów i sam je sobie obsługuje jak chce. jeśli masz wszystko upchnięte w jednej tablicy bajtów to możesz po niej indeksować jak chcesz, ale jest sprawdzanie czy indeks wychodzi poza granicę tablicy bajtów.

0
Wibowit napisał(a):

co do:

Drugie, pochodne: da się pisać w niemal każdym języku, i kompilować do webassembly, np w C (he, he).
No dobra, wyrażenia arytmetyczne (mam nadzije, ze bez arytmetyki pointerów), if'y, pętle.

arytmetyka wskaźników w wasmie w pewnym sensie jest, tzn. wasm ma do dyspozycji tablice bajtów i sam je sobie obsługuje jak chce. jeśli masz wszystko upchnięte w jednej tablicy bajtów to możesz po niej indeksować jak chcesz, ale jest sprawdzanie czy indeks wychodzi poza granicę tablicy bajtów.

tablica (po bożemu) to nie arytmetyka wskazników i na odwrót.
Stąd śmiechem spuszczam kompilowanie nie przygotowanego kodu C do WASM (a nawet nie wiem, jak miało to przygotowanie przebiegać - z braku konceptu tablicy)

To jeden z motywów do tego wątku, hurra-obietnice jak np kompilowanie C. "być moze" ktoś coś miał/ ma na myśli w rodzaju C, ale z tak totalnie inną biblioteka standardową, że to w praktyce niekompatybilny język
(Już rynek znał obiecanki cacanki efemerydy jak interpretery C, z tym że z prawdziwym C to nie miało wiele wspólnego, oprócz sterowania)

Drugim powodem - że ktoś to poprzedził prefiklsem "web".
Nic mi do tego a wręcz pozytywnie, chętnie bym kibicował pomysłom na nowe maszyny wirtualne, ale WASM w obecnym stanie akurat z webem ma najmniej wspólnego.

1
ZrobieDobrze napisał(a):

tablica (po bożemu) to nie arytmetyka wskazników i na odwrót.
Stąd śmiechem spuszczam kompilowanie nie przygotowanego kodu C do WASM (a nawet nie wiem, jak miało to przygotowanie przebiegać - z braku konceptu tablicy)

To jeden z motywów do tego wątku, hurra-obietnice jak np kompilowanie C. "być moze" ktoś coś miał/ ma na myśli w rodzaju C, ale z tak totalnie inną biblioteka standardową, że to w praktyce niekompatybilny język
(Już rynek znał obiecanki cacanki efemerydy jak interpretery C, z tym że z prawdziwym C to nie miało wiele wspólnego, oprócz sterowania)

nie znam się specjalnie, ale się wypowiem :)
na początku możesz zaalokować bardzo dużą tablicę bajtów (w sensie nie robisz tego z poziomu webassembly, a raczej żądasz tego od środowiska wykonawczego przy odpalaniu wasmowego kodu), np. 1 gigabajt. następnie piszesz własnego malloc i free, które alokują wewnątrz tej tablicy i zwracają indeks, który robi za wskaźnik. kompatybilność z podstawowymi zastosowaniami języka c wynosi 100% :] (na oko, pi razy drzwi)

1

Jak nie chcesz mieć arytmetyki wskaźników i chcesz mieć memory safe, to lepiej pisać np. w Rust, który jest z założenia memory-safe, a nie w C.

Z drugiej strony pisząc moduły Wasm w Rust i tak używałem unsafe do działania na mutowalnych zmiennych statycznych czy do przekazywania wskaźników luzem JS<->Rust. Może się dałoby zrobić inaczej, lepiej, tego nie wiem, ale na takie rozwiązanie wpadłem, że wymagało unsafe.

To jeden z motywów do tego wątku, hurra-obietnice jak np kompilowanie C. "być moze" ktoś coś miał/ ma na myśli w rodzaju C, ale z tak totalnie inną biblioteka standardową, że to w praktyce niekompatybilny język

Ale ludzie to robią. Nie wiem jak (i nie wiem, czy chcę wiedzieć 😂 kompilowanie C/C++ brzmi jak odwrotność dobrej zabawy), ale ludzie od lat portują kod C/C++ do Wasm (a wcześniej do JS, zanim istniał Wasm). https://hn.algolia.com/?q=ported+to+webassembly

Nic mi do tego a wręcz pozytywnie, chętnie bym kibicował pomysłom na nowe maszyny wirtualne, ale WASM w obecnym stanie akurat z webem ma najmniej wspólnego.

Bym się z tobą nie zgodził, ale (przez przypadek) masz rację.
WebAssembly potraktowany jako technologia webowa jak najbardziej ma z webem dużo wspólnego. Dlaczego by nie miał mieć?
Natomiast przez przypadek masz rację o tyle, że ludzie, którzy się tym zajmują, uznali, że zastosowania Wasm wykraczają poza Web. Wtedy Wasm można by odpalać natywnie, poza stroną internetową. Np. po to, żeby zsandboksować kod natywny. https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

2

nie wiem, w którym wątku są teraz dyskusje o blazorze (w wersji webassembly), ale ten chyba będzie ok :) sorry za lekkie odkopywanie

najnowsze wyniki blazor wasm w https://github.com/krausest/js-framework-benchmark są dość ciekawe. zajętość pamięci tego blazora to teraz około pół gigabajta (zarówno przy kompilacji aot jak i odpalaniu pod interpreterem). frameworki javascriptowe mają zajętość pamięci zwykle poniżej dziesięciu megabajtów. ta różnica bierze się pewnie z tego, że blazor wasm prealokuje te pół gigabajta po to, żeby potem w tej puli pamięci robić sobie (emulować) dowolną arytmetykę wskaźników.

najświeższe wyniki na chwilę obecną są dostępne pod link z ustawieniami, które są widoczne na screenshotach

testy autor przeprowadził na maku:

The benchmark was run on a MaBook Pro 14 (32 GB RAM, 8/14 Cores, OSX 12.6), Chrome 106.0.5249.61 (arm64)) using the puppeteer benchmark driver with reduced tracing.

blazor wasm jest dalej około 2x wolniejszy od angulara czy reacta:
screenshot-20221008144048.png
rozmiar paczki (którą musi ściągnąć przeglądarka) po skompilowaniu i skompresowaniu to dalej megabajty. w przypadku blazor wasm te mikrobenchmarki ważyły (już po kompresji) aż 12 megabajtów!
screenshot-20221008144358.png
a tutaj zużycie pamięci, które w przypadku blazor wasm jest kosmicznie wysokie w porównaniu do wszelakiej konkurencji:
screenshot-20221008144505.png
we wcześniejszych edycjach benchmarka, zużycie pamięci dla blazor wasm było bardzo małe. strzelam, że to dlatego, że nie liczyli zużycia pamięci przez wątki inne niż główny (blazor chyba standardowo działa dwuwątkowo, javascript jest odpalany w wątku głównym, a webassembly chodzi sobie asynchronicznie w tle). możliwe też, że chodzi o coś innego.

przypominam, że wasm-bindgen to rust skompilowany do webassembly, a więc da się w webassembly zrobić lekką stronę.

1 użytkowników online, w tym zalogowanych: 0, gości: 1