On 07/02/2015 09:32 AM, Dan wrote:
I can buy 8x 32 Gb or 16 x 16Gb. The first option is more expensive
than the second one, but I will have only one DIMM per channel. Any
suggestions or experience with this?
I have also seen cases where one memory module per channel is faster
than two of the same modules per channel, as reported by the BIOS and/
or memtest86+. But, I can't remember a single case where I could tell
the operational difference between faster and slower memory modules of
the same capacity, even with significant differences in frequency
specifications.
Ideally, you want enough memory to hold your program and all it's data
in memory at the same time, plus whatever memory the rest of your
computer needs, plus a decent amount of "extra" memory. My experience
has been that more memory is always better than less memory, even when
the larger memory is slower.
Whenever I build a new computer, the largest, fastest memory modules are
usually hard to get and/ or expensive. So, I buy one module of 1/2 or
1/4 maximum capacity and 100% maximum speed per channel. If/ when I
decide to add memory later, I prefer to buy maximum size and speed
modules. Once the memory slots (and CPU sockets) are maxed out and
that's still not enough, it's time sell or recycle the computer.
The reality for many programs is that "all the data" is far too big to
hold in memory, so disk I/O can become the bottleneck. (The kernel uses
that "extra" memory for caching, which is vital.) The standard solution
in this case is faster drives.
You might want to spend some time benchmarking your program on whatever
computers you have available. Older, slower machines can be very
revealing. See if you can tease out the various factors -- program
size, CPU(s), core(s), memory, disk I/O, etc.. This will allow you to
make informed decisions for upgrades.
You also might want to enlist the help of a computer scientist/
programmer familiar with numerical methods and/ or the library/ package
you are using. Smarter algorithms, data structures, etc., can yield
dramatic improvements in efficiency, alleviating the need for more hardware.
David
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5595f141.2020...@holgerdanske.com
