1. Foren
  2. Kommentare
  3. Internet
  4. Alle Kommentare zum Artikel
  5. › ORBX: Videocodecs der Zukunft

Javascripts Geschwindigkeit

Anzeige
  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


  1. Javascripts Geschwindigkeit

    Autor Christo 06.05.13 - 10:38

    Hätte jemand mir noch vor ein paar Jahren erzählt, dass so etwas mit Javascript einmal möglich sein wird, ich glaube ich hätte ihn ausgelacht.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  2. Re: Javascripts Geschwindigkeit

    Autor teenriot 06.05.13 - 10:45

    Beeindruckend stimmt schon.

    Aber ich frag mich trotzdem was das soll.
    Wozu wird bessere Hardware Entwickelt um sie dann zu verschenken indem man Skriptsprachen für Dinge benutzt für die die Sprachen überhaupt nicht ausgelegt sind.

    720pp bei 30 Frames auf dem IPhone...
    Bei 100% Auslastung und drastischem Zerren am Akku sicherlich...

    Es gibt keinen Mehrwert Javascript zu benutzen.
    Es muss eine statisch kompilierte Version von Javascript her.
    Oder am besten Javascript ersetzen, denn die Sprache ist und war nie auf der Höhe der Zeit, allein vom Syntax her.

    Videocodecs in Skriptsprachen zu schreiben ist Ressourcenverschwendung höchsten Grades, geradezu aberwitzig.



    1 mal bearbeitet, zuletzt am 06.05.13 10:46 durch teenriot.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  3. Re: Javascripts Geschwindigkeit

    Autor LH 06.05.13 - 10:45

    Christo schrieb:
    --------------------------------------------------------------------------------
    > Hätte jemand mir noch vor ein paar Jahren erzählt, dass so etwas mit
    > Javascript einmal möglich sein wird, ich glaube ich hätte ihn ausgelacht.

    Naja, am Ende erledigt viel die GPU, da hat JS nicht sooo viel mit zu tun.
    Im Grunde ist JS noch immer relativ langsam, aber man findet halt genug Wege um es herum.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  4. Re: Javascripts Geschwindigkeit

    Autor gorsch 06.05.13 - 12:34

    >Aber ich frag mich trotzdem was das soll.
    >Wozu wird bessere Hardware Entwickelt um sie dann zu verschenken indem man Skriptsprachen für Dinge
    >benutzt für die die Sprachen überhaupt nicht ausgelegt sind.
    Na weil der Kram eben in allen Browsern (mehr oder weniger) zuverlässig vorhanden ist!
    Über C könnte ich mich auch aufregen, trotzdem bleibt es das Fundament, auf dem praktisch all unsere Software aufbaut. C war auch nie darauf "ausgelegt" noch im Jahre 2013 relevant zu sein.
    Javascript wird mehr und mehr zum Backend werden, mit Projekten wie asm.js wird früher oder später endgültig native Performance greifbar.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  5. Re: Javascripts Geschwindigkeit

    Autor Haxx 06.05.13 - 12:48

    AoT code im browser.. really? oO

    Was wir brauchen ist WebCL
    http://www.khronos.org/webcl/

    Benutzer wird von Ihnen ignoriert. Anzeigen

  6. Re: Javascripts Geschwindigkeit

    Autor teenriot 06.05.13 - 13:00

    Die dynamischen Eigenschaften von Javascript machen es langsam im Vergleich zu Kompilaten. Aber diese Dynamik braucht man überhaupt nicht für Codec-Geschichten.
    Warum also das ganze in Javascript? Wo ist da der Mehrwert? Nur weil es geht?

    Ich denke mal Javascript ist aufgrund der Dynamik auch unsicher wenn's um kommerzielle Software geht.
    Außerdem darf Javascript nicht einfach im Klartext lesbar sein wenn es wirklich klassische Anwendungsentwicklung ersetzen soll.
    Dann ist da noch das Problem das es keinen echten Standard gibt, bzw sich niemand dran hält, was dann auch das debuggen und testen stark verkompliziert.

    All das könnte man lösen wenn Javascript kompiliert werden könnten. Es muss ja kein nativ laufzeitfähiger Code rauskommen. Virtuelle Machine würde genügen.



    1 mal bearbeitet, zuletzt am 06.05.13 13:01 durch teenriot.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  7. Re: Javascripts Geschwindigkeit

    Autor Christo 06.05.13 - 13:27

    teenriot schrieb:
    --------------------------------------------------------------------------------
    > Die dynamischen Eigenschaften von Javascript machen es langsam im Vergleich
    > zu Kompilaten. Aber diese Dynamik braucht man überhaupt nicht für
    > Codec-Geschichten.
    > Warum also das ganze in Javascript? Wo ist da der Mehrwert? Nur weil es
    > geht?

    Nein, weil es überall geht!


    > Ich denke mal Javascript ist aufgrund der Dynamik auch unsicher wenn's um
    > kommerzielle Software geht.
    > Außerdem darf Javascript nicht einfach im Klartext lesbar sein wenn es
    > wirklich klassische Anwendungsentwicklung ersetzen soll.

    Dafür gibt es spezielle "Verschlüsselungssoftware", die es in eine nicht leicht lesbaren Form bringen. Diese machen dann auch ein paar Optimierungen.
    Und Java & C# kann man auch leicht dekompilieren, die Sicherheit trügt dort.

    > Dann ist da noch das Problem das es keinen echten Standard gibt, bzw sich
    > niemand dran hält, was dann auch das debuggen und testen stark
    > verkompliziert.

    Schonmal was von Ecmascript gehört?
    Es ist nicht Javascript das von Browser zu Browser unterschiedlich ist, sondern das DOM.

    > All das könnte man lösen wenn Javascript kompiliert werden könnten. Es muss
    > ja kein nativ laufzeitfähiger Code rauskommen. Virtuelle Machine würde
    > genügen.

    Der einzige Vorteil von Bitecode (ala Java & .Net) ist, dass er kleiner ist.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  8. Re: Javascripts Geschwindigkeit

    Autor teenriot 06.05.13 - 13:41

    Christo schrieb:
    --------------------------------------------------------------------------------
    > teenriot schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Die dynamischen Eigenschaften von Javascript machen es langsam im
    > Vergleich
    > > zu Kompilaten. Aber diese Dynamik braucht man überhaupt nicht für
    > > Codec-Geschichten.
    > > Warum also das ganze in Javascript? Wo ist da der Mehrwert? Nur weil es
    > > geht?
    >
    > Nein, weil es überall geht!

    Das hängt aber nicht an der Dynamik.
    Mit einer Virtuelle Maschine kann man genauso ein und denselben Code auch überall laufen lassen

    > > Ich denke mal Javascript ist aufgrund der Dynamik auch unsicher wenn's
    > um
    > > kommerzielle Software geht.
    > > Außerdem darf Javascript nicht einfach im Klartext lesbar sein wenn es
    > > wirklich klassische Anwendungsentwicklung ersetzen soll.
    >
    > Dafür gibt es spezielle "Verschlüsselungssoftware", die es in eine nicht
    > leicht lesbaren Form bringen. Diese machen dann auch ein paar
    > Optimierungen.
    > Und Java & C# kann man auch leicht dekompilieren, die Sicherheit trügt
    > dort.

    Nur weil jedes Schloss knackbar ist sollte man trotzdem eins haben.
    Verschlüsselungssoftware schützt einen nicht davor das jemand Software spielend leicht manipulieren kann indem er die Dynamik ausnutzt.

    >
    > > Dann ist da noch das Problem das es keinen echten Standard gibt, bzw
    > sich
    > > niemand dran hält, was dann auch das debuggen und testen stark
    > > verkompliziert.
    >
    > Schonmal was von Ecmascript gehört?
    > Es ist nicht Javascript das von Browser zu Browser unterschiedlich ist,
    > sondern das DOM.

    Wenn man Javascript voll für die anwendungsentwicklung einsetzen will muss man zwangsläufig auch auf das DOM zurückgreifen.

    >
    > > All das könnte man lösen wenn Javascript kompiliert werden könnten. Es
    > muss
    > > ja kein nativ laufzeitfähiger Code rauskommen. Virtuelle Machine würde
    > > genügen.
    >
    > Der einzige Vorteil von Bitecode (ala Java & .Net) ist, dass er kleiner
    > ist.

    Wo bleibt das Interpretieren und Jit-Kompilieren?

    Benutzer wird von Ihnen ignoriert. Anzeigen

  9. Re: Javascripts Geschwindigkeit

    Autor Haxx 06.05.13 - 14:31

    Javascript ist langsam weil:
    - es kennt integer
    - es hat keine (sicheren arrays) mit fester länge.
    - Objekte haben keine feste Form
    - prototyp-klassen sind sehr teuer im Aufruf von dessen funktionen.


    Hätten wir eine bytecode vm müsste man statt javascript den bytecode standartisieren, das problem würde sich damit nicht ändern das jeder Browserhersteller seine eigene Implementierung hat.

    Auch javascript-sourcode kann man reduzieren bsw.
    - Gzip komprimierung (was ziemlich gut bei text ist)
    - Minify
    - Treeshaking (geht bei javascript nicht aber bsw. bei dart & dart2js)

    Obfuscation schützt dich zudem genauso (gut?) vor sourcode diebstahl wie kompilierung zu javaVM bytecode

    Benutzer wird von Ihnen ignoriert. Anzeigen

  10. Re: Javascripts Geschwindigkeit

    Autor ichbinsmalwieder 06.05.13 - 14:36

    teenriot schrieb:
    --------------------------------------------------------------------------------

    > 720pp bei 30 Frames auf dem IPhone...
    > Bei 100% Auslastung und drastischem Zerren am Akku sicherlich...
    >
    > Es gibt keinen Mehrwert Javascript zu benutzen.
    > Es muss eine statisch kompilierte Version von Javascript her.
    > Oder am besten Javascript ersetzen, denn die Sprache ist und war nie auf
    > der Höhe der Zeit, allein vom Syntax her.
    >
    > Videocodecs in Skriptsprachen zu schreiben ist Ressourcenverschwendung
    > höchsten Grades, geradezu aberwitzig.

    Deswegen wird doch WebGL und damit die Hardwarebeschleunigung benutzt.
    Dass das auf dem iPhone offenbar nicht funktioniert, musst du Apple ankreiden...

    Benutzer wird von Ihnen ignoriert. Anzeigen

  11. Re: Javascripts Geschwindigkeit

    Autor teenriot 06.05.13 - 14:43

    Haxx schrieb:
    --------------------------------------------------------------------------------

    > Hätten wir eine bytecode vm müsste man statt javascript den bytecode
    > standartisieren, das problem würde sich damit nicht ändern das jeder
    > Browserhersteller seine eigene Implementierung hat.

    Das ist grundsätzlich auch kein Problem wenn es einen Standard gibt an den sich gehalten wird. Bytecode hat einen kleinen Befehlssatz, was die Sache natürlich trotzdem nicht trivial macht in der Implementierung, aber beim Standardisieren.

    Es geht mir einfach darum das man nicht softwaremäßig 1,5 Schritte zurückgeht weil es die Hardware zulässt nachdem diese 2 Schritte nach vorne gegangen ist.
    Warum man muss für eine gute Eigenschaft eine andere weichen, wenn's doch auch anders geht? Ich mag keine Kompromisse nur der Einfachheit wegen.

    Früher wurde um Performance gekämpft. Ich sehe nicht ein warum darauf heute verzichtet werden soll bei grundlegenden Sachen wie einem Video-codec.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  12. Re: Javascripts Geschwindigkeit

    Autor teenriot 06.05.13 - 14:46

    ichbinsmalwieder schrieb:
    --------------------------------------------------------------------------------
    > teenriot schrieb:
    > ---------------------------------------------------------------------------
    > -----
    >
    > > 720pp bei 30 Frames auf dem IPhone...
    > > Bei 100% Auslastung und drastischem Zerren am Akku sicherlich...
    > >
    > > Es gibt keinen Mehrwert Javascript zu benutzen.
    > > Es muss eine statisch kompilierte Version von Javascript her.
    > > Oder am besten Javascript ersetzen, denn die Sprache ist und war nie auf
    > > der Höhe der Zeit, allein vom Syntax her.
    > >
    > > Videocodecs in Skriptsprachen zu schreiben ist Ressourcenverschwendung
    > > höchsten Grades, geradezu aberwitzig.
    >
    > Deswegen wird doch WebGL und damit die Hardwarebeschleunigung benutzt.
    > Dass das auf dem iPhone offenbar nicht funktioniert, musst du Apple
    > ankreiden...

    Warum soll man es Apple ankreiden das sie nicht (vorsorglich!) Hardware verbauen die nur nötig wird, weil man meint sich den Luxus einer Skriptsprache gönnen zu müssen, die die vorhandene Hardwareunterstützung nicht nutzen kann?

    Benutzer wird von Ihnen ignoriert. Anzeigen

  13. Re: Javascripts Geschwindigkeit

    Autor Blair 06.05.13 - 15:27

    teenriot schrieb:
    --------------------------------------------------------------------------------
    > Es muss eine statisch kompilierte Version von Javascript her.

    Das ist doch das was das im Artikel erwähnte asm.js macht.

    > Oder am besten Javascript ersetzen, denn die Sprache ist und war nie auf
    > der Höhe der Zeit, allein vom Syntax her.

    Bei Chrome gibts so etwas (NoCl), ist aber wohl noch nicht so weit.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  14. Re: Javascripts Geschwindigkeit

    Autor droptable 06.05.13 - 15:32

    teenriot schrieb:
    --------------------------------------------------------------------------------
    > All das könnte man lösen wenn Javascript kompiliert werden könnten. Es muss
    > ja kein nativ laufzeitfähiger Code rauskommen. Virtuelle Machine würde
    > genügen.

    asm.js kompatibler Code wird AOT übersetzt (zum Großteil in nativen Code).
    Zudem läuft "normaler" JavaScript Code bereits in einer VM und zum Teil (JIT oder AOT) sogar als nativer Code.

    Im übrigen ist JavaScript wohl die »schnellste« dynamisch typisierte Scriptsprache die derzeit existiert. Via asm.js nur doppelt so langsam als C, was immer noch 200% schneller ist (fiktiver Wert, keine Lust gerade zu rechnen) als alles andere in dem Bereich.

    JavaScript Bytecode wurde bereits des öfteren thematisiert und Brendan Eich (der Vater von JavaScript) hat sich explizit dagegen ausgesprochen.

    Ein Zitat von Douglas Crockford (Schöpfer des JSON Formats):
    »JavaScript's parser does a more efficient job of providing code security than the JVM's bytecode verifier.«

    Weitere Auszüge:
    http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageForTheWebPart2MadnessOrJustInsanity.aspx

    Benutzer wird von Ihnen ignoriert. Anzeigen

  15. Re: Javascripts Geschwindigkeit

    Autor Haxx 06.05.13 - 15:32

    > Warum soll man es Apple ankreiden das sie nicht (vorsorglich!) Hardware
    > verbauen die nur nötig wird, weil man meint sich den Luxus einer
    > Skriptsprache gönnen zu müssen, die die vorhandene Hardwareunterstützung
    > nicht nutzen kann?
    Jemand der webgl nutzt würde doch nah auf der Hardware arbeiten.
    Zudem läuft WebGL bereits auf dem Iphone, sogar ziemlich gut! Es wurde nur noch nicht aktiviert

    Benutzer wird von Ihnen ignoriert. Anzeigen

  16. Re: Javascripts Geschwindigkeit

    Autor teenriot 06.05.13 - 15:36

    asm.js - Schön und gut.

    Aber der Sourcecode wird so sehr verschandelt das ich mich damit nicht anfreunden würde wenn es Alternativen gäbe.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  17. Re: Javascripts Geschwindigkeit

    Autor Haxx 06.05.13 - 15:58

    teenriot schrieb:
    --------------------------------------------------------------------------------
    > asm.js - Schön und gut.
    >
    > Aber der Sourcecode wird so sehr verschandelt das ich mich damit nicht
    > anfreunden würde wenn es Alternativen gäbe.
    webCL/SIMD/Dart wäre eine alternative

    Benutzer wird von Ihnen ignoriert. Anzeigen

  18. Re: Javascripts Geschwindigkeit

    Autor Thaodan 06.05.13 - 16:03

    Auch wenn das OT ist: die Leute die C entwickelt hatten, haben/hatten eine ganz andere Mentalität. Zu mal die auch nicht in den 70ern stehen geblieben sind.

    Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
    -- Georg Schramm

    Benutzer wird von Ihnen ignoriert. Anzeigen

  19. Re: Javascripts Geschwindigkeit

    Autor Paykz0r 06.05.13 - 16:25

    teenriot schrieb:
    --------------------------------------------------------------------------------
    > Beeindruckend stimmt schon.
    >
    > Aber ich frag mich trotzdem was das soll.
    > Wozu wird bessere Hardware Entwickelt um sie dann zu verschenken indem man
    > Skriptsprachen für Dinge benutzt für die die Sprachen überhaupt nicht
    > ausgelegt sind.
    >
    > 720pp bei 30 Frames auf dem IPhone...
    > Bei 100% Auslastung und drastischem Zerren am Akku sicherlich...
    >
    > Es gibt keinen Mehrwert Javascript zu benutzen.
    > Es muss eine statisch kompilierte Version von Javascript her.
    > Oder am besten Javascript ersetzen, denn die Sprache ist und war nie auf
    > der Höhe der Zeit, allein vom Syntax her.
    >
    > Videocodecs in Skriptsprachen zu schreiben ist Ressourcenverschwendung
    > höchsten Grades, geradezu aberwitzig.

    soviel wird da nicht verschenkt wenn man webGL hat.
    das muss man immer alle sim verhältnis sehen.
    der codec schaufelt die daten in die gpu,
    die bearbeitet die asynch. und gibt das aus.

    das schaufeln der daten läuft also nebenher und ist vergleichweise zu vernachlässigen.
    und damit baut man sogar druck auf das alle mal webGL unterstützen.

    auf iOS gibt es da immer noch nix.
    Nur Android hat webGL via firefox mobile,
    den auch nicht gerade jeder nutzt.

    das kann sich ruig mal ändern

    Benutzer wird von Ihnen ignoriert. Anzeigen

  20. Re: Javascripts Geschwindigkeit

    Autor teenriot 06.05.13 - 16:28

    Ja aber Fakt ist doch das dieser Codec auf dem IPhone mehr CPU (Akku) braucht als die bisherigen hardwareunterstützten.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


