Memory question (dual channel)
I could do with some clarification!
I'm looking at some Corsair XMS DDR or some XMS DDR TwinX (the dual channel stuff).
The MoBo supports the latter but it is considerably more expensive. Is there a noticeable performance difference between dual channel and standard memory?
They’ll have the same CAS latency. Will be on a on an A64 3500+,with Asus A8V; I've no real plans to overclock.
More expensive memory will just about tip me over budget :eek: would it be worth it?
This is something I can not believe
Quote:
Originally Posted by BUFF
On an SPP board Dual Channel is only good for about an extra 3% anyway.
Now if I understand things correctly then what happens is that in your case it operates as 2x256 Dual Channel with an extra 256 tagged on.
This is something I can not believe and also part of the reason why I posted some time ago asking for a special "review" / test of Dual-channel motherboards .
Throughput is always restricted to the slowest point in the "network". The CPU-to-memory bandwidth on Socket-A motherboards are restricted to the CPU front-side bus bandwidth ... but the memory controller can access this memory much faster than the CPU and this spare bandwidth is supposedly available to IO devices. When the CPU and its FSB is busy, DMA could be handling some IO concurrently with this CPU-work, even if there is a lot of memory data transfers happening; and this should give real-world multi-tasking environments a big boost!
Games seems to be written very much single-threaded (I could be wrong about this) so does not gain much from dual-channel memory bandwidth, but programs which could separate out IO-intensive work from CPU-intensive work should be able to gain a lot from the dual-channel memory architecture. In addition current "benchmark" tools are written to test one component at a time, e.g. CPU-to L1 cache, CPU-to memory bandwidth, etc. Most of these synthetic tests intentionally work in a way that does not touch any other components (minimal screen updates while testing CPU, No disk IO while testing memory bandwidth, etc.) These performance tests "intentionally" miss the benefit brought by a dual-channel memory architecture!!!!
I would like to see some MPEG encoding software which leverages this dual channel architecture by using two threads to respectively read data from the source disk into a buffer (a) and write from a buffer (b) to the target file on disk, and a third thread which performs the encoding, reading from the first buffer and storing the resulting stream in the second buffer. The OS should pretty much automatically allocate DMA work to perform the IO in the background. The encoding thread will "pause" only if the buffers over or under-run.
Such a program would make a good test of a system's overall performance, stressing IO and CPU at the same time. I'm not much of a programmer myself, but maybe someone on this thread could compile such a beast <hint-hint>
The other place where dual-channel would come in handy is with paging ... if the work set is multi-threaded and the system is memory bound, then you will have a situation where some IO needs to happen to bring pages back into memory for processes to run. Actually, this is assuming Windows' kernel can schedule a runable process while another is blocked on paging ... I don't know enough of the Windows scheduler to confirm or deny this ability, but I assume a process which is being paged in will block the whole system on a single-CPU host (And I'm a Unix bigot so I am not really interested in learning more ... Windows is just for gaming in any case :wink: )
But in theory once again DMA could take care of much of the paging work in the background. In this regard DMA is almost like an extra CPU dedicated to IO ... except that it could do multiple streams in parallel and it still requires a real CPU to initiate the buffer transfer.
I would really like to see more multi-threaded programs on our desktop systems!