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

  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.

  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.

  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.

  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/

  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.

  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.

  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?

  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

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

  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.

  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?

  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.

  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

  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

  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.

  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

  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

  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

  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.

  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Anzeige
Stellenmarkt
  1. Home Shopping Europe GmbH, Ismaning Raum München
  2. operational services GmbH & Co. KG, Frankfurt, Berlin
  3. MEIERHOFER AG, München, St. Valentin (Österreich)
  4. Technische Informationsbibliothek (TIB), Hannover

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Interstellar, Mad Max, Codename UNCLE, American Sniper, San Andreas)
  2. (u. a. Fallout 4 USK 18 für 19,99€ inkl. Versand, The Expendables Trilogy Limited Collector's...


Haben wir etwas übersehen?

E-Mail an news@golem.de


MacOS 10.12 im Test: Sierra - Schreck mit System
MacOS 10.12 im Test
Sierra - Schreck mit System
  1. MacOS 10.12 Fujitsu warnt vor der Nutzung von Scansnap unter Sierra
  2. MacOS 10.12 Sierra fungiert als alleiniges Sicherheitsupdate für OS X
  3. MacOS Sierra und iOS 10 Apple schmeißt unsichere Krypto raus

Rocketlab: Neuseeland genehmigt Start für erste elektrische Rakete
Rocketlab
Neuseeland genehmigt Start für erste elektrische Rakete
  1. Osiris Rex Asteroid Bennu, wir kommen!
  2. Raumfahrt Erster Apollo-Bordcomputer aus dem Schrott gerettet
  3. Startups Wie Billig-Raketen die Raumfahrt revolutionieren

Osmo Mobile im Test: Hollywood fürs Smartphone
Osmo Mobile im Test
Hollywood fürs Smartphone
  1. Osmo Mobile DJI präsentiert Gimbal fürs Smartphone
  2. Hasselblad DJI hebt mit 50-Megapixel-Luftbildkamera ab
  3. DJI Flugverbotszonen in Drohnensoftware lassen sich ausschalten

  1. Postauto: Autonomer Bus baut in der Schweiz einen Unfall
    Postauto
    Autonomer Bus baut in der Schweiz einen Unfall

    Einer der beiden Kleinbusse, die autonom durch das schweizerische Sitten fahren, hat einen Unfall verursacht. Verletzt wurde niemand. Der Testbetrieb wurde vorerst eingestellt.

  2. Neues iPhone: US-Late-Night-Komiker witzeln über Apple
    Neues iPhone
    US-Late-Night-Komiker witzeln über Apple

    US-Komiker nehmen in ihren Talkshows seit der Vorstellung des iPhone 7 verstärkt Apple aufs Korn. Seien es die drahtlose Apple-Tasche, herumfliegende Airpods oder allgemeine Konsumkritik an dem Zwang, sich jedes Jahr etwas Neues zu kaufen.

  3. Festnetz: Weiterhin kein Internet ohne Telefonie bei der Telekom
    Festnetz
    Weiterhin kein Internet ohne Telefonie bei der Telekom

    Trotz Rückgang bei der Sprachtelefonie bietet die Deutsche Telekom keine reinen Internetzugänge an. Bündelangebote im Festnetz sind für den Netzbetreiber lukrativ.


  1. 07:17

  2. 19:12

  3. 18:52

  4. 18:34

  5. 18:17

  6. 17:51

  7. 17:25

  8. 16:25