3 ms·

What is ‘browser scale’? I’d imagine most browsers spend most of their time idle.

Slartie 4y ago
If you want to see some of the most complex multithreading systems, take a look inside modern browsers. That's what he means by "browser scale". I have some knowledge into working with Chromium's internals, and it is crazy what's going on inside there. Several different job and message queue systems interlocking with each other, tasks spread across multiple processes getting split and regrouped and synced and recombined, practically everything running async, just so a few pixels are rendered a little faster when your multicore machine updates a small section of a website. Browsers are indeed idling a lot, but if you want them to do something, they must be as crazy fast as possible. The competition in that space is ridiculous.
jerf 4y ago
In the tens of millions to hundreds of millions of lines of code. Browsers are some of the largest things out there. See also desktop office suites, multi-decade CAD programs, a few other things. Few programs are at that scale. IIRC, even the Linux kernel isn't really at that scale, once you clean away a few files in the drivers that are just literally millions of #defines or something. If you're writing at that scale, by all means copy the necessary practices, but don't just casually assume your need is super large and you've just gotta use the hard-core lock-based concurrency because it's the only option for you. You can get a long way with much nicer architecture that is only slightly slower. For instance, I write a lot of Go. I've sometimes gotten a bit nervous about writing a goroutine (/thread) that owns some particular data structure because I'm like "wow, a lot of things are going to access this, is this going to become a bottleneck in the system?" But every time I've run the analysis carefully, the answer generally comes back not just "no" but "heck no, not even close". Your intuition can deceive you very easily. Locking a single structure behind the limit that "we can only dedicate at most 1 CPU full time to maintaining this structure" is, in practice, far less scary than it sounds. 1 CPU is a lot of power and you generally need a lot of other CPUs trying to access it simultaneously to overwhelm it. Ahdahl's Law kinda works in your favor on this matter (for once); for something like this to be the bottleneck, it needs to approach accounting for (1/(CPUs - 1)) of your execution time, and for that to be the case, those other processes hammering this 1-CPU-locked data structure need to be doing whatever else they are doing very quickly. As with anything in discussions like this, it absolutely can happen! But always check your intuition concretely before going crazy adopting something more complicated and "higher performance"; odds are good this isn't a problem for a given "random" data structure.

If you want to see some of the most complex multithreading systems, take a look inside modern browsers. That's what he means by "browser scale". I have some knowledge into working with Chromium's internals, and it is crazy what's going on inside there. Several different job and message queue systems interlocking with each other, tasks spread across multiple processes getting split and regrouped and synced and recombined, practically everything running async, just so a few pixels are rendered a little faster when your multicore machine updates a small section of a website. Browsers are indeed idling a lot, but if you want them to do something, they must be as crazy fast as possible. The competition in that space is ridiculous.

jerf 4y ago

In the tens of millions to hundreds of millions of lines of code. Browsers are some of the largest things out there. See also desktop office suites, multi-decade CAD programs, a few other things. Few programs are at that scale. IIRC, even the Linux kernel isn't really at that scale, once you clean away a few files in the drivers that are just literally millions of #defines or something. If you're writing at that scale, by all means copy the necessary practices, but don't just casually assume your need is super large and you've just gotta use the hard-core lock-based concurrency because it's the only option for you. You can get a long way with much nicer architecture that is only slightly slower. For instance, I write a lot of Go. I've sometimes gotten a bit nervous about writing a goroutine (/thread) that owns some particular data structure because I'm like "wow, a lot of things are going to access this, is this going to become a bottleneck in the system?" But every time I've run the analysis carefully, the answer generally comes back not just "no" but "heck no, not even close". Your intuition can deceive you very easily. Locking a single structure behind the limit that "we can only dedicate at most 1 CPU full time to maintaining this structure" is, in practice, far less scary than it sounds. 1 CPU is a lot of power and you generally need a lot of other CPUs trying to access it simultaneously to overwhelm it. Ahdahl's Law kinda works in your favor on this matter (for once); for something like this to be the bottleneck, it needs to approach accounting for (1/(CPUs - 1)) of your execution time, and for that to be the case, those other processes hammering this 1-CPU-locked data structure need to be doing whatever else they are doing very quickly. As with anything in discussions like this, it absolutely can happen! But always check your intuition concretely before going crazy adopting something more complicated and "higher performance"; odds are good this isn't a problem for a given "random" data structure.