Announcement

Collapse
No announcement yet.

SIMD JavaScript Support Added To Firefox, Under Review For Chrome

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

  • SIMD JavaScript Support Added To Firefox, Under Review For Chrome

    Phoronix: SIMD JavaScript Support Added To Firefox, Under Review For Chrome

    One of Intel's latest open-source adventures has been adding support for SIMD (Single Instruction, Multiple Data) instructions to JavaScript...

    http://www.phoronix.com/vr.php?view=MTY0ODE

  • #2
    So do you need avx / avx 2? or you can get some benefits just with SSE 4.1?

    Comment


    • #3
      Originally posted by Sdar View Post
      So do you need avx / avx 2? or you can get some benefits just with SSE 4.1?
      I'm pretty sure you would get most of the benifits just having SSE2, probably even with just MMX you could get somthing out of it.

      Comment


      • #4
        Dear Apple,

        Thanks for being such a huge backer of LLVM and creating Clang, for without this investment [and later Google, SONY, Cray, IBM, Intel, etc] these advances don't create Emscripten, and dozens of other recently projects making commercial and foss software that much better.

        Sincerely,

        People not obsessed with FOSS who continue in the face of FOSS self-righteous condesencion to make computing better for everyone.

        P.S. I expect everyone to thank Google for ARM64, LLVM and everything that goes with it for they are so ``Do No Evil'' in today's youth's eyes.

        Where would the world be without Google creating WebKit? Why we better thank KDE because we know Apple owes WebKit to KDE, the same folks who never used WebKit until the entire industry did. /s

        Comment


        • #5
          WebKit was actually pretty bad (safari3 would consistantly crash on undo) prior to when Google started contributing. Apple also did a realy bad job of sharing patches with khtml pretty much killing it. Though i will agree that Apple deserves much credit for there part in WebKit's development.

          Comment


          • #6
            Originally posted by Marc Driftmeyer View Post
            People not obsessed with FOSS who continue in the face of FOSS self-righteous condesencion to make computing better for everyone.
            Without FOSS this and a lot of other software would not exist.

            Originally posted by Marc Driftmeyer View Post
            P.S. I expect everyone to thank Google for ARM64, LLVM and everything that goes with it for they are so ``Do No Evil'' in today's youth's eyes.
            What? The ARM64 backend is from Apple. The original roots for LLVM were from Chris Lattner and Vikram Adve while at the University of Illinois.


            Originally posted by Marc Driftmeyer View Post
            Where would the world be without Google creating WebKit?
            Google did not create WebKit. Apple did.

            Originally posted by Marc Driftmeyer View Post
            Why we better thank KDE because we know Apple owes WebKit to KDE
            Of course the KDE project deserves some credit. Without KHTML / KJS WebKit would not exist.

            Originally posted by Marc Driftmeyer View Post
            the same folks who never used WebKit until the entire industry did.
            They had no choice but to wait until KDE 5 to switch the default rendering / JavaScript engine as it would have broken backwards compatibility. WebKit was not a 100% compatible drop in replacement for all of the API KHTML / KJS provided.

            Comment


            • #7
              Ported from Dart

              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

              Comment


              • #8
                As much as it might improve performance, it feels just so wrong to me that we're at the point in the modern web where we need SIMD instructions. Seriously... if you need that kind of performance client side maybe you shouldn't be writing a web application?

                Comment


                • #9
                  Originally posted by Luke_Wolf View Post
                  As much as it might improve performance, it feels just so wrong to me that we're at the point in the modern web where we need SIMD instructions. Seriously... if you need that kind of performance client side maybe you shouldn't be writing a web application?
                  There is no good reason not to improve the performance of JavaScript for apps that can benefit from it such as games, emulators or forms of media processing. You're just being narrow minded.

                  Comment


                  • #10
                    Originally posted by brad0 View Post
                    There is no good reason not to improve the performance of JavaScript for apps that can benefit from it such as games, emulators or forms of media processing. You're just being narrow minded.
                    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.

                    Comment


                    • #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; 03-31-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

                              Working...
                              X