CCL: Effect of using SSD for scratch
- From: Essam Metwally <Essam.Metwally||certara.com>
- Subject: CCL: Effect of using SSD for scratch
- Date: Tue, 24 Apr 2012 22:15:10 -0500
Sent to CCL by: Essam Metwally [Essam.Metwally],[certara.com]
There are many reviews of the topic of SSD vs HDD. A recent comparison
between the two is available at the following link.
http://www.tomshardware.com/reviews/ssd-review-benchmark,3139-6.html
As you can see there, the I/O is definitely the bottleneck. You can see
by the charts that you will be well served using a SSD for a scratch file.
And you are looking at approximately 85% increase in speed by shifting to
a SSD...
HOWEVER
I have not done the comparison with SSD, but I can offer my own
comparisons between a RAM disk and a high end hard drive. I have achieved
speed increases between 100x and 1000x just by shifting to a RAM disk. For
an SSD ,if you carry the 85% increase in speed, you are looking at 15x to
150x (I would hazard the numbers are far better than that but I'm not in
the mood to benchmark it...My SSD is in another machine)
The practicality of such an approach will always be application specific.
Basically, can you create a large enough drive to be useful for your
particular application? Do you have enough memory to support the
simultaneous use of memory for both storage and application?
A point for consideration, I just picked up 16GB for a MacBook Pro for
~$130. 32GB of DDR3 can be had for ~250... Memory is far cheaper than it
used to be but SSD's are still cheaper than memory... Mac is not an ideal
platform for RAM disks (On mac they are cached by the unified buffer,
meaning that in some instances you need at least double the RAM of the RAM
disk... Ie for a fully used 8GB ram disk you need minimally 16GB of memory
or you trigger paging out to disk... Self-defeating). I digress...
In terms of speed for a SATA 6 configuration you are looking at a max of
600MB/s speed vs RAM at ~6000MB/s (the former is burst speed, the later is
sequential, not just a burst)
And this is not restricted to read and write speeds, you measure memory
latency in nanoseconds vs 10s to 100s of microseconds for a SSD. This
translates into finding what you need that much faster... And lets face
it, with processors as fast as they are, it will make a huge difference.
This is particularly germane to GPU computing...
In short, MEMORY IS CHEAP. When you are talking about a scratch file, and
you accept the caveat that the contents of such a disk will not survive a
crash, then this is absolutely the way to go.
--
Essam
---------------------------
Dr Essam Metwally
Senior Fellow
Tripos International
A Certara Company
essam.metwally]_[certara.com
Tel +314 662 2868
---------------------------
On 4/24/12 14:42, "John McKelvey jmmckel[]gmail.com"
<owner-chemistry]_[ccl.net> wrote:
>
>Sent to CCL by: John McKelvey [jmmckel#gmail.com]
>CCLers
>
>I am looking to buy a machine sort of specific for running
>Hartree-Fock and DFT codes. There is always the issue of cpu speed,
>but for large systems disk-io can be a significant issue, even for the
>usual scratch file. Has anyone done any direct or reasonable indirect
>evaluations around this issue?
>
>Many thanks,
>
>John
>
>
>
>--
>John McKelvey
>10819 Middleford Pl
>Ft Wayne, IN 46818
>260-489-2160
>jmmckel^^^gmail.com>
>
_________________________________________________________________
NOTICE: The information contained in this electronic mail message is intended
only for the personal and confidential use of the designated recipient(s) named
above. This message may be an attorney-client communication, may be protected by
the work product doctrine, and may be subject to a protective order. As such,
this message is privileged and confidential. If the reader of this message is
not the intended recipient or an agent responsible for delivering it to the
intended recipient, you are hereby notified that you have received this message
in error and that any review, dissemination, distribution, or copying of this
message is strictly prohibited. If you have received this communication in
error, please notify us immediately by telephone and e-mail and destroy any and
all copies of this message in your possession (whether hard copies or
electronically stored copies). Thank you.