[gentoo-amd64] Re: hardware choice

[Duncan]

Nikos Chantziaras <realnc@×××××.de> posted gi4ng7$6qp$1@×××××××××.org,
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