Wieso?

[Anonymer Nutzer]

Was genau macht WebAssembly jetzt besser als JIT kompiliertes JS in einer höchstoptimierten Laufzeitumgebung?

Rechtfertigt dies auch die Nachteile gegenüber JS? Sprich: Ich kann JS direkt selbst im browser debuggen. Mach das mal mit ner Binärdatei.

[andi_lala]

Ohne Source Maps kannst du heutzutags kein JS mehr sinnvoll debuggen. Jedenfalls nicht in einem modernen Stack. Und mit Source Maps kannst du auch mit WASM kompilierten Code debuggen.

[Anonymer Nutzer]

andi_lala schrieb:
--------------------------------------------------------------------------------
> Ohne Source Maps kannst du heutzutags kein JS mehr sinnvoll debuggen.
> Jedenfalls nicht in einem modernen Stack. Und mit Source Maps kannst du
> auch mit WASM kompilierten Code debuggen.


Hm. Okay, guter Punkt

[Xiut]

So weit ich das verstanden habe, soll Webassembly ja auch nur das können, was JavaScript kann. Entsprechend hoffe ich zumindest auf die Möglichkeit in JavaScript ganz normal entwickeln und debuggen zu können, es aber später dann in Webassembly compilieren zu können, so wie man ja normalerweise auch jetzt den JavaScript-Code durch minify und co. jagt, bevor man ihn wirklich produktiv einsetzt.

[Xiut]

andi_lala schrieb:
--------------------------------------------------------------------------------
> Ohne Source Maps kannst du heutzutags kein JS mehr sinnvoll debuggen.
> Jedenfalls nicht in einem modernen Stack. Und mit Source Maps kannst du
> auch mit WASM kompilierten Code debuggen.

Wieso sollte man ohne Source Maps nicht mehr sinnvoll debuggen können? Kommt ja stark darauf an, wann man den javaScript-Code durch entsprechende Tools jagt, was bei uns zum Beispiel erst dann der Fall ist, wenn es auf die Live-Server geht.

[laserbeamer]

Aus meiner Sicht ist der einzige Zweck mehr DRM.
Damit kann man noch besser obfuscaten und uns mehr dämlichen Kopierschutz aufzwingen.

[andi_lala]

Außer man muss den JS Code sowieso transpilen, damit man wenigstens eine halbwegs moderne und sinnvolle Programmiersprache nutzen kann.

[andi_lala]

Möglichkeiten für einen Kopierschutz gibt es im Web mehr als genug. Dafür braucht man kein WASM.

[twothe]

Die Antwort steht im Artikel. Laut Benchmarkgame ist JS unter Node.js mit allen erdenklichen Optimierungen ca. 6-7 mal langsamer als vergleichbarer C++ Code. In Zahlen bedeutet das, dass ein Spiel, dass unter C++ mit 60 FPS läuft, unter JavaScript mit 8-10 FPS laufen würde. Einfach gerechnet. Damit lassen sich viele Anwendungen schlicht nicht realisieren.

[rw]

Vielleicht weil man nicht mehr auf JavaScript angewiesen ist?

[RicoBrassers]

twothe schrieb:
--------------------------------------------------------------------------------
> Die Antwort steht im Artikel. Laut Benchmarkgame ist JS unter Node.js mit
> allen erdenklichen Optimierungen ca. 6-7 mal langsamer als vergleichbarer
> C++ Code. In Zahlen bedeutet das, dass ein Spiel, dass unter C++ mit 60 FPS
> läuft, unter JavaScript mit 8-10 FPS laufen würde. Einfach gerechnet. Damit
> lassen sich viele Anwendungen schlicht nicht realisieren.

Es handelt sich hier aber nicht um C++-Code, sondern um Wasm.
Du kannst mir auch gerne ausrechnen, dass ein Ferrari x-mal schneller als ein Golf ist. Das ist aber trotzdem irrelevant, wenn wir einen R8 fahren.

[Haxx]

