Announcement

Collapse
No announcement yet.

SIMD JavaScript Support Added To Firefox, Under Review For Chrome

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Luke_Wolf View Post
    Higher complexity games that need this kind of performance, emulators, and media processing should not be written in javascript. At most you can argue that the game scripts can be written in javascript but even then there's better options. It's the wrong tool for the job. Typescript and friends improve the situation but even then you're still in a horrible situation.

    Javascript is fine for simple games and things that aren't all that complex, animations, UI stuff, things like that. That said I really don't want to imagine the eye-burning horror that an emulator or encoder written in JS will look like in terms of the codebase.
    Except the other options defeat the purpose of using JavaScript... so they're portable.

    Comment


    • #12
      Originally posted by brad0 View Post
      Except the other options defeat the purpose of using JavaScript... so they're portable.
      "So they're portable"?... Are you daft?

      Most languages are portable (however libraries you use may not be, but that's on you to choose platform independent libraries and frameworks such as Qt), the only advantage that javascript provides due to a freak of nature is that it's the only language native to web browsers (native in the sense it doesn't need a plugin), and if you really want to go with the browser I can use Flash, Java, Silverlight, or NaCl, however if I'm not so insane that I desire such a thing I can write an application targeting the JVM or Mono, or any of the widely ported scripting languages and run applications natively on the device outside of a browser , even making use of the internet as opposed to the web, or I can even use C++ and Qt to write once and compile independent binaries for all of the architectures or if I decide to use LLVM I can even make a JITed version.

      Simply put, Portability is not and never was a reason to use Javascript.

      the "reason" to use javascript is because it's a language that lets you do quick and dirty things easily for situations (particularly UI) where the best engineering in the world doesn't really matter. For anything else you want at a bare minimum a strict and statically typed language, and I would say preferably one that is explicitly typed, and on top of that JS has a lot of weird stuff going on.
      Last edited by Luke_Wolf; 31 March 2014, 12:22 AM.

      Comment


      • #13
        Originally posted by johnmccutchan View Post
        This work is a direct port of SIMD types I did for Dart in 2013. Exact same types and operations. If you're interested in seeing what the API looks like, I maintain the ECMAScript proposal as a polyfill library. If you want to experience the full speed of these types today, you can use Dart (the SIMD types are fully accelerated on SSE and NEON in the Dart VM).

        More information:

        Talk I gave last year
        Programming guide

        John McCutchan
        This is definitely interesting and thanks for the great work! Is there an email list or similar, where I should post for more discussion?

        I was wondering why you didn't include any float64 SIMD types. I have been meaning to port some scientific computing code to Javascript that would greatly benefit from float64 SIMD types. After all, SSE and AVX both include float64 SIMD instructions and ARMv8 includes SIMD float64 as well. For architectures that lack float64 SIMD instructions (such as ARMv7 NEON) you could probably just compile to sequence of scalar instructions anyway so that shouldn't be an issue?

        Comment


        • #14
          Originally posted by Luke_Wolf View Post
          "So they're portable"?... Are you daft?

          Most languages are portable (however libraries you use may not be, but that's on you to choose platform independent libraries and frameworks such as Qt), the only advantage that javascript provides due to a freak of nature is that it's the only language native to web browsers (native in the sense it doesn't need a plugin), and if you really want to go with the browser I can use Flash, Java, Silverlight, or NaCl, however if I'm not so insane that I desire such a thing I can write an application targeting the JVM or Mono, or any of the widely ported scripting languages and run applications natively on the device outside of a browser , even making use of the internet as opposed to the web, or I can even use C++ and Qt to write once and compile independent binaries for all of the architectures or if I decide to use LLVM I can even make a JITed version.

          Simply put, Portability is not and never was a reason to use Javascript.

          the "reason" to use javascript is because it's a language that lets you do quick and dirty things easily for situations (particularly UI) where the best engineering in the world doesn't really matter. For anything else you want at a bare minimum a strict and statically typed language, and I would say preferably one that is explicitly typed, and on top of that JS has a lot of weird stuff going on.
          You have a different definition of portable than the people writing these apps. Portable meaning NOT building binaries for a shit load of different OS's, platforms and architectures having to maintain them too. Freak of nature? JavaScript was designed at Netscape for web browsers for client side apps. LOL you're asking if I am daft and then mention Flash, Java, and especially Silverlight and NaCl. What a laugh.

          Comment


          • #15
            Originally posted by Luke_Wolf View Post
            "So they're portable"?... Are you daft?

            Most languages are portable (however libraries you use may not be, but that's on you to choose platform independent libraries and frameworks such as Qt), the only advantage that javascript provides due to a freak of nature is that it's the only language native to web browsers (native in the sense it doesn't need a plugin), and if you really want to go with the browser I can use Flash, Java, Silverlight, or NaCl, however if I'm not so insane that I desire such a thing I can write an application targeting the JVM or Mono, or any of the widely ported scripting languages and run applications natively on the device outside of a browser , even making use of the internet as opposed to the web, or I can even use C++ and Qt to write once and compile independent binaries for all of the architectures or if I decide to use LLVM I can even make a JITed version.

            Simply put, Portability is not and never was a reason to use Javascript.

            the "reason" to use javascript is because it's a language that lets you do quick and dirty things easily for situations (particularly UI) where the best engineering in the world doesn't really matter. For anything else you want at a bare minimum a strict and statically typed language, and I would say preferably one that is explicitly typed, and on top of that JS has a lot of weird stuff going on.
            And even then the portability of Javascript is flawed because not all implementations of Javascript are necessarily compatible with each other, an easy example is the sheer number of websites that are broken if you try to use a webkit based browser that's not chrome, such as rekonq to access the web, also I've had a number of websites which only work in firefox such as textnow.com where the login button does absolutely nothing under other browsers (I haven't checked if they've fixed that yet or not).

            also... stupid 5 minute edit time limit ...

            Comment


            • #16
              Originally posted by brad0 View Post
              You have a different definition of portable than the people writing these apps. Portable meaning NOT building binaries for a shit load of different OS's, platforms and architectures having to maintain them too. Freak of nature? JavaScript was designed at Netscape for web browsers for client side apps. LOL you're asking if I am daft and then mention Flash, Java, and especially Silverlight and NaCl. What a laugh.
              If I don't want to build a bunch of binaries for different OSes then I can use Mono, Java, or any of the various scripting languages exactly as I mentioned, I can also create JITed binaries using LLVM as mentioned. In fact I stated exactly as such

              if I'm not so insane that I desire such a thing I can write an application targeting the JVM or Mono, or any of the widely ported scripting languages and run applications natively on the device outside of a browser , even making use of the internet as opposed to the web, or I can even use C++ and Qt to write once and compile independent binaries for all of the architectures or if I decide to use LLVM I can even make a JITed version.
              But then maybe you just have horrible reading comprehension, or further don't understand that targeting the web browser != portable, beyond it'll work in most web browsers... hopefully.

              And Yes Javascript was "designed" for that in the same way that HTML was "designed" for displaying information over the web, and they both came out utterly horribly, in large part due to a certain w3c's obsession with not throwing errors and thus enforcing a loose standard, as opposed to everything being strictly validated, although the defacto design nature of the standard didn't help either. (Read up on the history of the <image> tag if you want a perfect example of how defacto their design process was, in spite of discussion of far superior solutions)
              Last edited by Luke_Wolf; 31 March 2014, 01:36 AM.

              Comment


              • #17
                Originally posted by Luke_Wolf View Post
                Higher complexity games that need this kind of performance, emulators, and media processing should not be written in javascript. At most you can argue that the game scripts can be written in javascript but even then there's better options. It's the wrong tool for the job. Typescript and friends improve the situation but even then you're still in a horrible situation.

                Javascript is fine for simple games and things that aren't all that complex, animations, UI stuff, things like that. That said I really don't want to imagine the eye-burning horror that an emulator or encoder written in JS will look like in terms of the codebase.
                Not sure if you're trolling or just stupid. Can't you see we're actively trying to improve JS to support all the possible use cases. In the future, ALL software will be written in JavaScript. 1) JS is dynamic, it's a huge plus 1b) no need to install binaries 1c) basically using JS is a zero effort because it works out of the box 2) it's user friendly 3) easy to use 4) thanks to good compiler optimizations it will be soon "faster than native" 5) it's a great portable, human readable intermediate format (see emscripten et al) 6) good company support 7) good standards support 8) it's fast interpreted language so no slow startup cost like with JVM and Java 9) JS is the new cool kid on the block, Java and native are not.

                Many companies are replacing legacy apps with JS. Soon JS will run emulators for Flash, Java, Silverlight. A single runtime to rule them all.

                Comment


                • #18
                  Originally posted by Luke_Wolf View Post
                  If I don't want to build a bunch of binaries for different OSes then I can use Mono, Java, or any of the various scripting languages exactly as I mentioned, I can also create JITed binaries using LLVM as mentioned. In fact I stated exactly as such
                  Well, do that then and maybe it will take off the same way as javascript based web apps have. Until then the rest of us can enjoy writing and using faster javascript. Seriously, what's your problem?

                  Originally posted by Luke_Wolf View Post
                  But then maybe you just have horrible reading comprehension, or further don't understand that targeting the web browser != portable, beyond it'll work in most web browsers... hopefully.

                  And Yes Javascript was "designed" for that in the same way that HTML was "designed" for displaying information over the web, and they both came out utterly horribly, in large part due to a certain w3c's obsession with not throwing errors and thus enforcing a loose standard, as opposed to everything being strictly validated, although the defacto design nature of the standard didn't help either. (Read up on the history of the <image> tag if you want a perfect example of how defacto their design process was, in spite of discussion of far superior solutions)
                  They saw the problem and tried to enforce a strict standard with XHTML, in which parsing would be aborted on errors. And the tag is called <img> btw.

                  Comment


                  • #19
                    Originally posted by brad0 View Post
                    Portable meaning NOT building binaries for a shit load of different OS's, platforms and architectures having to maintain them too.
                    Yes it does.
                    And please enlighten us on how it is different to test a software on a Windows & OSX vm, instead of testing a web app on ie6, 7, 8, 9, 10, 11, firefox 23 -> 29, chrome, safari, etc...

                    And seriously, with good continuous integration you don't even NEED do to the testing yourself, it is all done automagically (provided that you are serious and do write some tests).

                    Comment


                    • #20
                      Originally posted by caligula View Post
                      Not sure if you're trolling or just stupid. Can't you see we're actively trying to improve JS to support all the possible use cases. In the future, ALL software will be written in JavaScript.
                      Are you.... really that stupid? seriously?

                      let's break this down by the numbers:
                      Originally posted by caligula View Post
                      1) JS is dynamic, it's a huge plus
                      Pure Dynamic Types are evil. Period. Why?

                      (if you don't see what's wrong with this picture... I don't want to maintain your codebase)
                      oh sure it may be "easier" for simple problems but have fun debugging. Also how's your tooling? oh wait you don't have any because you can't, that requires strong static typing to work properly.


                      Originally posted by caligula View Post
                      1b) no need to install binaries
                      Oh yes because web browsers aren't binaries, clearly... Obviously I don't need anything at all to run the javascript. Nope.

                      Fact: It's an interepreted language and as a result you need a binary, the interpreter, and JS needs it just as much as any other interpreted language so you get no points.

                      Originally posted by caligula View Post
                      1c) basically using JS is a zero effort because it works out of the box
                      Works out of the box.... no... you still need a web browser or something else to interpret the JS code for you, just like anything else. Furthermore on almost every linux system BASH works "out of the box", but does that mean that I should be writing everything in BASH? Hell no.

                      Furthermore just what systems are there that I should care about that somehow manage to run a web browser binary in order to be able to run JS but that can't run a program that was written in any common language (C, C++, Python, etc..)?

                      Originally posted by caligula View Post
                      2) it's user friendly
                      No, no it really isn't. It's stupid-lazy friendly in that it's not particularly strict, it's loosely and dynamically typed, has significant amounts of brain damage (== vs ===) and in general it has the w3c's idiotic attitudes.

                      A user friendly language is toolable, a user friendly language tells you what you're doing wrong and what to change to fix things instead of trying to do weird shit behind your back, a user friendly language works with you to help you write better code. a user friendly language JS is not.

                      Originally posted by caligula View Post
                      3) easy to use
                      Only in the sense that you can do simple dirty stuff with it easily. If you go beyond that scope you're not going to be having a fun time at all.

                      Originally posted by caligula View Post
                      4) thanks to good compiler optimizations it will be soon "faster than native"
                      You know the .NET and JVM Managed Language guys claimed the same thing... guess what hasn't happened? Because here's the problem, as people find new and better ways to to make compilers optimize code the ideas get shared around and everyone implements them. Now the .NET and JVM guys could actually have an argument here because of a trick called Profile Guided Optimizations which they could continuously do, as long as the bytecode is cached.

                      Originally posted by caligula View Post
                      5) it's a great portable, human readable intermediate format (see emscripten et al)
                      Well JSON is nice yes, however it's YAML with brackets... JS itself though.. yuck

                      Originally posted by caligula View Post
                      6) good company support
                      You get 1 point here

                      Originally posted by caligula View Post
                      7) good standards support
                      And here you lose the point, because it's got such great standards support that half the internet is broken when using webkit proper with Rekonq and other browsers, and even in mainstream browsers there is significant breakage across various webpages usually exclusively favouring either Chrome or Firefox, textnow as an example only works with firefox.

                      Originally posted by caligula View Post
                      8) it's fast interpreted language so no slow startup cost like with JVM and Java
                      you mean like every other significant interpreted language out there?

                      Originally posted by caligula View Post
                      9) JS is the new cool kid on the block, Java and native are not.
                      Actually it's neither new or the cool kid on the block. It's such the cool kid on the block that most of the major browser developers are trying to replace it entirely or create a variant of it fixing design flaws inherent in Javascript (Typescript, Coffeescript, Dart, et al).

                      And while Java is out of the limelight Scala is the language quite popular with the people on the JVM side, and C++ ever since C++11 has been made the cool thing again. In fact whenever it comes up in conversation fellow programmers regard Javascript with disdain, but then I hang out with programmers who like extremely strict standards, strong typing, pedantic compilers, and good tooling.


                      Originally posted by caligula View Post
                      Many companies are replacing legacy apps with JS. Soon JS will run emulators for Flash, Java, Silverlight. A single runtime to rule them all.
                      Surely you must be joking. Flash maybe since they're closish in terms of language and mozilla has decided to start on one (although in all likelihood it'll only get as far as Gnash, which is to say not far enough), Java and Silverlight though... hell no... not happening and you're completely daft if you think anyone but the most insane person is going to spend that kind of effort on a project like that. And if that person does the rest of the programming world will be looking at them with a cocked eye going WTF?

                      tl;dr:

                      Comment

                      Working...
                      X