| |||||||||||||
|
| |||||||||||||
You can achieve the same speed, but certainly not the same simplicityYou can achieve the same speed, but certainly not the same simplicityPosted Jan 12, 2009 13:00 UTC (Mon) by ibukanov (subscriber, #3942)In reply to: You can achieve the same speed, but certainly not the same simplicity by khim Parent article: Chrome 2.0 Preview Means Mac, Linux Versions Coming Soon (Wired blog)
> But this replaces SIMPLE AND EFFICIENT system
While I agree with the simplicity part of fork-based solution, they are less efficient than mmap-based initialization. With fork one need to keep an extra process around to clone children. That takes resources including extra memory that is not relevant to the initialization image.
(Log in to post comments)
Cost in neglible Posted Jan 12, 2009 13:12 UTC (Mon) by khim (guest, #9252) [Link] You need 12K or so (8K in kernelspace, 4K in userspace) - not a big deal even for phones, let alone desktops...
Cost in neglible Posted Jan 12, 2009 17:37 UTC (Mon) by ibukanov (subscriber, #3942) [Link]
> You need 12K or so
With the fork it is hard to control all the memory in the to-be-forked process that is used by shared libraries upon initialization. This memory will be most likely changed in the child process (otherwise there would be no pint to link the library). This wasted memory can easily eat hundreds times more than those 12K.
Also note that with a fork-based solution one need to setup communication between 3 processes (the main control process, to-be-forked prototype and the child processes) complicating the code compared with that dump/mmap case when one deals with just main-child relations.
So as I wrote fork-based solutions are simpler, but for a complex applications such as a browser the fork may not be the most efficient way to handle things.
Hard to control, but usually not a liability Posted Jan 12, 2009 20:44 UTC (Mon) by khim (guest, #9252) [Link] With the fork it is hard to control all the memory in the to- be-forked process that is used by shared libraries upon initialization. This memory will be most likely changed in the child process (otherwise there would be no pint to link the library). Actually a lot of libraries share memory after fork and don't change it. They load translation tables, conversion tables, etc - and more often then not they just read it after initialization and don't change. YMMV (it depnds of what is actually linked in your program), but to say initialization data for different libraries is a liability of fork is to oversimlify the problem. When I look on the new process with empty page in Chrome and see that it eats over 5MB (RSS, not virtual or shared) it becomes quite hard to convince me that fork will do worse.
Hard to control, but usually not a liability Posted Jan 12, 2009 21:38 UTC (Mon) by ibukanov (subscriber, #3942) [Link]
> new process with empty page in Chrome and see that it eats over 5MB
But that does not invalidate my claim that with enough efforts one can archive better memory utilization with dump/mmap sharing rather than in a fork-based version with the added benefits that the latter can be straightforwardly ported to Windows. This comes from the facts that with a dump one can precisely control what to share and rarely used parts of the shared image do not require loading until they are accessed.
Of cause, in most cases those efforts to implement dump/mmap are not justifiable, but a browser is a special case where the complexity of the rest of code allows to spend some efforts to optimize sharing.
As regarding those 5MB of private data in Chrome they may indicate that Chrome's developers has not bothered to optimize sharing. Or that Chrome really needs that amount of memory for various caches and JIT. That would not be surprising given that on my system a new xterm eats roughly 3MB of unshared memory while gnome-terminal consumes 6MB just to show plain text.
Hard to control, but usually not a liability Posted Jan 24, 2009 1:01 UTC (Sat) by gdamjan (subscriber, #33634) [Link]
The difference beeing, that fork thing has been field tested for milions of years (internet years), used very-very often, and probably as perfect as it gets in software.
Unlike you own very special and complex code.
|
|
||||||||||||