ASP.NET + Blazer vs React/Angular/Node/Vue

Rozmawianie teraz o wydajności WASMa jest bezcelowe, to dalej prawie MVP i dopiero wprowadzane są do niego takie ficzery jak współdzielona pamięć z JSem czy wielowątkowość, w dodatku nie może jeszcze operować na DOM. Na ocenę wydajności Blazora przyjdzie nam z 2-3 lata poczekać co najmniej.

Nech napisał(a):

Rozmawianie teraz o wydajności WASMa jest bezcelowe, to dalej prawie MVP

czy chcesz przez to powiedzieć że używanie WASMa także jest bezcelowe?
IHMO MVP to już jednak coś więcej niż prototyp czy inna zabawka dla deweloperów

Kamil Żabiński napisał(a):

czy chcesz przez to powiedzieć że używanie WASMa także jest bezcelowe?

WASMa jako całości nie, Blazera jako produkcyjnego frameworka frontendowego póki co tak.

Kamil Żabiński napisał(a):

Na szczęście informatyka i programowanie to bardziej inżyniera i nauka niż religia. Więc nie wystarczy powiedzieć, że jest "tak i tak". Trzeba jeszcze to udowodnić.
Jakieś benchmark? Czy WASM jest zawsze szybszy od JS? Czy "Hello World" jest szybsze w WASM niż JS? Czy jakbym miał odpowiednik JQuery w WASM to będzie szybciej? A może odpowiednik Vue? Gdzie jest punkt w którym WASM wyprzedza JSa? Jak duży do ma być projekt. Albo jaki rodzaj projektu? Więcej pytań niż odpowiedzi.

Pisałem projekt, który korzysta z WASM. Było to narzędzie projektowe. Jest nieporównywalnie szybszy od JS jeżeli chodzi o obliczenia. Grafika 3D, CSG itp. z pewnością przenoszą się do WASM. Threejs i babylonjs itp. są znacznie... wolniejsze. Inna rzecz, że czas uruchamiania to parę sekund.

PS. wiem, że są próby wykorzystania WASM w Threejs i babylonjs

Framework webowy to powinien raczej celować w wydajność stron z masą tabelek, formularzy, ramek, zakładek, dialogów, odświeżania danych na żywo, logiki biznesowej itp itd a nie wydajność grafiki 3D czy jakichś typów obliczeń praktycznie nigdy nie będących wąskim gardłem w webówce.

Poza tym nie zapominajmy o asm.js:
https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-native-performance-gets-even-narrower-with-float32-optimizations/
https://blogs.unity3d.com/2018/08/15/webassembly-is-here/
https://medium.com/@torch2424/webassembly-is-fast-a-real-world-benchmark-of-webassembly-vs-es6-d85a23f8e193
https://blog.acolyer.org/2017/09/18/bringing-the-web-up-to-speed-with-webassembly/

WebAssembly is on average 33.7% faster than asm.js, with validation taking only 3% of the time it does for asm.j.s
WebAssembly binaries are also compact, being on average 62.5% the size of asm.js, and 85.3% of native x86-64 code.

Czy "33.7% faster" to nieporównywalnie szybszy? Może po prostu źle coś zakodziłeś w JSie?

@Wibowit:

Framework webowy to powinien raczej celować w wydajność stron z masą tabelek, formularzy, ramek, zakładek, dialogów, odświeżania danych na żywo, logiki biznesowej itp itd a nie wydajność grafiki 3D czy jakichś typów obliczeń praktycznie nigdy nie będących wąskim gardłem w webówce.

wasm to nie framework webowy

druga sprawa jest taka, że twierdzenie jakoby web = tylko krudki, to chyba jakiś żart :D pierwszy lepszy przykład: gry, arkusze kalkulacyjne i ogólnie coraz więcej utility softu jest po dostępna przez przeglądarkę, ma to taką zaletę, że jest crossplatformowe by default.

już z rok temu były jakieś plany typu AutoCAD & WebAssembly: Moving a 30 Year Code Base to the Web

Temat jest o Blazorze, więc nawiązuję do Blazora i jego typowych zastosowań. WASM sam w sobie nie wymaga użycia Blazora w ogóle.

btw fajnie, że odpisałeś mi tylko na najmniejszą pierdółkę, a całe clou pominąłeś :D - WeiXiao 6 minut temu

