1. Foren
  2. Kommentare
  3. Internet
  4. Alle Kommentare zum Artikel
  5. › Webassembly: Bytecode fürs Web ist…

Wieso?

  1. Thema

Neues Thema Ansicht wechseln


  1. Wieso?

    Autor: Hypfer 01.11.16 - 11:51

    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.

  2. Re: Wieso?

    Autor: andi_lala 01.11.16 - 11:53

    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.

  3. Re: Wieso?

    Autor: Hypfer 01.11.16 - 11:53

    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

  4. Re: Wieso?

    Autor: Xiut 01.11.16 - 11:55

    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.

  5. Re: Wieso?

    Autor: Xiut 01.11.16 - 11:59

    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.

  6. Re: Wieso?

    Autor: laserbeamer 01.11.16 - 12:09

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

  7. Re: Wieso?

    Autor: andi_lala 01.11.16 - 12:11

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

  8. Re: Wieso?

    Autor: andi_lala 01.11.16 - 12:12

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

  9. Re: Wieso?

    Autor: twothe 01.11.16 - 12:26

    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.

  10. Re: Wieso?

    Autor: rw 01.11.16 - 12:28

    Vielleicht weil man nicht mehr auf JavaScript angewiesen ist?

  11. Re: Wieso?

    Autor: RicoBrassers 01.11.16 - 12:41

    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.

  12. Re: Wieso?

    Autor: Haxx 01.11.16 - 16:33

    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.

  13. Re: Wieso?

    Autor: RicoBrassers 02.11.16 - 09:11

    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).

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Leibniz-Institut für Alternsforschung - Fritz-Lipmann-Institut e.V. (FLI), Jena
  2. Bau- und Liegenschaftsbetrieb NRW, Düsseldorf
  3. noris network AG, München, Aschheim (bei München), Nürnberg, Berlin (Remote-Office möglich)
  4. WITRON Gruppe, Parkstein (Raum Weiden / Oberpfalz)

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 31,99€
  2. 4,63€
  3. (-15%) 25,49€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programmiersprache Go: Schlanke Syntax, schneller Compiler
Programmiersprache Go
Schlanke Syntax, schneller Compiler

Die objektorientierte Programmiersprache Go eignet sich vor allem zum Schreiben von Netzwerk- und Cloud-Diensten.
Von Tim Schürmann


    Golem on Edge: Wo Nachbarn alles teilen - auch das Internet
    Golem on Edge
    Wo Nachbarn alles teilen - auch das Internet

    Mehr schlecht als recht arbeiten zu können und auch nur dann, wenn die Nachbarn nicht telefonieren - das war keine Dauerlösung. Wie ich endlich Internet in meine Datsche bekommen habe.
    Eine Kolumne von Sebastian Grüner

    1. Keine Glasfaser, keine IT-Kompetenz Schulen bemühen sich vergeblich um Geld aus dem Digitalpakt
    2. Kultusministerien Schulen rufen kaum Geld aus Digitalpakt ab
    3. Change-Management Wie man Mitarbeiter mitnimmt

    8Sense im Test: Vibration am Kragen gegen Schmerzen im Rücken
    8Sense im Test
    Vibration am Kragen gegen Schmerzen im Rücken

    Das Startup 8Sense will mit einem Ansteckclip einer Bürokrankheit entgegenwirken: Rückenschmerzen. Das funktioniert - aber nicht immer.
    Ein Test von Oliver Nickel

    1. Rufus Cuff Handgelenk-Smartphone soll doch noch erscheinen
    2. Fitnesstracker im Test Aldi sportlich abgeschlagen hinter Honor und Mi Band 4