Chrome, multicore and embarrassing parallelism

Chrome is designed as a share-nothing process architecture where each tab is its own process. It seems like this will be a big deal as processor companies use additional cores to improve performance rather than straight speed gains. This means that Chrome's lead over other browser may grow as newer chips appear with 8, 16... 128 or more cores. I've heard many Googlers talk about the fact that the company tries to attack problems that are "embarrassingly parallelizable" -- a term that describes indexing, crawling and ranking extremely well. It meshes well with the skill sets at Google and their amazing server farm technology. Philosophically, it seems like Chrome is treating the browser as a problem which can be made "embarrassingly parallelizable" when there are at least as many cores as tabs/processes. Assuming minimal RAM and L[1|2|3] cache contention, performance shouldn't drop as long as n_tabs < n_cores. Here's the killer piece: n_tabs is limited by human mental facilities. People can only manage a finite number of tasks. n_cores is growing exponentially. Perhaps not at the rate of Moore's law, but betting against exponents is always a bad idea.