Announcement

Collapse
No announcement yet.

Apple Implements LLVM JIT Back-End For WebKit JavaScript

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

  • Apple Implements LLVM JIT Back-End For WebKit JavaScript

    Phoronix: Apple Implements LLVM JIT Back-End For WebKit JavaScript

    For speeding up the JavaScript performance within upstream WebKit, Apple developers have implemented a new just-in-time (JIT) back-end that's based upon LLVM...

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

  • #2
    Faster Than Light (FTL) would have been a better name than Fourth Tier LLVM.

    Comment


    • #3
      Originally posted by Harsh View Post
      Faster Than Light (FTL) would have been a better name than Fourth Tier LLVM.
      Suddenly, indie gamers.

      Comment


      • #4
        Blink?

        Is this thing likely to appear in Blink?

        Comment


        • #5
          Originally posted by seedo View Post
          Is this thing likely to appear in Blink?
          That would be a no. This is JavaScriptCore, even when Chrome was using WebKit they were not using JavaScriptCore but V8. Also considering it only gives a speed-up of 20% in exchange for massive memory usage increase, bundling a full compiler, big increase in complexity and several manyears of work; FTL doesn't even look that great.

          Comment


          • #6
            I hope it can be disabled configure-time then.

            Comment


            • #7
              Originally posted by carewolf View Post
              Also considering it only gives a speed-up of 20% in exchange for massive memory usage increase, bundling a full compiler, big increase in complexity and several manyears of work; FTL doesn't even look that great.
              What are you basing any of that on?

              Comment


              • #8
                Originally posted by carewolf View Post
                That would be a no. This is JavaScriptCore, even when Chrome was using WebKit they were not using JavaScriptCore but V8. Also considering it only gives a speed-up of 20% in exchange for massive memory usage increase, bundling a full compiler, big increase in complexity and several manyears of work; FTL doesn't even look that great.
                Did someone pee in your cereal this morning or are you an Internet Explorer developer?

                Comment


                • #9
                  Originally posted by wizard69 View Post
                  Did someone pee in your cereal this morning or are you an Internet Explorer developer?
                  I am a WebKit developer. Though my perception of FTL might be tainted by the fact that when it was merged in July 2013, it managed to break everything. JavaScriptCore was unusable for more than a month after the FTL merge even though FTL was not even enabled. Not really the best of starts and it lowered my expectations of FTL dramatically (plus demonstrated the cost of added complexity even when disabled).

                  Comment


                  • #10
                    Originally posted by scottishduck View Post
                    What are you basing any of that on?
                    The webkit developers behind it are saying it will be a 33% increase. (Over the existing 3rd tier compiler). 40 times faster than interpreted vs. the 30 times faster they can already go.

                    That really just brings them back on par with their competition, it's not like this is a huge breakthrough, at least in performance. Maybe now that they've got the framework done they'll be able to get some more benefits from it soon, though.

                    Comment


                    • #11
                      Originally posted by carewolf View Post
                      That would be a no. This is JavaScriptCore, even when Chrome was using WebKit they were not using JavaScriptCore but V8. Also considering it only gives a speed-up of 20% in exchange for massive memory usage increase, bundling a full compiler, big increase in complexity and several manyears of work; FTL doesn't even look that great.
                      This seems like an extraordinarily ignorant statement.
                      - LLVM as a JIT has been a focus of attention for a long time because it's of interest to lots of people. There may be several man-years of work there, but it's work that would have happened regardless of what WebKit did. So WebKit might as well take advantage of it.
                      Such complexity as has been added to WebKit is complexity that should be added anyway; it's OBVIOUSLY the right thing to do to move JIT'ing onto a second thread that runs while the interpreter runs, and doing this with the FTL JIT lays the ground work for doing it in many other situations. EVERY bit of such work work, whether it's running the first tier JIT or the CSS compiler, should be spawned off to secondary threads as the same time as we start by using an immediate interpreter to get things going.

                      - "massive memory usage increase " is no big deal in many circumstances. Plenty of people have multiple GB of RAM available, which most of the time is being used to cache files that were last touched two weeks ago. What's wrong with using that RAM to speed things up by 20%?

                      - "bundling a full compiler" is a problem why, exactly? So the Safari binary is now 1MB larger. WTF cares?

                      It's fine to argue about technical direction; that's what tech sites are about. But you come across as a ignorant luddite who just seems pissed off that things have changed. "Life was great when everyone used a JIT that I could understand, but I don't understand this newfangled LLVM stuff so obviously it six".

                      Comment


                      • #12
                        Originally posted by name99 View Post
                        - "bundling a full compiler" is a problem why, exactly? So the Safari binary is now 1MB larger. WTF cares?
                        20MB larger, if other things using LLVM statically are any indication. In any case, he's a webkit developer which you apparently missed two posts above

                        Comment


                        • #13
                          Originally posted by curaga View Post
                          20MB larger, if other things using LLVM statically are any indication. In any case, he's a webkit developer which you apparently missed two posts above
                          That assumes that the LLVM infrastructure doesn't already exist on the system. I expect parts of it already do exist (even on non-dev systems) because the LLVM infrastructure is used, among other things, to convert GL shaders into code that's optimized for the the target GPU.
                          So the cost is not the size of the entire LLVM infrastructure, it's only some stubs and setup code in WebKit.

                          Once again, I don't understand what the issue here is. Seems like this guy is pissed off that the dev branch of WebKit was broken for a few weeks --- well, that's the life of running dev code. If you need absolute stability for your project, then you run an alternative branch that lags behind the leading edge...

                          Comment


                          • #14
                            The entire LLVM lib infra would be 165mb. I specifically said statically, because with LLVM it doesn't make much sense to link dynamically.

                            LLVM has no ABI/API compatibility, so once you have apps linked against 3.1, 3.2, 3.3 you'd have three copies of that 165mb on your system. Linking statically avoids that, and also allows the app to only link the parts it uses, bringing the average increase to only 20mb.

                            There aren't that many projects using it either. On my system it's only Mesa; if I were to add Webkit, then the total would be two. I know I'd rather take 40mb than 165mb.

                            Comment

                            Working...
                            X