Re: W2K RAMlimits

[Robert L Krawitz <rlk@alum.mit.edu>]

   From: "Laurie Solomon" <laurie@advancenet.net>
   Date: Fri, 14 Jun 2002 21:33:15 -0500

   >is the issue that there's no way to create a RAM drive in Windows, or
   Photoshop
   >will detect that and flat out refuse to use it?  If the former
   >(there's no RAM filesystem driver) it makes sense; it would be very
   >unpleasant to do with user-mode code, and Adobe's not in the
   >filesystem business.  If the latter -- i. e. it's possible to create a
   >RAM-based filesystem -- and Photoshop will refuse to use it for its
   >swapfile, this seems rather contrary of it.

   It is primarily the latter.  Photoshop generally refuses to use RAM for
   certain operations and will only use itsown virtual memory for those
   operations which it gets by swaping memory to and from the designated
   scratch disks.  In Windows one can crate a RAM disk and designate it as a
   scratch disk which Photoshop in all probability will use as a source for its
   virtual memory.

If that's true, then Photoshop would have no trouble using a RAM disk
for this purpose.
		    
		    However, one runs into some practical problems such as
   enough actual physical RAM to support the operating system functioning as
   well as Photoshop's working operational overhead in addition to that needed
   for the RAM disk which has to be from 3-5 times the size of the largest
   image file that is to be worked on.

So a 1 GB image would require on the order of 8 GB of RAM (~3 GB for
the OS and application and 5 GB scratch space).  This doesn't seem
unreasonable.  At least some x86 processors can access up to 64 GB of
physical memory (an individual address space still has a 4 GB limit).
					
					One could also face the
   practical problem of sometimes needing to access both RAM and the
   RAM disk simultaneously for different purposes and operations,
   which might result in having to alternate between accessing the RAM
   and the RAM disk which will then slow down the system to the point
   that one has not gained anything by creating and using the RAM disk
   as a scratch disk.

Even with that (*particularly* with that), it would still be a lot
faster than a rotating disk drive.  Memory is random access; it
doesn't have to "seek" the way the head on a disk drive does.  If you
have to read 1 GB into memory, even the fastest single disk drive
(currently) will take about 20 seconds *best* case, with all of the
data located in access order at the outer edge of the drive.  If the
data isn't located at the outside edge of the drive, the performance
will be somewhat less; if it's near the inner edge of even a very fast
drive (where there are fewer bits per track) will be closer to 20
MB/sec (50 seconds).  That assumes you're just reading the data in; if
you're not reading it in order (so that the disk can't stream the
data, but has to skip back and forth), or the read is being
interrupted to do some processing (which will also force the read to
interrupt, and wait for the drive to rotate back around), performance
will drop through the floor in a hurry.  Pure sequential I/O can be
sped up by some RAID setups, but that won't help random access, which
are limited by the access time (~10 ms); the transfer rate (bandwidth)
plays essentially no role in that case.

With memory, you can skip back and forth like that without difficulty.
With my modest (by the most up to date standards) setup of an AMD XP
1700+ with DDR-266 memory, the memory copy bandwidth -- memory to
memory, being careful to overflow cache so that it won't get any
benefit from the cache -- is about 600 MB/sec.  Assuming that
Photoshop is careful to page align buffers (which should be no big
deal at all) and the OS kernel is intelligent about minimizing copies,
and filesystem overhead is low, it's possible to read the same 1 GB
file in about 1.7 seconds.  What's more, seeking around in the file
won't hurt the performance much, assuming that you're reading
page-size (4K) or bigger chunks.

-- 
Robert Krawitz <rlk@alum.mit.edu>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@uunet.uu.net
Project lead for Gimp Print/stp --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
-
Turn off HTML mail features. Keep quoted material short. Use accurate
subject lines. http://www.leben.com/lists for list instructions.