Entschuldigung, nur registrierte Benutzer dürfen in diesem Forum schreiben. Klicken Sie hier um sich einzuloggen


Anzeige

Haben wir etwas übersehen?

E-Mail an news@golem.de


DDR-Hackerfilm Zwei schräge Vögel: Mit Erotik und Kybernetik ins perfekte Chaos
DDR-Hackerfilm Zwei schräge Vögel
Mit Erotik und Kybernetik ins perfekte Chaos
  1. Zoobotics Vier- und sechsbeinige Pappkameraden
  2. Miraisens Virtuelle Objekte werden ertastbar
  3. Autodesk Pteromys konstruiert Papiergleiter am Computer

Rezension What If: Ein Highlight der Nerdkultur vom XKCD-Autor
Rezension What If
Ein Highlight der Nerdkultur vom XKCD-Autor
  1. Transistoren Rechnen nach dem Schmetterlingsflügel-Prinzip
  2. MIT-Algorithmus Wie rotiert Schrott in Schwerelosigkeit?
  3. Neues Verfahren Yale-Forscher formt Smartphone-Hüllen aus metallischem Glas

IMHO: Microsoft kauft sich einen Markt mit Klötzchen
IMHO
Microsoft kauft sich einen Markt mit Klötzchen
  1. Minecraft Microsoft kauft Mojang
  2. Minecraft Microsoft will offenbar Mojang kaufen
  3. Minecraft New-Gen-Klötzchenwelt mit 1080p und 60 fps

  1. Spiele-API: DirectX-11 wird parallel zu DirectX-12 weiterentwickelt
    Spiele-API
    DirectX-11 wird parallel zu DirectX-12 weiterentwickelt

    Nicht nur ein neues DirectX-12 mit weniger CPU-Overhead, sondern auch ein DirectX 11.3 wird es geben - Microsoft hat die Weiterentwicklung der Schnittstelle US-Medien bestätigt. Ob für beide neue Versionen auch neue Hardware nötig ist, steht aber noch nicht fest.

  2. Streaming-Box: Netflix noch im Herbst für Amazons Fire TV
    Streaming-Box
    Netflix noch im Herbst für Amazons Fire TV

    Bisher ist Netflix für die deutsche Version des Fire TV nicht verfügbar. Das bleibt offenbar auch zum Verkaufsstart am 25. September 2014 so, Amazon will die App aber kurz darauf nachliefern. Das geht aus Fotos der Verpackung des Geräts hervor.

  3. Schnell, aber ungenau: Roboter springt im Explosionsschritt
    Schnell, aber ungenau
    Roboter springt im Explosionsschritt

    US-Forscher haben einen Roboter vorgestellt, der durch Gasexplosionen in seinem Fuß angetrieben wird. Er landet zwar nicht sehr zielgenau, aber seine Sprünge sind beeindruckend.


  1. 14:11

  2. 13:09

  3. 18:22

  4. 16:41

  5. 16:31

  6. 16:13

  7. 15:09

  8. 15:03