Nikos Chantziaras <[email protected]> posted [email protected], excerpted below, on Mon, 15 Dec 2008 06:47:06 +0200:
> The reason I recommend the dual core over the quad core is that > compiling isn't the primary use of a desktop PC. Application > performance is, that's why the higher speed per core of the E8400 is IMO > better. I won't disagree with you, but I will throw in my own experience going from single CPU to dual socket (before the dual-cores), now to dual dual- core socket (so four cores, total), and add another factor to think about. While it doesn't match your recommendation, it fails to match due to one specific aspect, that may or may not be a factor for the OP. A bit of history, first, going back some years to establish the foundation. The upgrade to my first Athlon, the lowest speed they offered IIRC, 500 MHz, was a very good one for me. I was extremely happy with that machine, because for the first time I could run intensive streaming, etc, say (keep in mind the era) a 300 kbps Real Video stream, and keep up both with playing the video and handling the network video stream, without a hitch! I could even drag the playing window around with the mouse (in Windows 98, IIRC), and the thing would keep playing, not a hitch! That 500 MHz Athlon was good stuff! A few years later, I upgraded, way more than doubling the CPU and with other efficiencies as well, to 1.33 GHz. I was quite disappointed with that upgrade, particularly after the great experience I'd had with the 500 MHz Athlon. I thought, way more than double the speed, it should be able to handle two of the things well that the 500 MHz machine could handle one of so well, or handle one intensive one while being able to keep up with several less intensive background tasks, say encoding a video (or now, doing the latest emerge -uDN @world) while continuing to do normal stuff on the desktop. I was wrong, it could still do only one thing at a time well. Trying to get it to do something heavy in the background while continuing to web browse or whatever in the foreground didn't really work so well, and I ended up rather disappointed in that upgrade. Living with that for a few years, I realized what I had done wrong. Yes, the thing was faster, but it was just a single CPU. I would have been better off getting a dual CPU machine, even at just a GHz or likely even at 800 MHz, than I was with the 1.33 GHz single CPU. I determined that I wasn't going to make /that/ mistake again. It was during this time that I switched from MSWindows (98) to Linux, rather than upgrading to what I quickly labeled eXPrivacy, which was a very bitter disappointment to me as I had to that point been a loyal MS user (even running the IE 4, 5, and 5.5 betas). But eXPrivacy crossed a line I simply was not going to cross, and MS very literally gave me little choice BUT Linux. Of course, now, I'm glad they gave me that push (can't thank them enough for it, actually!), but without it, I'd have likely still been an MS user today. Unfortunately, the problem was NOT just the W98 scheduler, as Linux was bumpy trying to do multiple things at once too. I really DID need a multi-CPU solution, and determined that was what my next one would be. As it turned out, my next upgrade was from ia32 to amd64, as well as from single CPU to dual CPU. I purchased a dual socket Opteron box, originally dual Opteron 242s. And yes, I had been correct in my guess. The dual Opteron, even tho I just upped the speed from my previous 1.33 GHz to the 1.6 GHz of the Opteron 242s, and only had a gig of RAM, was everything I had dreamed about in terms of properly multitasking. Even if I let the heavy multi-threaded task use all the scheduler would give it of both CPUs, it was STILL WAY WAY WAY smoother and more pleasant to work with than the single CPU. But, I DID notice one nagging problem. If for some reason something got in an infinite loop, hogging one of the CPUs, while it didn't mean no hope, reboot and get it over with, like could have with a single CPU, that old jerkiness of running the rest of the system on a single CPU came back. Having actually experienced the smoothness a dual CPU could give, the experience both under runaway thread conditions and under extreme CPU load still left something to be desired. Well, as it happens, I still have that same mobo, but I've upgraded pretty much everything else around it. I'm now running 4-way md/kernel RAID-6 for my main system (with some parts I don't need redundancy on RAID-0, for speed), and upgraded the memory to a full 8 gigs, which was nice. But the upgrade to dual dual-cores, for four cores total across two CPU sockets, was what really surprised me. Like you I /had/ thought dual- core was pretty much enough for me. After all, I run pretty much a desktop system, altho as probably all of us here it's Gentoo, which does put us in the upper 20% of the demand profile for those with desktop systems. BUT, what I found out, was that actual usability VASTLY improved! In fact, I haven't been as happy with an upgrade since that upgrade to my first 500 MHz Athlon that I started this story with! The four cores really DO make a difference, and it's MUCH MUCH bigger a difference that I would have ever expected. Now, running Gentoo, I'm sure you're familiar with compiling stuff, and possibly with trying to do something else while you do. On a single CPU single-core, yeah, there are things you can do to mitigate the effects and make it sort of work, but you definitely still notice it. On a dual- core or a dual-socket single-core, you can actually do stuff while compiling without too much of a problem, but, you do still notice it a bit. What amazes me is that with the four cores, as long as I keep memory usage under control, I can run utterly ridiculous load averages, say several hundred, while compiling the kernel, a load average of 100 per core. Yet properly tuned, /you/ /pretty/ /much/ /don't/ /even/ /notice/ /it/! Keep in mind that it's NOT the memory, as I had upgraded to the the 8 gigs RAM before I upgraded to the dual dual-cores, and it's NOT the RAID, for the same reason. Neither is it the fact that I have PORTAGE_TMPDIR pointing at tmpfs, again, because once I got the 8 gigs RAM, I was doing that back with the dual-cores too. Now, the kernel is nice to run lots of build jobs on, because those jobs do use relatively little memory. In practice, I normally run -j -l21, limiting to 21 load not because of the CPU load directly, but because of the memory most compiles require. But as I said, as long as memory usage stays reasonable (which with the 4-way striped swap, means say half a gig or less into swap, the same effect on a single-disk machine would be probably 100 MB or so into swap, maybe less), once I upgraded from a total of two cores to four, load average basically /does/ /not/ /matter/ any more. It literally ceases to be an issue. A load average of one (0.25 per core), 2 per core, 10 per core, 100 per core, doesn't matter, the desktop is still very close to as responsive as it always is. The same goes for those runaway processes I mentioned. With a single core, it was pretty much game over. You could usually quit programs and shutdown safely if you tried, but it was an exercise in patience to do so. With dual cores (either as two sockets single-core each, as I originally had on this board here, or the single socket dual-cores so common now), it's better. You can still run your stuff, sort of, and the system continues functioning well enough to shut down without too much trouble. With the four cores, a few days ago I noticed a runaway process (a kernel process, no less, inotify or whatever, watching for a changed file, only something went wrong when I deleted the file, likely because I'm running directly off of Linus' git kernels and that code likely hit a bug) on my ksysguard graph, and wondered to myself how long it had been pegging 100% on that core, since I hadn't noticed any difference in performance at all. Well, I wasn't ready to reboot at the time, and I let it run. The thing ran for well over 24-hours, unkillable because it's a kernel thread, pegging 100% on one or another of the cores (it would switch cores once in awhile), while I did my thing, uninterrupted. I eventually did reboot when I came to a convenient point to do so, mainly because I was tired of seeing that thing spiking 100% all the time, not because it affected performance. If I'd have not had the ksysguard graphing it, I'd have literally never even known! Of course, once you've seen the system handle 100 load per core without a sweat, it's little surprise that it could handle a single-thread runaway process keeping a single core pegged to 100, with the others effectively idling most of the time, or even if they had a bit of work to do some of the time. It's that experience that has me recommending something different than you. Yes, it's a desktop machine. But we DO run Gentoo, so DO put it to use once in awhile. And, having at least three cores does make a big difference over two. With two, if one drops out, either because of a runaway process or because you're compiling in the background (at -j1 so it only affects the one CPU), the remaining single core is left having to multitask everything else, and it really does show up in lowered system usability. That third core (tri-core Phenom) or go for four, really DOES make a difference, at least the way I use my machine, and the way I expect most Gentoo users will want to use it, if they can. There's desktop, and there's Gentoo desktop, and at least for a Gentoo user, that third core DOES make a difference. OTOH, I really can't see what I'd do with >4 cores ATM. As the experience above demonstrated, with four, a single core can drop out and I don't notice it. What would I do with eight, or even six? Maybe decrease the compile-time where I'm merging stuff that can parallelize sufficiently? Sure, but is it worth it? At this point, four cores is I'd say the sweat spot. Then there's memory. Seriously. make it 4 gig. You'll use it. 8 gig is nice, but honestly, the last couple gig, or even the last four, run empty a lot of the time. So 8 gig memory if you can afford it, at least for a quad-core (4 for a dual-core is almost the same as 8 for a quad-core, for a dual-core, I'd say 2 gig minimum), but do plan on getting four, or you'll be crimping the efficiency of those cores. Then there's disk. Honestly, I'd say go for a 4-spindle SATA array you can run kernel RAID on, before upping from 4 to 8 gigs RAM. A quad-core (or minimum tri-core for those going AMD who can therefore get it), 4 gig RAM, 4-way-SATA-in-kernel-RAID system, is going to be a very well balanced system, remarkably free of bottlenecks. The learning curve on kernel RAID can be a bit steep, certainly, but get a system that well balanced tuned to make use of all components well, and you /will/ notice the difference! You /will/ wonder how you ever got along without it. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
