4 ms·
A lot of desktop applications aren't well suited for multi-core use. They have been written for a long time as single-threaded applications and making them mul
by Periodic 16y ago
A lot of desktop applications aren't well suited for multi-core use. They have been written for a long time as single-threaded applications and making them multi-threaded is a huge task for a small gain. Some applications get worse when first made to use multiple cores and it takes a lot of tweaking and rewriting to get performance back to where it was.
2-8 cores on the desktop hasn't made a huge dent. 50-cores is a bit extreme. It's going to thrive in the server market where one system is typically servicing many requests from many users. Desktops are generally designed to only service one user.
- rbanffy 16y agoIs it really that small a gain? I am now with 6 open tabs in Firefox, one terminal with four tabs, a music player decoding an internet radio stream, an E-mail client and Emacs with two windows open and a Python process running in it. There is also a desktop CouchDB running somewhere (and that's a highly parallelizable animal) that deals with lots of the data my system generates. If for nothing else, having more cores would prevent context switches on the two cores I have. Sadly, it's no surprise much software isn't designed for multiprocessors. Prior to Windows XP taking over Windows 9x as the dominant OS for desktops, it would make no sense to develop a mainstream x86 designed for multi-threading apps - just consider the failure of the Pentium Pro (designed to run 32 bit apps in a 16-bit era). Processors and programs have been optimized for so long to cope with mono-threading OSs that it will take a while to get rid of this legacy and to step into this parallel future. There is a good reason why most desktop software is not a good fit with parallel processors - until recently there were few desktop 4+ thread machines. This is what I mean when I say Microsoft held back the PC's evolution for a decade. I used 64-bit processors (Alpha) and multi-processor desktop machines (MIPS, PPC and SPARC) years before similarly equipped PCs appeared in the market.
- queensnake 16y ago| I am now with 6 open tabs in Firefox, one terminal with four tabs, a music player decoding an internet radio stream, an E-mail client and Emacs with two windows open and a Python process running in it. Only two of those 'normal' activities consume cycles. Your CouchDB may be parallel, but that's not a typical desktop job. The truths are a) most desktop use is over-covered by current, single or dual CPUs b) you can't convert all sequential apps to parallel, as earnestly as Intel and AMD might wish for it. That is, until there are radical agents acting on your behalf, sussing out interesting things on the internet for you and whatever, but those would probably run in a cloud somewhere anyway. Of course this will be proved wrong in time but, I don't think that current desktop apps, /just written for parallel/, will ever use 50 cores.
- deleted 16y ago[deleted]
- rbanffy 16y agoI agree most desktop needs are very well served by current processors, but we can look further down the road. The only reason there are very few active threads on my desktop is that its processor cannot deal with more than two active threads. Making applications more parallel than that is pointless - it would only increase management overhead. Still, pretty little of my desktop workload is inherently serial (and most of what is serial is that way because of some implementation flaw). It's a chicken-and-egg problem. SMP did not receive much attention from mainstream processor manufacturers until OSs that could use it became common, and, even then, x86s are heavily optimized for single-thread performance because they have to run software that was developed before SMP became commonplace. Build a 16-thread ARM to compete (price, power envelope) with an Atom and you'll see people optimizing for 16 threads instead of two.