W sumie nie wiem jakie było to clou, ale dopiszę, że bardzo ważna jest implementacja frameworka. Na https://www.techempower.com/benchmarks/ czy https://github.com/krausest/js-framework-benchmark widać, że w obrębie jednego języka można mieć dramatycznie różne wyniki wydajnościowe. ZTCP to taki ASP.NET osiągał bardzo kiepskie wyniki wydajnościowe na benchmarkach TechEmpower zanim MS się konkretnie tymi benchmarkami zainteresował (i teraz radzi sobie w nich np dużo lepiej niż Javowy Spring, który widocznie się tym benchmarkiem nie przejmuje). Za przechwałkami dotyczącymi wydajności powinny stać jakieś konkretne liczby z testów własnego frameworka, a nie stwierdzenia typu: komuś gdzieś tam WASM pomógł 10x, więc nam też pomoże.

@Wibowit:

o to, że coraz więcej softu z potencjałem do liczenia czegoś jest w webie, a nie tylko formularze i requesty

Ogólnie jestem za. Jeśli chodzi o testowanie przypadkowych programów to wolałbym by były osandboxowanymi WASMami niż EXEkami latającymi po ruskich forach. Z drugiej strony teraz jest tendencja do liczenia wszystkiego w chmurze, a więc jeśli ma być dużo mielenia danych w tym webowym arkuszu kalkulacyjnym to może to być odpalone na np serwerach Gugla, a nie laptopie czy smartfonie użytkownika.

