Definitely, run 8 @ 800; memory speed is
vastly overrated (to the great finacial benefit of the memory companies -
especially since the advent of the 1156/1366 platforms), and the
only place it really shows up (unless you transcode a lot of video) is in 'synthetic' benchmarking - and that's
why it's called
synthetic - it doesn't relate to the real world. What matters in the real world is latency, as your system is almost never doing long sustained reads/writes from/to main memory... The speed-up from hardly ever swapping (which, think about it - involves a
mechanical transaction) will
far outweigh any benefit from higher raw memory clock speed!
(From a previous post...)
Quote:
...people often misunderstand the actual quantitative speed improvements inherent in faster ram... Here's the mistake: 1066 is 33% higher than 800 ([1066-800]/800 = 266/800 = .33), so 1066 RAM must be a third faster than 800, right? Not so! You have to figure in latencies. Most 800 will run at 4-4-4-12, while most 1066 is rated at 5-5-5-15, or, even worse, 5-5-5-18. Here's how to appraise the situation in reality: at 800 MHz, a RAM bus cycle is 1.25 nSec long (1000/800); at 1066 (1000/1066), it is roughly .938 nSec long - so, with an 800 stick at a 4 average latency, a RAM bus transaction takes 1.25 (cycle time) times 4 (latency), or 5nSec, while at 1066 it is .938 (cycle time) times 5 (latency), for a transaction time of (roughly) 4.7nSec - so you see, by going to nominally 33% faster RAM, you actually gain three tenths of a nSec per transaction: .3 (transaction gain) over 5(transaction total) = .06, for a real-world improvement of 6%...
(...from another...)
"There
is a place where high speed, versus low latency,
will be an advantage - any operations that require large, sustained, reads from and writes to RAM - like, as I mentioned, video transcoding... I always consider my 'pass/fail' system stress test to be: watch/pause one HDTV stream off a networked ATSC tuner, while recording a second stream off a PCI NTSC tuner, while transcoding and 'de-commercialing' a third stream to an NAS media server... But, for the
vast majority of people, for the
vast majority of use, this is
not the case. What's going on
behind the scenes: the task scheduler is scurrying around, busier than a centipede learning to tap-dance, counting 'ticks': ...tick... yo - over there, you gotta finish up, your tick is
over, push your environment, that's a good fella; oops - cache snoops says we've got an incoherency - grab me a meg for him from over there; ...tick... you - get me the address of the block being used by {F92BFB9B-59E9-4B65-8AA3-D004C26BA193}, will 'ya; yeah - UAC
says he has permission - I dunno - we'll just
have to trust him; damnit -
everybody listen up, we've got a pending interrupt request, everyone drop what you're doing, and you - over there - query interrupt handler for a vector - this is important!!! ...tick.... This is why (aside from the obvious matter of access architecture) that swap files are optimized in 4k 'chunks'... And the most fascinating (scary) thing about it all, is that, at some synaptic, neural level, we're doin' the same thing! (...though, the older I get, the less dependable my interrupt return mechanism is - I repeatedly find myself at the bottom of the basement steps, wondering "now what did I come down here for?!" )