Multiprocess Firefox • Hacker News Board

Re: Multiprocess Firefox

#21

Post by pjmlp » Thu, Dec 05, 2013, 1:41 PM UTC

rdtsc wrote: post #13

csmuk wrote: post #7

Earlier quoted context omitted.

Personally I prefer message passing (over pipes). Shared memory (be it shm/heap in same process) with associated mutexes, semaphores, locks and the like is a right pain to get right without introducing race conditions, deadlocks etc. Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet.

> Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet. But is also has shared heaps by default. So you still have to rely on everyone being an "adult". I wish shared heaps would have been a specially enabled feature not the default. But I guess the language was position to compete with C++ and Java and isolated heaps would have provided a perfor…

In D, by default global data is actually thread local. You need to explicitly enable sharing.

Re: Multiprocess Firefox

#22

Post by pjmlp » Thu, Dec 05, 2013, 1:43 PM UTC

AndrewDucker wrote: post #11

csmuk wrote: post #7

Earlier quoted context omitted.

Personally I prefer message passing (over pipes). Shared memory (be it shm/heap in same process) with associated mutexes, semaphores, locks and the like is a right pain to get right without introducing race conditions, deadlocks etc. Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet.

This is why Mozilla are investing heavily in Rust, so that they can use its semantics to share memory in a safe way.

Yes, I look forward to the day memory unsafe languages are only part of legacy systems.

Re: Multiprocess Firefox

#23

Post by kibwen » Thu, Dec 05, 2013, 1:45 PM UTC

For those of you interested in parallelism in browsers, I suggest you keep an eye on Mozilla's experimental new browser engine, Servo.[1] The goal is to make use of a variety of concurrency strategies (such as a Chrome-esque process-per-tab design[2]) and Rust's built-in support for memory-safe concurrency abstractions (fork/join, lightweight tasks, SIMD, etc.) to produce a ludicrously parallel[3] web browser. And even if Servo itself never happens to make its way into production, one of its purposes is to enable Mozilla to explore effective parallelism strategies to pursue with Gecko.

[1] https://github.com/mozilla/servo/

[2] I wasn't exactly thrilled about this myself, but as long as Servo has to interact with C++ code (notably, SpiderMonkey) this was judged critical for security. Fortunately, pcwalton seems to believe that Servo's tab processes will occupy less memory than Chrome's.

[3] https://github.com/mozilla/servo/wiki/Design

Re: Multiprocess Firefox

#24

Post by nly » Thu, Dec 05, 2013, 1:48 PM UTC

I welcome this just so we can determine which tabs are using the CPU persistently. I had to switch back to Chromium (after a good few weeks really giving FF another go) because I was sick of this issue. Firefox is smoother and more memory friendly than Chromium these days, a pleasure to use, but in Chrome I can kill hoggy tabs... so that's where I'm staying for the moment.

Re: Multiprocess Firefox

#25

Post by nly » Thu, Dec 05, 2013, 1:49 PM UTC

fenesiistvan wrote: post #15

My biggest problem with Firefox is its startup time. It takes much longer to start the firefox.exe then IE and Chrome which are both very fast. I am using Win7 on i7-3960X, intel SSD, 16 GB RAM. If I install any plugin then this thing is much worst. (For this reason I am not using any plugin which is a big loss). It is weird that this issue is seldomly mentioned, but I think that it is much more important then the ot…

I don't have no/low tab cold start problems in either.

... that said, try closing Chromium with 20 odd tabs open and then reopening it. It'll take bloody ages to reload all those tabs. Firefox lazy tab loading saves a metric buttload of time in this scenario.

Re: Multiprocess Firefox

#26

Post by moron4hire » Thu, Dec 05, 2013, 1:54 PM UTC

fenesiistvan wrote: post #15

