

Chrome, multicore and embarrassing parallelism - sanj
http://blog.luckycal.com/?p=20

======
MicahWedemeyer
To take advantage of multiple cores doesn’t require multiple (heavyweight)
processes. A single multithreaded process would do just as well.

Not to say it’s a bad idea, just that we’ve got to remember that multiple
processes is nothing revolutionary. A single thread for each tab would
probably work just as well from a parallelization standpoint, but you’d lose
the ability to kill one without bringing down the entire browser.

~~~
sanj
I agree. However, it seems like a fundamentally simpler to build a share-
nothing system than a threaded one.

~~~
anamax
Yes, but "share-nothing" almost always has some sharing. (If it doesn't, it
can be run somewhere else, by someone else, at some other time, including
"never".)

~~~
iman
yeah, chrome tabs are not "shared-nothing".

They have a common document cache, a common cookie store, a common history
store, probably a common dns lookup result cache, and maybe some other things.
These all need to be carefully synchronized between multiple tabs.

In fact, I would argue that multi threaded would be better than multi process
so that even more things could be easily shared. For example, I imagine that
css stylesheets are parsed into some big fat data structure inside browsers.
If I open two tabs from a website that share a stylesheet it would be optimal
if they share this same internal representation (no locking would be required
for the sharing since it's read-only). This has the obvious savings of memory,
but it also increases speed since the css file only has to be parsed and
processed once instead of multiple times. And things like sharing keep-alive
connections between tabs are virtually impossible with multi process, while
very possible with multiple threads.

~~~
anewaccountname
>probably a common dns lookup result cache

Uhh, from the OS they get that for free.

~~~
iman
But nevertheless, browsers still maintain their own internal cache. Firefox:
[http://jelmer.jteam.nl/2006/11/04/disabling-the-firefox-
dns-...](http://jelmer.jteam.nl/2006/11/04/disabling-the-firefox-dns-cache/)

------
cx01
I don't really get what he's saying. Most of the time you will have one active
tab, which is consuming a lot of CPU, and all the other tabs in the background
will do nothing. Dividing those background tabs onto multiple cores won't
bring any significant performance enhancement.

~~~
dabeeeenster
If you have a tab in the background that has flash elements (i.e. most sites
with animated ads these days) they will continue to run, even if the tab is
hidden. This will have a knock on performance hit.

~~~
rbanffy
I really think that there should be a way to shut down "smart" content that´s
invisible as not to steal CPU cycles from other tasks. I don´t think Flash
content is that much important you need to run it all the time.

~~~
wmf
This is already done in Safari (and probably other browsers):
<http://webkit.org/blog/96/background-music/>

_In both Safari 2 and WebKit nightlies, GIFs don’t animate unless they are
being painted somewhere. If an animated GIF becomes invisible, then the
animation will pause and no CPU will be consumed by the animation. Therefore
all animated images in a background tab will not animate until the page in
that tab becomes visible. If an animated GIF is scrolled offscreen even on a
foreground page, it will stop animating until it becomes visible again._

 _Many plugins do animation and work based off being pumped “null events” in
which they do processing. The faster you pump these events, the faster
animations will occur, and the more CPU will be used. Safari 2 actually
throttles these events aggressively to background windows and background
tabs._

------
iamelgringo
I don't ever recall a time when a web page that I was loading pegged my CPU. I
agree that tabbed browsing is embarrassingly parallel. But, are web pages
particularly CPU bound? If anything, it's the bandwidth that's throttling the
development issue.

The hard core javascript guys I know talk about developing interesting client
side code compare it to developing the old 8 bit computer games, and trying to
do something really cool and interesting with 64K of memory. They're trying to
do something interesting and bundle it up in 64K of code, so the download
speeds don't cause people to bounce to another site.

~~~
wmf
_I don't ever recall a time when a web page that I was loading pegged my CPU._

I see this occasionally due to browser bugs. (This is tautological, since I
define pegging the CPU as a bug.) In some sense Chrome is the first postmodern
browser: instead of trying to eliminate bugs it lets you kill -9 tabs.

------
fauigerzigerk
I'm not sure if that makes any sense. The bottleneck in terms of parallelism
on the client is me, the user. Predictably, what all those cores will do
99.999% of the time is wait for me and wait for my ISP to increase throughput.
The multi process model in chrome (that IE has as well, on a per window basis)
is meant to reduce the effects of crashes, not increase parallelism.

------
axod
I'd really question the theory that #cores will grow exponentially.

Be interesting to see some evidence that's likely to happen.

~~~
13ren
Moore's Law is exponential

If you believe it will continue, and that clock speeds won't increase, then
you get exponentially increasing #'s of cores (or some other use of silicon
estate).

An alternative scenario is that there will be no mainstream demand for more
computing power, and only niche markets will buy them. The mainstream will
favour cheap, less powerful CPU's. The rise of eeePC and clones is suggestive
of this scenario.

~~~
anewaccountname
>If you believe it will continue, and that clock speeds won't increase, then
you get exponentially increasing #'s of cores (or some other use of silicon
estate).

Only if you believe the wiring connecting the cores wouldn't explode with the
number of cores.

~~~
13ren
I think the wires would just be a single bus.

A single bus works fine for moving data to/from one of many memory locations.
Another method of using just one bus is TCP-IP packet-style communication. Of
course, there's limited bandwidth, so you want most of your computation done
within a processor, not between them.

~~~
anamax
If a single bus works for large numbers of processors, why are data centers
wired differently?

For many problems, bisection bandwidth is a key constraint.

