4 ms·

So this is basically older versions of Firefox compiled with the Intel C++ Compiler? Given that most of Firefox is in JS so the actual code that you end up run

by rockdoe 11y ago

So this is basically older versions of Firefox compiled with the Intel C++ Compiler? Given that most of Firefox is in JS so the actual code that you end up running is the JIT output, I'd be very skeptical it's any faster. They certainly don't provide any objective data that it is. (And if it were, I'd assume Mozilla would just Intel C for the official builds, too?)

gsnedders 11y ago
> Given that most of Firefox is in JS so the actual code that you end up running is the JIT output, I'd be very skeptical it's any faster. Most of Firefox is JS? Almost all of the lines of code are C++, as far as I'm aware. Certainly the UI is drawn using XUL/XBL/web-stuff, but how often is web performance bounded by UI performance? It's bounded by the performance of the rendering engine, and that is C++. > (And if it were, I'd assume Mozilla would just Intel C for the official builds, too?) Seems unlikely, given the output of ICC is crippled for non-Intel x86 chips (which de-facto means AMD nowadays).
- rockdoe 11y ago
  >Almost all of the lines of code are C++ Significant parts of the functionality are written in JS. >but how often is web performance bounded by UI performance? It's often bounded by JS performance. JS performance depends on the JIT output, much less so the speed with which the JIT itself runs. The rendering engine may be a factor, but there HW acceleration also factors in. It's far from being clear cut. Media decoding already uses optimized assembler, nothing for the compiler to do there. I'd suppose most of the gain would be in layout? >Seems unlikely, given the output of ICC is crippled for non-Intel x86 chips (which de-facto means AMD nowadays). You can patch that out. I'd hope this Waterfox is doing that... Even so, Mozilla provides a stub installer that downloads the right binary nowadays. It could check the chip vendor and get the appropriate binary.
  - gsnedders 11y ago
    > Significant parts of the functionality are written in JS. Such as? > It's often bounded by JS performance. JS performance depends on the JIT output, much less so the speed with which the JIT itself runs. On what? Last I looked, even things like FB & Gmail are largely bound by performance of C++ code. Sure, there's a few hot JS functions high-up in the profiles (esp. in the large data structures they build up when initially loading), but by and large time is spent in C++ code, not JS.
    - rockdoe 11y ago
      >Such as? Looks for .js and .jsm in the source tree. Bookmarks, Tab management, all UX, PDF viewer, Search, Prefs, Sync, parts of SafeBrowsing, WebRTC, Update Handling, Login and Form manager, Devtools, Reader Mode, and uh I think I've proven my point.
      - RussianCow 11y ago
        But none of those things will ever really bottleneck the browser except for maybe the PDF viewer. The performance of bookmarks, tab management, search, and basically all your other examples doesn't matter. The parts of the browser that benefit from speed are written in C++. Not that I'm convinced simply compiling with ICC will actually have a noticeable impact on the day-to-day performance of the browser, but it might speed up layout and other specific CPU-bound tasks. I'd love to see some benchmarks, but I think it's silly to shrug it off by saying that it won't matter because the browser UI is written in JavaScript.
        nickpsecurity 11y ago
        Explains why it barely handles my hundreds of bookmarks, though. Maybe I need to rewrite that part in native code haha.
        fungos 11y ago
        It seems a joke but is also, sadly, a fact. Chrome bookmarks manager is lightspeed if compared to Firefox, to not mention total lack of usability on Firefox's part, so 1995.

by rockdoe 11y ago

gsnedders 11y ago

> Given that most of Firefox is in JS so the actual code that you end up running is the JIT output, I'd be very skeptical it's any faster. Most of Firefox is JS? Almost all of the lines of code are C++, as far as I'm aware. Certainly the UI is drawn using XUL/XBL/web-stuff, but how often is web performance bounded by UI performance? It's bounded by the performance of the rendering engine, and that is C++. > (And if it were, I'd assume Mozilla would just Intel C for the official builds, too?) Seems unlikely, given the output of ICC is crippled for non-Intel x86 chips (which de-facto means AMD nowadays).

rockdoe 11y ago
>Almost all of the lines of code are C++ Significant parts of the functionality are written in JS. >but how often is web performance bounded by UI performance? It's often bounded by JS performance. JS performance depends on the JIT output, much less so the speed with which the JIT itself runs. The rendering engine may be a factor, but there HW acceleration also factors in. It's far from being clear cut. Media decoding already uses optimized assembler, nothing for the compiler to do there. I'd suppose most of the gain would be in layout? >Seems unlikely, given the output of ICC is crippled for non-Intel x86 chips (which de-facto means AMD nowadays). You can patch that out. I'd hope this Waterfox is doing that... Even so, Mozilla provides a stub installer that downloads the right binary nowadays. It could check the chip vendor and get the appropriate binary.
- gsnedders 11y ago
  > Significant parts of the functionality are written in JS. Such as? > It's often bounded by JS performance. JS performance depends on the JIT output, much less so the speed with which the JIT itself runs. On what? Last I looked, even things like FB & Gmail are largely bound by performance of C++ code. Sure, there's a few hot JS functions high-up in the profiles (esp. in the large data structures they build up when initially loading), but by and large time is spent in C++ code, not JS.
  - rockdoe 11y ago
    >Such as? Looks for .js and .jsm in the source tree. Bookmarks, Tab management, all UX, PDF viewer, Search, Prefs, Sync, parts of SafeBrowsing, WebRTC, Update Handling, Login and Form manager, Devtools, Reader Mode, and uh I think I've proven my point.
    - RussianCow 11y ago
      But none of those things will ever really bottleneck the browser except for maybe the PDF viewer. The performance of bookmarks, tab management, search, and basically all your other examples doesn't matter. The parts of the browser that benefit from speed are written in C++. Not that I'm convinced simply compiling with ICC will actually have a noticeable impact on the day-to-day performance of the browser, but it might speed up layout and other specific CPU-bound tasks. I'd love to see some benchmarks, but I think it's silly to shrug it off by saying that it won't matter because the browser UI is written in JavaScript.
      - nickpsecurity 11y ago
        Explains why it barely handles my hundreds of bookmarks, though. Maybe I need to rewrite that part in native code haha.
        fungos 11y ago
        It seems a joke but is also, sadly, a fact. Chrome bookmarks manager is lightspeed if compared to Firefox, to not mention total lack of usability on Firefox's part, so 1995.