Chodzi o to, że zastanawiam się jak Blazor może wypaść jako framework ogólnego przeznaczenia (czyli dla typowych apek webowych), a nie framework szczególnego przeznaczenia (przydatny małemu procentowi programistów C#). Jak myślisz: co będzie typowym zastosowaniem Blazora?

@Wibowit:

Jeżeli już będzie "mature", to wydaje mi się, że wiodące zastosowanie będzie takie jak reacta czy vue lub angulara.

Pisałem w nim coś większego niż hello world kilka miesięcy temu (mogło się coś poprawić) - kilka komponentów, zagnieżdżenia, parametry, routing, logowanie itd. i generalnie gdyby nie słabości tj. tooling(!!!) oraz ograniczenia WASMA, to chyba nawet byłby prod ready.

No to w takim razie trzeba tego Blazora testować w takich scenariuszach.

Właśnie się zorientowałem, że w https://github.com/krausest/js-framework-benchmark są wyniki WASMowej aplikacji. Wystarczy wejść na https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html w frameworks wybrać "vanillajs-keyed" i "wasm-bindgen-v0.2.47-keyed" i mamy porównanie Vanilla.JS kontra WASM-bindgen czyli konkretnie to: https://github.com/krausest/js-framework-benchmark/blob/master/frameworks/keyed/wasm-bindgen/src/lib.rs

wasm-bindgen jest średnio 5% wolniejszy od vanilla.js

Wibowit napisał(a):

Framework webowy to powinien raczej celować w wydajność stron z masą tabelek, formularzy, ramek, zakładek, dialogów, odświeżania danych na żywo, logiki biznesowej itp itd a nie wydajność grafiki 3D czy jakichś typów obliczeń praktycznie nigdy nie będących wąskim gardłem w webówce.

Poza tym nie zapominajmy o asm.js:
https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-native-performance-gets-even-narrower-with-float32-optimizations/
https://blogs.unity3d.com/2018/08/15/webassembly-is-here/
https://medium.com/@torch2424/webassembly-is-fast-a-real-world-benchmark-of-webassembly-vs-es6-d85a23f8e193
https://blog.acolyer.org/2017/09/18/bringing-the-web-up-to-speed-with-webassembly/

WebAssembly is on average 33.7% faster than asm.js, with validation taking only 3% of the time it does for asm.j.s
WebAssembly binaries are also compact, being on average 62.5% the size of asm.js, and 85.3% of native x86-64 code.

Czy "33.7% faster" to nieporównywalnie szybszy? Może po prostu źle coś zakodziłeś w JSie?

1. asm.js to co innego niż vanilajs. Zwykle nie pisze się go z ręki, tylko kompiluje (Emscripten ). W mojej opinii to taki krok pośredni w ewolucji do WASM, bo w większości przypadków ta sama biblioteka/framework generuje asm i wasm, wykrywane jest wsparcie i asm służy jako opcja dla gorszych przeglądarek. To z resztą nawet jest wprost napisane: "asm.js is mostly superseded by WebAssembly."
2. threejs, babylonjs i inne biblioteki 3D nie wykorzystują ani asm, ani wasm w wersji podstawowej. Można znaleźć implementacje experymentalne.
3. Te 33.7% w grafice 3d to przepaść. Od tego zależy, czy aplikacja będzie miała 19 fpsów, czy 29 fpsów na określonym urządzeniu. W dużych produkcjach zyskanie 1 milisekundy uważa się za sukces.
4. Ta wartość 33.7% jest pewną wartością uśrednioną i składają się na nią następujące rzeczy:
   a. To porównanie z asm.js, nie ze zwykłym jsem
   b. Jak przejrzy się wykres wydajności, to widać znaczne różnice z uwagi na konieczność interpretacji js. W zwykłym jsie pierwsze wykonanie funkcji zwykle oznacza chwilowy spadek wydajności, widoczny w FPSach - będzie to widoczne jako chwilowe przycięcie aplikacji, chociaż teoretycznie średnia nie odzwierciedli tego.
   c. W porównaniu obliczeń JS vs WASM zwykle przegrywa 4 krotnie (z moich testów tak wynika), ale tego nie sposób porównać, bo różne silniki mają różną wydajność dla różnych operacji.
   d. Wiele powszechnie używanych funkcji jest bardzo skutecznie zaimplementowana w powszechnie używanych przeglądarkach i praktycznie nie ma różnicy JS vs WASM, ale akurat nie dotyczy to takich zastosowań jak grafika 3d.

Dobrze zakodziłem w JSie. Porównywałem identyczne algorytmy.

Steve Sanderson on Blazor at NDC London: gRPC, Testing, and PWA capability

00:00 - 11:00: Talks about basic Blazor stuff previously known.

11:00 - 17:35: Shows binding to make a kind of dividing bar like on Humble Bundle.

17:35 - 31:15: Makes a product scanner "Blazor Mart" with Blazor + gRPC.

31:15 - 43:00: Test driven development to implement 'remove item' functionality.

43:00 - 48:00: Makes it a PWA by adding a service worker for temporary offline use.

48:00 - 49:50: Makes the web app installable in your OS (again, PWA).

49:50 - end: Talks about Server-side vs WebAssembly, 'Hybrid Blazor' (Electron). Shows of the beginning of 'Blazor + Native UI' for native mobile and desktop applications (no release date announced).

Kolejna prezentacja z NDC:

In this talk, Blazor's two architects will take you deeper into the framework, showing a range of more advanced features and their internal workings.

We'll dig into server-side Blazor and how we built the SignalR-based mechanism for efficiently streaming UI updates. Plus we’ll give you a guided walkthrough of how to build a high-quality redistributable Razor Class Library complete with friendly APIs, a static asset build system, and continuous deployment.

wloochacz napisał(a):

Poza tym, WASM z definicji ma być szybki i trudno mi uwierzyć, aby JS go dogonił.

Trochę odgrzewam, ale przypadkowo trafiłem na taki wpis WASM is slow. Dla wyjaśnienia TeaVM jest kompilatorem i maszyną wirtualną dla pomysłu Java -> Wasm.
Wpis ten skłonił mnie do refleksji jak często ludzie zakłamują benchmarki (świadomie lub nieświadomie). Piszą jakiś ładny kod proceduralno-matematyczny działający tylko na stosie. Nie używają sterty ani obiektów. I wychodzą im bardzo ciekawe wyniki.
Błąd polega na tym, że w normalnym życie tworzymy obiekty i mocno używamy sterty. W OOP - dużo, w OOP + FP - bardzo dużo (obiekty są mniejsze, niemutowalne i mają krótszy czas życia).

Teraz zastanawiam się czy by nie napisać jakiejś małej normalnej aplikacji (nie matematycznej) w Javie lub Scali (C# nie znam). Raz skompilować do JSa a raz do WASM i porównać wyniki. Oczywiście wynik i tak będzie obarczony niedoskonałościami transpilerów do JS i kompilatorów do WASM :/