RE: W2K RAMlimits

["Laurie Solomon" <laurie@advancenet.net>]

Bob,
Unfortunately, much of what you are saying is going over my head with
respect to details so you might as well be arguing with a wall as to discuss
memory bandwidth specs with me. :-)

I was only noting that (A) Photoshop cannot use straight RAM fo its scratch
disk but needs to have that RAM in the form of a RAM disk with an assigned
drive letter to be able to use it, (B) in certain cases involving single or
multiple medium and large size image files that need to be kept open and
used at the same time or work that involves multiple levels and channels,
numerious actions, and the like most people and systems do not have and are
not capable of using the sorts of RAM ( in terms of quantity) that may be
required to set aside RAM for a Ram Disk of the necessary size and still
have RAM available for other system operations, and (C) that the
simultaneous need to use RAM and the RAM disk has been suggested to be on of
the limiting factors in obtaining efficient uses of a RAM disk with
Photoshop.  This latter statement (C) is not mine but one which I was merely
conveying as having heard.

>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).

While CPUs may or may not be able to access up to 64GB, I do not think that
there are any consumer workstations or servers out there with motherboards
that can provide the memory chip slots or BIOSs to handle it. There may be
some motherboards out there and may be some that have recently come on the
market; but most that I know of can accommodate 4 GB of RAM total at most
unless we are talking some large server.  I also have not seen any RAM chips
that are larger than 1 GB on the market although they may be out there at a
price and via special order.

-----Original Message-----
From: owner-epson-inkjet@leben.com
[mailto:owner-epson-inkjet@leben.com]On Behalf Of Robert L Krawitz
Sent: Saturday, June 15, 2002 7:37 AM
To: epson-inkjet@leben.com
Cc: epson-inkjet@leben.com
Subject: Re: W2K RAMlimits


   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.



					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.

-
Turn off HTML mail features. Keep quoted material short. Use accurate
subject lines. http://www.leben.com/lists for list instructions.