7 ms·

The 7740X retaining dominance in browser-oriented tests demonstrates the continued bottleneck we suffer due to the "single-threaded" (or nominally single-thread

by bhauer 9y ago

The 7740X retaining dominance in browser-oriented tests demonstrates the continued bottleneck we suffer due to the "single-threaded" (or nominally single-threaded) predilection of web browsers, the DOM, and JavaScript. Servo and other concurrency-oriented innovations are going to be very welcome when they arrive in earnest.

mtgx 9y ago
Does Mozilla plan to implement that part of Servo through Project Quantum, or not right now?
- masklinn 9y ago
  I guess, Quantum CSS is the integration of Stylo (parallelised CSS system) into Firefox.
  - the8472 9y ago
    and webrender too. webrender is already available in nightly as experimental option while they're still working on integrating stylo. https://github.com/servo/webrender/wiki https://github.com/servo/webrender/wiki
    - masklinn 9y ago
      WebRender is a GPU renderer though, I don't think it makes much use of on-CPU parallelisation.
guelo 9y ago
Servo is a layout engine but the benchmarks are mostly testing javascript performance. Extra cpu cores are not going to speed up JS benchmarks, not because JS is single-threaded but because the benchmarks themselves have to be designed to test multiple threads. The same would be true if the benchmarks were written in C, if you want to test multithreading you have to write code to do it. Javascript benchmarks could test multithreading via Web Workers but for whatever reasons they don't seem to.
- the8472 9y ago
  browser benchmarks could test more than javascript execution. dom layout, canvas rendering, scrolling etc. Some of those things can benefit from multiple threads even if JS is single-threaded. Allocation-heavy workloads will also benefit from concurrent and parallel GC implementations.
- bhauer 9y ago
  > Javascript benchmarks could test multithreading via Web Workers but for whatever reasons they don't seem to. Well, like I said, JavaScript has a long history and therefore a predilection for single-threading. Yes, you could write tests that exercise Web Workers, but Web Workers are still infrequently used in the wild, let alone in benchmarking suites. I've used Web Workers in a few projects and I'm underwhelmed by their current features. I can't really blame the JavaScript community at large for not using them much yet. The DOM and other elements of browsers also have single-threaded assumptions or behaviors. More multi-threaded capability is a first step, and then we'll need to take advantage of that capability.
deleted 9y ago
[deleted]
bo1024 9y ago
I don't understand why anyone would design a website so complex that there is a noticeable benchmark difference between $100 processors and $1000 processors.
- olau 9y ago
  They wouldn't, but they do. Frameworks upon frameworks upon frameworks, and nobody knows what happens underneath. If you are a gmail.com user, have you ever tried the plain HTML version? The difference in speed is mind-boggling. Yes, the Javascript version is doing more, but it should also be able to be faster as it doesn't have to load the whole page each time.
  - Groxx 9y ago
    Similarly: running with e.g. noscript reminds you that internet speeds actually have improved over the years. Pages load in instants rather than seconds, it's wonderful.
  - old-gregg 9y ago
    Fun anecdote: I tried using newegg.com to build a PC based on these new processors. My 2 year old Macbook Pro almost melted, with only about 6-7 tabs (all pointing to different parts on newegg.com) open. This is kind of ironic: you need a really powerful PC to use a web site which sells powerful PCs. Catch-22. No. I do not want a web page to be able to eat up more than one core. Frankly, I feel like I want to try a browser extension that "locks" any web page within 20% of a core performance. These developments make me believe that browser-based apps, that were "around the corner" 10 years ago, is a lost cause. Despite numerous optimizations done to Javascript engines and despite tremendous performance of modern CPUs, browser-based apps continue to crawl at a speed of early IBM PCs of the 80s. Even a 286 circa 1992 running DOS apps felt faster than newegg.com in 2017 on a modern Intel i7. Sure its tempting to blame "lazy programmers" and bloated frameworks, but bad engineering, tight schedules and tech debut have always existed, for all platforms, all the time. There's just something fundamentally broken about apps built on asynchronous loading of dozens of UI components from a remote location and assembling them into a coherent UI screen as the pieces arrive.

by bhauer 9y ago

mtgx 9y ago

Does Mozilla plan to implement that part of Servo through Project Quantum, or not right now?

masklinn 9y ago
I guess, Quantum CSS is the integration of Stylo (parallelised CSS system) into Firefox.
- the8472 9y ago
  and webrender too. webrender is already available in nightly as experimental option while they're still working on integrating stylo. https://github.com/servo/webrender/wiki https://github.com/servo/webrender/wiki
  - masklinn 9y ago
    WebRender is a GPU renderer though, I don't think it makes much use of on-CPU parallelisation.

guelo 9y ago

Servo is a layout engine but the benchmarks are mostly testing javascript performance. Extra cpu cores are not going to speed up JS benchmarks, not because JS is single-threaded but because the benchmarks themselves have to be designed to test multiple threads. The same would be true if the benchmarks were written in C, if you want to test multithreading you have to write code to do it. Javascript benchmarks could test multithreading via Web Workers but for whatever reasons they don't seem to.

the8472 9y ago
browser benchmarks could test more than javascript execution. dom layout, canvas rendering, scrolling etc. Some of those things can benefit from multiple threads even if JS is single-threaded. Allocation-heavy workloads will also benefit from concurrent and parallel GC implementations.
bhauer 9y ago
> Javascript benchmarks could test multithreading via Web Workers but for whatever reasons they don't seem to. Well, like I said, JavaScript has a long history and therefore a predilection for single-threading. Yes, you could write tests that exercise Web Workers, but Web Workers are still infrequently used in the wild, let alone in benchmarking suites. I've used Web Workers in a few projects and I'm underwhelmed by their current features. I can't really blame the JavaScript community at large for not using them much yet. The DOM and other elements of browsers also have single-threaded assumptions or behaviors. More multi-threaded capability is a first step, and then we'll need to take advantage of that capability.

deleted 9y ago

[deleted]

bo1024 9y ago

I don't understand why anyone would design a website so complex that there is a noticeable benchmark difference between $100 processors and $1000 processors.

olau 9y ago
They wouldn't, but they do. Frameworks upon frameworks upon frameworks, and nobody knows what happens underneath. If you are a gmail.com user, have you ever tried the plain HTML version? The difference in speed is mind-boggling. Yes, the Javascript version is doing more, but it should also be able to be faster as it doesn't have to load the whole page each time.
- Groxx 9y ago
  Similarly: running with e.g. noscript reminds you that internet speeds actually have improved over the years. Pages load in instants rather than seconds, it's wonderful.
- old-gregg 9y ago
  Fun anecdote: I tried using newegg.com to build a PC based on these new processors. My 2 year old Macbook Pro almost melted, with only about 6-7 tabs (all pointing to different parts on newegg.com) open. This is kind of ironic: you need a really powerful PC to use a web site which sells powerful PCs. Catch-22. No. I do not want a web page to be able to eat up more than one core. Frankly, I feel like I want to try a browser extension that "locks" any web page within 20% of a core performance. These developments make me believe that browser-based apps, that were "around the corner" 10 years ago, is a lost cause. Despite numerous optimizations done to Javascript engines and despite tremendous performance of modern CPUs, browser-based apps continue to crawl at a speed of early IBM PCs of the 80s. Even a 286 circa 1992 running DOS apps felt faster than newegg.com in 2017 on a modern Intel i7. Sure its tempting to blame "lazy programmers" and bloated frameworks, but bad engineering, tight schedules and tech debut have always existed, for all platforms, all the time. There's just something fundamentally broken about apps built on asynchronous loading of dozens of UI components from a remote location and assembling them into a coherent UI screen as the pieces arrive.