My biggest problem with Firefox is its startup time. It takes much longer to start the firefox.exe then IE and Chrome which are both very fast. I am using Win7 on i7-3960X, intel SSD, 16 GB RAM. If I install any plugin then this thing is much worst. (For this reason I am not using any plugin which is a big loss). It is weird that this issue is seldomly mentioned, but I think that it is much more important then the ot…

Whaaaat are you doing? I've got it on an SSD on lesser specs than you and it comes up practically instantly.

Re: Multiprocess Firefox

#27

Post by csmuk » Thu, Dec 05, 2013, 1:59 PM UTC

rdtsc wrote: post #13

csmuk wrote: post #7

Earlier quoted context omitted.

Personally I prefer message passing (over pipes). Shared memory (be it shm/heap in same process) with associated mutexes, semaphores, locks and the like is a right pain to get right without introducing race conditions, deadlocks etc. Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet.

> Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet. But is also has shared heaps by default. So you still have to rely on everyone being an "adult". I wish shared heaps would have been a specially enabled feature not the default. But I guess the language was position to compete with C++ and Java and isolated heaps would have provided a perfor…

My C code doesn't share heaps. Strict privsep design meaning one heap per process and no threads in favour of "select".

Re: Multiprocess Firefox

#28

Post by ferongr » Thu, Dec 05, 2013, 2:00 PM UTC

com2kid wrote: post #6

aquadrop wrote: post #2

It also brings the possibility to overcome ~4GB memory limit per x32 process. Which is nice.

Very nice indeed, I crash Firefox a few times a day from hitting the memory limit. Granted this is due to AB+ and Reddit Enhancement Suite. Although imo.im leaking memory over time doesn't help! (I am somewhat annoyed that an IM client takes up 500MB of memory, I miss Meebo!) Right now FF is at a fairly svelte 1.8GB. Heh. The other problem is that performance degrades dramatically as the number of open tabs increases…

>Once I hit 50 or so tabs scrolling becomes horribly jerky

That could be a GPU driver issue. GPU scheduling is generally horrible outside the "run a fullscreen game as fast as you can and screw everything else" usercase.

Re: Multiprocess Firefox

#29

Post by kibwen » Thu, Dec 05, 2013, 2:01 PM UTC

rdtsc wrote: post #13

csmuk wrote: post #7

Earlier quoted context omitted.

Personally I prefer message passing (over pipes). Shared memory (be it shm/heap in same process) with associated mutexes, semaphores, locks and the like is a right pain to get right without introducing race conditions, deadlocks etc. Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet.

> Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet. But is also has shared heaps by default. So you still have to rely on everyone being an "adult". I wish shared heaps would have been a specially enabled feature not the default. But I guess the language was position to compete with C++ and Java and isolated heaps would have provided a perfor…

> Anyone know of more?

Rust's "tasks" feature isolated memory, and, thanks to the magic of linear types, passing data from one to another is both statically-guaranteed to be safe and is never more expensive than the cost of copying a pointer.

Re: Multiprocess Firefox

#30

Post by nly » Thu, Dec 05, 2013, 2:01 PM UTC

csmuk wrote: post #7

sp332 wrote: post #5

Earlier quoted context omitted.

It's always been a better sandbox model, but message passing is still a pain to orchestrate compared to shared-memory data structures.

Personally I prefer message passing (over pipes). Shared memory (be it shm/heap in same process) with associated mutexes, semaphores, locks and the like is a right pain to get right without introducing race conditions, deadlocks etc. Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet.

Going multiprocess and using IPC doesn't intrinsically eliminate any of the tricky concurrency challenges with multi-threading. Neither do coroutines (goroutines).

When you have multiple processes talking to another then, unless all your RPCs are completely stateless, you still need to orchestrate synchronisation in some form. There's also the problem that in 2013 we still don't really know how to do IPC/RPCs really well, and doing so portably is hard (Notice Mozilla are writing their own from scratch)

It's all very well new languages coming along and solving the trivial stuff (setting up message queues, isolating memory) but very few of them do anything to solve the real problems.