RicoBrassers schrieb:
--------------------------------------------------------------------------------
> twothe schrieb:
> ---------------------------------------------------------------------------
> -----
> > Die Antwort steht im Artikel. Laut Benchmarkgame ist JS unter Node.js
> mit
> > allen erdenklichen Optimierungen ca. 6-7 mal langsamer als
> vergleichbarer
> > C++ Code. In Zahlen bedeutet das, dass ein Spiel, dass unter C++ mit 60
> FPS
> > läuft, unter JavaScript mit 8-10 FPS laufen würde. Einfach gerechnet.
> Damit
> > lassen sich viele Anwendungen schlicht nicht realisieren.
>
> Es handelt sich hier aber nicht um C++-Code, sondern um Wasm.
> Du kannst mir auch gerne ausrechnen, dass ein Ferrari x-mal schneller als
> ein Golf ist. Das ist aber trotzdem irrelevant, wenn wir einen R8 fahren.
WASM läuft mindestens so schnell wie ASM.js
also 10-20% langsamer als nativer code.
Wobei calls in Javascript APIs (WebGL ect.) natürlich deutlich langsamer sind als vergleichbare calls in native Schnittstellen.

[RicoBrassers]

Haxx schrieb:
--------------------------------------------------------------------------------
> RicoBrassers schrieb:
> ---------------------------------------------------------------------------
> -----
> > twothe schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > Die Antwort steht im Artikel. Laut Benchmarkgame ist JS unter Node.js
> > mit
> > > allen erdenklichen Optimierungen ca. 6-7 mal langsamer als
> > vergleichbarer
> > > C++ Code. In Zahlen bedeutet das, dass ein Spiel, dass unter C++ mit
> 60
> > FPS
> > > läuft, unter JavaScript mit 8-10 FPS laufen würde. Einfach gerechnet.
> > Damit
> > > lassen sich viele Anwendungen schlicht nicht realisieren.
> >
> > Es handelt sich hier aber nicht um C++-Code, sondern um Wasm.
> > Du kannst mir auch gerne ausrechnen, dass ein Ferrari x-mal schneller
> als
> > ein Golf ist. Das ist aber trotzdem irrelevant, wenn wir einen R8
> fahren.
> WASM läuft mindestens so schnell wie ASM.js
> also 10-20% langsamer als nativer code.
> Wobei calls in Javascript APIs (WebGL ect.) natürlich deutlich langsamer
> sind als vergleichbare calls in native Schnittstellen.

Mag ja durchaus sein, twothe hat aber von C++-Code gesprochen, der vom Browser überhaupt nicht ausgeführt wird, also hier komplett irrelevant ist. Daher meine Aussage.

Dass JavaScript, welches innerhalb einer VM läuft, längsamer ist, als nativer Code, ist mir schon klar. Aber auch Wasm ist kein nativer Code, weshalb man erstmal abwarten muss, wie gut die Performance von Wasm dann letztendlich ist.

Aber auch hier nochmal der Hinweis: Im Browser selbst wird durch Wasm kein C++-Code ausgeführt, weshalb die Performance von C++-Programmen hier in diesem Kontext komplett uninteressant ist. Der C++-Code wird vom Programmierer in Wasm übersetzt, wodurch letztendlich die Performance-Vorteile von C++ erstmal flöten gehen. Die letztendliche Performance von Wasm hängt dann vom (Trans-)Compiler und von der VM ab (und natürlich auch von der Hardware).

Und in der Regel optimieren Transcompiler den Code nicht so gut, wie ein Mensch dies von Hand machen kann, daher wird die bevorzugte (und vermutlich auch performantere) Variante das Schreiben in "nativem" Wasm sein. das Transcompiling soll eben, wie im Artikel beschrieben, dafür sein, dass man bestehenden C++-Code portieren kann, bzw. man eben für alle Anwendungsbereich nur eine Programmiersprache braucht (ähnliches Prinzip wie NodeJS, nur umgekehrt - aus einer "Serverseiten Sprache" wird eine "Clientseitige Sprache" - bezogen auf Webinhalte).