Yes, I am quit sure. There are very few opportunities to multithread a web application on the client (extensions like web workers help somehow, but are still situational). And sure, you can run every tab on its own core — but this is quite pointless, given that usually only one tab is visible and thus only one really requires computational resources.
Not really. Think on a Facebook, a Gmail and a Netflix tab. It's not about visibility, but doing updates even when they're hidden. You can see notifications of new messages on the tab's title while you watch Netflix in another tab. A Java applet could run your home broker's app in another tab while Disqus is refreshing comments in another tab even when you're not looking at it. Scheduling these tasks between cores seem easier than doing all of them in a single core. Don't know why a multicore architecture can't help improving the user experience at this scenario.
In addition, the average UI-based application is essentially single threaded. The execution model is based around very long periods of waiting, with brief bursts of activity to accommodate the user request. Because event processing, controller logic and view updates are usually done on one thread, you need a CPU that can very quickly power up to its maximal P-state, perform the useful work (often coalesced) and then power down such as quick as possible to conserve power.
Still don't know why iPad Air2-class speed (that is, it's already faster than a 2010 Core 2 Duo according to Geekbench) can't suit the average user needs - with the advantage of reaching way higher speeds when paralellism is explored by the application.
Multiprocessing ability is of course important to ensure smooth operation, but having two hardware threads is usually enough for a contemporary desktop OS. The important realisation (continued from what I said above) is that the usual multiprocessing pattern is very asymmetrical. You have one high-priority thread (usually the one that has to react to user's action) and then a number of lower-priority service threads that either serve data or spend most of their time waiting for something (such as your AJAX response). Often, the most efficient way is to schedule the high-priority thread on one core and the background ones on the second core. This is true for any kind of everyday application that comes to my mind: browsing, office, email (sure, you'd want to fetch you mails on a background thread — but that is an extremely low-priority operation which mostly consists of idle waiting on server response).
Well, a Pentium 4 (perhaps a III) with the help of 8GB of RAM and a PCIe SSD would be enough to execute these tasks at decent speeds with the bonus of having other cores for loading previews or rendering internal panels if needed.
Highly parallel designs, such as groups of weaker ARM cores, only become an advantage if you are dealing with symmetrical multiprocessing patterns. Ideally, you want to subdivide the task in N equal portions, where N is the number of your CPUs. But very few everyday computing tasks exhibit this character. This is commonly the case with image processing, and — yes — real-time audio processing
Fourier transforms are easily parallelizable, so you can load up those additional cores with some useful work.
Ok, real time, frequency domain stuff can be parallelized, but in time domain not really, since you work with a fixed, arbitrary window which can't be splitted into smaller subsamples. Otherwise you would lose information and affect the quality of the filter. Also, latency is important, so you want the best single core performance. Legacy plugins are also single core, so you would need a faster core to get acceptable performance.
In comparison, there is not much chance you can parallelize word processing...
Word processing you mean Office stuff like MS Word? I can imagine multitasking here producing grammar correction, summarization, and other inimaginable natural language processing tasks. Maybe this isn't just feasible on a dual core architecture.
There is a good reason why a dual-core Intel CPU outperforms a hexa-core AMD one in games.
This can only be explained by legacy A.I. and graphics frameworks. Let's say you have a poor iGPU and the graphics stuff needs help from the CPU. If it could make use of a lot of cores, of course it would run faster if the sum of speeds surpassed a single core one.
In short, we have to go ahead even if legacy software pushes technology to obsolete standards.
