Announcement

Collapse
No announcement yet.

Firefox Developers Continue Tuning ASM.js Performance

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

  • #11
    Originally posted by Thaodan View Post
    you WASTE 50% speed on an already low powered device?
    FirefoxOS application are intended to be universal, so web application make sense and it doesn't mean that software aren't running locally, just that they use web standard.

    Comment


    • #12
      Originally posted by mark45 View Post
      Asm.js isn't meant to be used by hand, it's too low level, it only solves the performance issue of porting certain apps from native languages.
      It's not a cure, it's a painkiller, and hence has limited future and also widely depends on how Dart is gonna do.
      How is asm.js a painkiller? (A painkiller solves nothing and only hides the pain)

      Comment


      • #13
        Originally posted by Thaodan View Post
        you WASTE 50% speed on an already low powered device?
        Explain please.

        Comment


        • #14
          Originally posted by Thaodan View Post
          you WASTE 50% speed on an already low powered device?
          Chill out. Even though I'd prefer native code, specially in resource constrained environments as mobile, that's currently the norm. Scripted/JIT languages provide some conveniences apps developers want, such as not having to test in every platform out there (portability). The only ones not using this kind of resource wasting (well, some resources, one could argue there is a very important resource which is more efficiently used with those languages, the developer's time) are Apple. Android runs the apps in a Java VM called Dalvik, for example. WinRT, AFAIK, uses .NET, which is managed and pretty much similar to JVM.

          Originally posted by Ferdinand View Post
          Explain please.
          It runs at around 50-75% the speed of native code, so the OP feels it's wasting that 50-25%.

          Comment


          • #15
            MS's own apps for WinPhone were almost all C++, and for WP8+ they graciously allowed non-MS developers too to use native languages. We must bow our heads, for this gift of fire is entirely wasted on our lowly selves. Afterall, weren't we already speechless in our gratitude for being allowed to use an incomplete and slow .Net implementation?

            Note that winRT != winPhone.

            Comment


            • #16
              Originally posted by azakai View Post
              As I wrote in a comment on the blog, yes, the version can matter. I didn't test the very latest LLVM and gcc versions because the goal wasn't to see the very limit of performance, but get a more broad picture of what results people can get by using typical native compilers (most applications people use are not compiled with bleeding edge compilers).

              So I used the gcc that came with my linux distro - it's the one that built practically every single app I run on my machine - and for LLVM, I used the same version used by emscripten, which means it has identical frontend optimizations and the comparison of native to JS is more apples-to-apples. But again, I agree that testing the very latest is interesting as well, just depends on what your purpose is.
              Thank you very much for your reply.
              I have to say that i've only read the phoronix article and not your blog post. I Should have read yours as well before claiming unfair comparison by mozilla (you).

              I do now get why you compared against clang.

              Good luck squeezing out the last part to be at native (clang) speeds. I do performance optimization quite often (in completely different areas) and know that the last bit towards a set goal are usually the most difficult parts to get.

              Comment


              • #17
                Honestly most apps aren't cpu limited anyway

                I mean, the occasional app like unzipping can go as fast as possible, but for the most part i think the main concern with asm.js is now memory usage, not cpu usage. That, and the fact that the increased cpu usage means a bit more power is being used, which is important on mobile.

                Comment

                Working...
                X