1TB external bus-powered SSD drive with Thunderbolt?

Discussion in 'Digital Photography' started by Sandman, May 30, 2014.

  1. Sandman

    PeterN Guest

    On 6/3/2014 7:55 PM, John McWilliams wrote:
    > On 6/3/14 PDT, 7:01 AM, PeterN wrote:
    >> On 6/1/2014 10:12 PM, John McWilliams wrote:
    >>> On 6/1/14 PDT, 12:29 PM, PeterN wrote:
    >>>> On 6/1/2014 12:20 PM, Savageduck wrote:
    >>>>
    >>>> <snip>
    >>>>
    >>>>>
    >>>>> As Wile E. Coyote knows, it is best to be wary of Acme Corp. products.
    >>>>>
    >>>>
    >>>> A well known international law firm was not the least bit suspicious
    >>>> when it purchased a non-existent residential housing complex for
    >>>> several
    >>>> million dollars. The name of the property manager was Wylie Coyote.
    >>>>
    >>> Please, tell us more!
    >>>

    >> Every so often I am tempted to write a book about that. The only reason
    >> I don't is that it could embarrass the swindler's family. The swindler
    >> is long passed.

    >
    > How 'bout a Q+D version, names elided....?
    >


    His There ate too many people who know what happened and it would bring
    back painful memories to his family. His son used to work for me, and
    his brother was a client. They are all good people, who could feel hurt
    emotionally hurt.

    --
    PeterN
     
    PeterN, Jun 4, 2014
    1. Advertising

  2. Sandman

    nospam Guest

    In article <>, Sandman
    <> wrote:

    > > > > > > nospam:
    > > > > > > it does if it's i/o bound.
    > > > > >
    > > > > > Sandman:
    > > > > > Processing isn't i/o bound to the disk drive.
    > > > >
    > > > > nospam:
    > > > > it is when it's waiting on data to or from the disk drive
    > > >
    > > > Sandman:
    > > > Then it's not processing.

    > >
    > > it absolutely is processing, but starved for data so it's limited in
    > > how fast it can do it.

    >
    > If it is waiting, it is not processing. It's a binary state. It is either
    > processing data or it is not. It can't process data "slow" due to disk
    > speed, disk speed only affects the time it takes to move data into the
    > memory space it needs to be in order to be processed.
    >
    > A processor works at a given frequency, regardless of disk speed. If the
    > CPU is "waiting" for data, it is not processing data. Those are two
    > seperate tasks.


    that's nothing more than word games.

    if the processor is starved for data because something is i/o bound,
    then things are slower and the user is less productive.

    > > > Sandman:
    > > > CPU benchmarks does not include media speed.

    > >
    > > cpu benchmarks are meaningless in the real world because they ignore
    > > everything else that matters.

    >
    > That doesn't change the facts.


    it's what the facts mean that matters.

    > > > Sandman:
    > > > On the topic of photography processing, we're speaking of
    > > > processing data that is in RAM, and unless you're working with
    > > > gigapixel images, all photos you have will fit in RAM in today's
    > > > machines. There may be a delay for the data to be read from the
    > > > disk to RAM, but that's not part of processing.

    > >
    > > of course it's part of the processing.

    >
    > Incorrect.


    it's absolutely correct.

    > > you're focused on individual aspects, not the big picture.

    >
    > No, I am focused on the original question:
    >
    > John McWilliams
    > 05/30/2014 <lmabna$ulq$>
    >
    > "Are you quite sure that the speed of an external drive will
    > in fact speed up processing? Last time I looked into it, the
    > answer was no, but times change, and processing methods move
    > about as well."
    >
    > An external, or internal, drive won't "speed up processing" or "processing
    > methods", since both processing and processing methods are seperate from
    > the drive speed.


    a faster hard drive absolutely will speed things up if what's being
    done is i/o bound, which is almost always the case with photoshop.

    that's why it's generally the #1 thing adobe suggests to do after
    increasing memory, which has an upper limit depending on the design of
    the computer.

    > > > > nospam:
    > > > > which for graphics, is almost always the case. that's why faster
    > > > > hard drives speed up photoshop.
    > > >
    > > > Sandman:
    > > > You have to have very VERY large photoshop documents open in order
    > > > to make it swap RAM to disk and thus include disk speed in the
    > > > processing speed. For a normal photographer, this is never the
    > > > case. Once the file is open in Photoshop, it is in RAM and the
    > > > processing Photoshop does is not limited by, or sped up by, the
    > > > speed of the disk.

    > >
    > > incorrect.

    >
    > No, correct.


    nope.

    > > one of the best ways to speed up photoshop is use a faster hard
    > > drive, which is why many hard core photoshop users use raid arrays
    > > and more recently, ssd.

    >
    > No, you are only speeding up the time it takes Photoshop to read and write
    > the file, not to process it.
    >
    > > photoshop maintains multiple buffers in memory for speed and other
    > > reasons, which means that images will use a *lot* more memory than
    > > they might first appear.

    >
    > But Photoshop need to be pushed EXTREMELY hard in order to swap that to
    > disk. A normal photographer is never ever anywhere near that limit.


    not that hard at all to have it access the swap file.

    > > if you have a slower drive, it will affect the overall performance.

    >
    > But not processing.


    you're playing word games.
     
    nospam, Jun 4, 2014
    1. Advertising

  3. Sandman

    nospam Guest

    In article <>, Sandman
    <> wrote:

    > > > Scott Schuckert:
    > > > Yeah, no - old news. Typical factory memory configurations have
    > > > grown far faster than Photoshops memory needs. Unless you have an
    > > > ancient setup that's unnaturally short on RAM, the only thing a
    > > > fast drive will do is speed up saving files, and to a slightly
    > > > lesser extent, opening them.

    > >
    > > both of which are part of the workflow.

    >
    > But not part of the processing, which is one part of the workflow, which is
    > what takes place inside Photoshop (or Lightroom or Aperture or whatever)
    > after you have opened the file.


    it's all part of the processing. you're playing word games.

    what matters is how long it takes for the user to do what they want to
    do, not how long each individual component by itself takes.

    > > however, you're forgetting about the scratch buffers that photoshop
    > > maintains, which do *not* all fit in memory unless your image is
    > > unusually small.

    >
    > Photoshop will *only* use a scratch disk if it runs out of RAM, never
    > before. And with todays computers, Photoshop will never run out of RAM
    > while working on photos from normal photographers.


    photoshop *always* uses scratch disk for a wide variety of things.

    > I have 8GB of RAM in this iMac, which is hardly unusually large, Photoshop
    > by default only use 5GB. Without any files, PS use 152MB of RAM on my
    > system. If I open a single RAW file from my D800E, which is a 36MP photo,
    > the RAM usage comes up to a whopping 257MB. Even if we account for double
    > that RAM when adding some layer effects and whatnot, you could still open
    > 25 such images in Photoshop before you got close to the RAM limit.


    completely wrong and you have *no* way of knowing what is used by
    photoshop's internal buffers.

    photoshop has its own memory management system, so looking at the
    system's stats isn't going to tell you much of anything.

    > > you're also forgetting about memory bandwidth in getting data into
    > > the processor to calculate whatever and then back to memory when
    > > it's done. most of what photoshop does are simple calculations
    > > (e.g., adjust brightness) on a *lot* of pixels which makes it i/o
    > > bound, not cpu bound.

    >
    > But not *disk* bound. Fast RAM is *essential* to processing.


    i said i/o bound. memory is i/o.
     
    nospam, Jun 4, 2014
  4. In article <>,
    Sandman <> wrote:

    > In article <>, android wrote:
    >
    > > > > Kevin McMurtrie:
    > > > > I'd avoid LaCie too. I had a factory drive fail early on the
    > > > > first revision "5big" RAID and the only way to get it fixed
    > > > > under warranty was to return the whole thing and get a new one
    > > > > two weeks later. That's really not grasping the "no downtime"
    > > > > feature of RAID 5.
    > > >
    > > > > Amazon seems to have Thunderbolt powered SSD.
    > > >
    > > > > http://www.amazon.com/dp/B00D2YMK86
    > > > > http://www.amazon.com/dp/B009HQCARY
    > > > > http://www.amazon.com/dp/B00D4D6LJ4
    > > > > http://www.amazon.com/dp/B007FNKAYQ
    > > >
    > > > Sandman:
    > > > Yeah, but none big enough, though :/

    > >
    > > Just like earlier on the Mac groups you seem to look for things that
    > > don't exist....

    >
    > Yeah, well, I am already aware of the scarcity of devices that meet my
    > need, otherwise I wouldn't post a question online unless I knew it was hard
    > to find otherwise. Unfortunately, in many cases, it's because it *can't* be
    > found :)
    >
    > > I would, again suggest buying a USB3 enclosure and
    > > then put an SSD of your choice in it.


    So use spinning rust and don't drop it while it's running. There's at
    least a few more years before flash memory becomes cheaper than magnetic
    media.

    If you're thinking that you need SSD because you're running MacOS, then
    it's really MacOS that's the problem. The filesystem is ancient, tuned
    my morons, and is completely overwhelmed by all the junk features of the
    past few releases. Downgrade to 10.6.8 or invest some time in getting
    Linux or Windows running. Few uses see significant performance gains
    with an SSD. Databases - yes, video rendering - yes, impact resistance
    - yes, photo editing - no.
     
    Kevin McMurtrie, Jun 4, 2014
  5. Sandman

    nospam Guest

    In article <>, Kevin
    McMurtrie <> wrote:

    > > > I would, again suggest buying a USB3 enclosure and
    > > > then put an SSD of your choice in it.

    >
    > So use spinning rust and don't drop it while it's running. There's at
    > least a few more years before flash memory becomes cheaper than magnetic
    > media.


    ssd is not going to be cheaper than magnetic media for a very long
    time, if ever.

    > If you're thinking that you need SSD because you're running MacOS, then
    > it's really MacOS that's the problem. The filesystem is ancient, tuned
    > my morons, and is completely overwhelmed by all the junk features of the
    > past few releases. Downgrade to 10.6.8 or invest some time in getting
    > Linux or Windows running. Few uses see significant performance gains
    > with an SSD. Databases - yes, video rendering - yes, impact resistance
    > - yes, photo editing - no.


    nonsense. complete utter nonsense.
     
    nospam, Jun 4, 2014
  6. Sandman

    Sandman Guest

    In article <030620142113129003%>, nospam wrote:

    > > Sandman:
    > > If it is waiting, it is not processing. It's a binary state. It is
    > > either processing data or it is not. It can't process data "slow"
    > > due to disk speed, disk speed only affects the time it takes to
    > > move data into the memory space it needs to be in order to be
    > > processed.

    >
    > > A processor works at a given frequency, regardless of disk speed.
    > > If the CPU is "waiting" for data, it is not processing data. Those
    > > are two seperate tasks.

    >
    > that's nothing more than word games.


    > if the processor is starved for data because something is i/o bound,
    > then things are slower and the user is less productive.


    True - which isn't the case with digital photo processing. At no point is
    the CPU "halted" waiting for data due to a slow hard drive when post
    processing photos. When you open a photo in Photoshop, there may be a delay
    while the data is being read from disk, but at that point in time, the CPU
    isn't working with the data.

    > > > > Sandman:
    > > > > CPU benchmarks does not include media speed.
    > > >
    > > > nospam:
    > > > cpu benchmarks are meaningless in the real world because they
    > > > ignore everything else that matters.

    > >
    > > Sandman:
    > > That doesn't change the facts.

    >
    > it's what the facts mean that matters.


    Indeed.

    > > > > Sandman:
    > > > > On the topic of photography processing, we're speaking of
    > > > > processing data that is in RAM, and unless you're working with
    > > > > gigapixel images, all photos you have will fit in RAM in today's
    > > > > machines. There may be a delay for the data to be read from the
    > > > > disk to RAM, but that's not part of processing.
    > > >
    > > > nospam:
    > > > of course it's part of the processing.

    > >
    > > Sandman:
    > > Incorrect.

    >
    > it's absolutely correct.


    Incorrect. Reading data from disk is not processing, not technically, and
    not when considering a photo editing workflow. Processing takes places when
    the data is read from disk, not before.

    You may have a workflow that opens up images in Alien Skin's Exposure, adds
    a special color tone to it and returns to Lightroom. If you have a super
    slow disk you may have to wait for several seconds for the image to open in
    Exposure, and few - if any - would consider this wait to be part of them
    processing their photos.

    > > > nospam:
    > > > you're focused on individual aspects, not the big picture.

    > >
    > > Sandman:
    > > No, I am focused on the original question:

    >
    > > John McWilliams 05/30/2014 <lmabna$ulq$>

    >
    > > "Are you quite sure that the speed of an external drive will in
    > > fact speed up processing? Last time I looked into it, the answer
    > > was no, but times change, and processing methods move about as
    > > well."

    >
    > > An external, or internal, drive won't "speed up processing" or
    > > "processing methods", since both processing and processing methods
    > > are seperate from the drive speed.

    >
    > a faster hard drive absolutely will speed things up if what's being
    > done is i/o bound, which is almost always the case with photoshop.


    It is never the case with Photoshop, especially not when talking about
    common photography. All photos from professional and consumer cameras fit
    in RAM at all times.

    > that's why it's generally the #1 thing adobe suggests to do after
    > increasing memory, which has an upper limit depending on the design
    > of the computer.


    Cite from Adobe recommending getting a faster disk to speed up Photoshop
    image processing?

    > > > > > nospam:
    > > > > > which for graphics, is almost always the case.
    > > > > > that's why faster hard drives speed up photoshop.
    > > > >
    > > > > Sandman:
    > > > > You have to have very VERY large photoshop documents
    > > > > open in order to make it swap RAM to disk and thus include
    > > > > disk speed in the processing speed. For a normal photographer,
    > > > > this is never the case. Once the file is open in Photoshop, it
    > > > > is in RAM and the processing Photoshop does is not limited by,
    > > > > or sped up by, the speed of the disk.
    > > >
    > > > nospam:
    > > > incorrect.

    > >
    > > Sandman:
    > > No, correct.

    >
    > nope.


    Incorrect.

    > > > nospam:
    > > > one of the best ways to speed up photoshop is use a faster hard
    > > > drive, which is why many hard core photoshop users use raid
    > > > arrays and more recently, ssd.

    > >
    > > Sandman:
    > > No, you are only speeding up the time it takes Photoshop to read
    > > and write the file, not to process it.

    >
    > > > nospam:
    > > > photoshop maintains multiple buffers in memory for speed and
    > > > other reasons, which means that images will use a *lot* more
    > > > memory than they might first appear.

    > >
    > > Sandman:
    > > But Photoshop need to be pushed EXTREMELY hard in order to swap
    > > that to disk. A normal photographer is never ever anywhere near
    > > that limit.

    >
    > not that hard at all to have it access the swap file.


    Incorrect.

    > > > nospam:
    > > > if you have a slower drive, it will affect the overall
    > > > performance.

    > >
    > > Sandman:
    > > But not processing.

    >
    > you're playing word games.


    I.e. I am being factual. The topic was processing, not "overall
    performance". You're the one that introduced "overall performance", not me.
    I was merely taking the topic back to what I was respoding to and is thus
    talking about.

    If I say that processing won't be sped up by faster drives and you reply by
    saying that I am incorrect and that "overall performance" WILL be sped up
    with faster drives, then I am not the one playing word games.

    "Processing" is either the act of post-processing your photos on a more
    general level, or it is the act of processing data done by the CPU.

    Since there is no question that processing data by the CPU has no relation
    at all to the hard drive, I assume you want to turn this into a more
    "general processing of photos" and whether or not faster disks will speed
    that workflow up.

    While I disagree that this was the original question, I'm not sure I would
    agree that processing of photos is quicker with faster drives, unless we're
    talking about a batch-based workflow where you edit hundreds of photos the
    exact same way.

    I.e. The time it takes to read the file from disk is insignificant in
    relation to the manual processing you do in applications. If it takes a
    second ot open a photo in Photoshop and a second to save it, that's nothing
    compared to all the seconds you spend using menues, nevigating dialog boxes
    and everything else not related to actual processing. Cutting those two
    seconds down to 0.5 seconds really doesn't speed up that workflow in any
    significant way.

    Now, if you're batch-editing, then the disk speed is really important.

    --
    Sandman[.net]
     
    Sandman, Jun 4, 2014
  7. Sandman

    Sandman Guest

    In article <>, Kevin McMurtrie wrote:

    > > > android:
    > > > Just like earlier on the Mac groups you seem to look for things
    > > > that don't exist....

    > >
    > > Sandman:
    > > Yeah, well, I am already aware of the scarcity of devices that
    > > meet my need, otherwise I wouldn't post a question online unless I
    > > knew it was hard to find otherwise. Unfortunately, in many cases,
    > > it's because it *can't* be found :)

    >
    > So use spinning rust and don't drop it while it's running. There's
    > at least a few more years before flash memory becomes cheaper than
    > magnetic media.


    This isn't about price, which wasn't a parameter. I want a fast disk that
    is mobile - something mechanical media can not deliver.

    > If you're thinking that you need SSD because you're running MacOS,
    > then it's really MacOS that's the problem.


    Huh?? I want SSD because it's super-fast. That has nothing to do with MacOS
    (other than the fact that I want Thunderbolt which still is pretty much
    Mac-only. Also, superfast)

    > The filesystem is ancient, tuned my morons, and is completely overwhelmed
    > by all the junk features of the past few releases.


    Haha, talk about clueless.

    > Downgrade to 10.6.8 or invest some time in getting Linux or Windows
    > running.


    WTF? I want to use my computer, not play games or... run a SQL database.

    > Few uses see significant performance gains with an SSD.


    You just went from clueless to complete moron.

    > Databases - yes, video rendering - yes, impact resistance - yes, photo
    > editing - no.


    Who talked about any of that?


    --
    Sandman[.net]
     
    Sandman, Jun 4, 2014
  8. Sandman

    Sandman Guest

    In article <030620142113149130%>, nospam wrote:

    > In article <>, Sandman


    > > > > Scott Schuckert:
    > > > > Yeah, no - old news. Typical factory memory
    > > > > configurations have grown far faster than Photoshops memory
    > > > > needs. Unless you have an ancient setup that's unnaturally
    > > > > short on RAM, the only thing a fast drive will do is speed up
    > > > > saving files, and to a slightly lesser extent, opening them.
    > > >
    > > > nospam:
    > > > both of which are part of the workflow.

    > >
    > > Sandman:
    > > But not part of the processing, which is one part of the workflow,
    > > which is what takes place inside Photoshop (or Lightroom or
    > > Aperture or whatever) after you have opened the file.

    >
    > it's all part of the processing. you're playing word games.


    Not at all. I am talking about the question which was posed, which I pasted
    in an earlier message. It said nothing about "workflow".

    > what matters is how long it takes for the user to do what they want
    > to do, not how long each individual component by itself takes.


    I agree, but as far as I can make out - "how long it taks for the user" was
    not a parameter for the original question, especially since no one has yet
    to define how long *what* takes for the user.

    > > > nospam:
    > > > however, you're forgetting about the scratch buffers that
    > > > photoshop maintains, which do *not* all fit in memory unless
    > > > your image is unusually small.

    > >
    > > Sandman:
    > > Photoshop will *only* use a scratch disk if it runs out of RAM,
    > > never before. And with todays computers, Photoshop will never run
    > > out of RAM while working on photos from normal photographers.

    >
    > photoshop *always* uses scratch disk for a wide variety of things.


    Incorrect.

    <http://helpx.adobe.com/photoshop/kb/optimize-performance-photoshop-cs4-cs5.html>

    "Photoshop reads and writes image information to disk when there is not
    enough RAM to contain all of it."

    In short, Adobe suggests you get a faster disk only if you do not have
    enough RAM to contain your images. And with todays computers and for the
    normal photographer, that is never the case.

    > > Sandman:
    > > I have 8GB of RAM in this iMac, which is hardly unusually large,
    > > Photoshop by default only use 5GB. Without any files, PS use 152MB
    > > of RAM on my system. If I open a single RAW file from my D800E,
    > > which is a 36MP photo, the RAM usage comes up to a whopping 257MB.
    > > Even if we account for double that RAM when adding some layer
    > > effects and whatnot, you could still open 25 such images in
    > > Photoshop before you got close to the RAM limit.

    >
    > completely wrong


    No, completely right.

    > and you have *no* way of knowing what is used by
    > photoshop's internal buffers.


    True, but I can see how much RAM it is using.

    > photoshop has its own memory management system, so looking at the
    > system's stats isn't going to tell you much of anything.


    Incorrect, it tells me how much RAM Photoshop is using, which is what we're
    talking about. Photoshop is not able to use RAM that is not handeled by the
    system, regardless of whatever "own memory management system" you think it
    uses.

    > > > nospam:
    > > > you're also forgetting about memory bandwidth in getting data
    > > > into the processor to calculate whatever and then back to memory
    > > > when it's done. most of what photoshop does are simple
    > > > calculations (e.g., adjust brightness) on a *lot* of pixels
    > > > which makes it i/o bound, not cpu bound.

    > >
    > > Sandman:
    > > But not *disk* bound. Fast RAM is *essential* to processing.

    >
    > i said i/o bound. memory is i/o.


    The topic was disks. No one has claimed that RAM speed isn't important to
    processing. It is very much essential to processing.


    --
    Sandman[.net]
     
    Sandman, Jun 4, 2014
  9. In article <>,
    Sandman <> wrote:

    > In article <>, Kevin McMurtrie
    > wrote:
    >
    > > > > android:
    > > > > Just like earlier on the Mac groups you seem to look for things
    > > > > that don't exist....
    > > >
    > > > Sandman:
    > > > Yeah, well, I am already aware of the scarcity of devices that
    > > > meet my need, otherwise I wouldn't post a question online unless I
    > > > knew it was hard to find otherwise. Unfortunately, in many cases,
    > > > it's because it *can't* be found :)

    > >
    > > So use spinning rust and don't drop it while it's running. There's
    > > at least a few more years before flash memory becomes cheaper than
    > > magnetic media.

    >
    > This isn't about price, which wasn't a parameter. I want a fast disk that
    > is mobile - something mechanical media can not deliver.
    >
    > > If you're thinking that you need SSD because you're running MacOS,
    > > then it's really MacOS that's the problem.

    >
    > Huh?? I want SSD because it's super-fast. That has nothing to do with MacOS
    > (other than the fact that I want Thunderbolt which still is pretty much
    > Mac-only. Also, superfast)
    >
    > > The filesystem is ancient, tuned my morons, and is completely overwhelmed
    > > by all the junk features of the past few releases.

    >
    > Haha, talk about clueless.


    Says the fool thinking an SSD is needed for photo editing. Try running
    'fs_usage' next time your computer feels slow.

    HFS+ has poor concurrency and caching yet Apple has been completely
    overloading it with junk features - Bundles, Auto Save, Versions, Mobile
    Time Machine, Spotlight, completely broken Finder pre-caching, broken
    journaling (HFS+J), broken caching, and a mess of daemon processes that
    perform polling. As you can see from diagnostic utilities, most Apple
    apps are disabling caching to avoid bugs.

    You can fanboi all you want but it doesn't make MacOS faster. The
    feature list for the next MacOS is out and I/O performance isn't on it.
    Continue on your quest to buy extremely expensive hardware if you'd
    like. It's your time and money.


    > > Downgrade to 10.6.8 or invest some time in getting Linux or Windows
    > > running.

    >
    > WTF? I want to use my computer, not play games or... run a SQL database.
    >
    > > Few uses see significant performance gains with an SSD.

    >
    > You just went from clueless to complete moron.
    >
    > > Databases - yes, video rendering - yes, impact resistance - yes, photo
    > > editing - no.

    >
    > Who talked about any of that?
     
    Kevin McMurtrie, Jun 4, 2014
  10. Sandman

    Sandman Guest

    In article <>, Kevin McMurtrie wrote:

    > > > Kevin McMurtrie:
    > > > If you're thinking that you need SSD because you're running
    > > > MacOS, then it's really MacOS that's the problem.

    > >
    > > Sandman:
    > > Huh?? I want SSD because it's super-fast. That has nothing to do
    > > with MacOS (other than the fact that I want Thunderbolt which
    > > still is pretty much Mac-only. Also, superfast)

    >
    > > > Kevin McMurtrie:
    > > > The filesystem is ancient, tuned my morons, and is completely
    > > > overwhelmed by all the junk features of the past few releases.

    > >
    > > Sandman:
    > > Haha, talk about clueless.

    >
    > Says the fool thinking an SSD is needed for photo editing.


    I know of no such person.

    > Try running 'fs_usage' next time your computer feels slow.


    No need.

    > HFS+ has poor concurrency and caching yet Apple has been completely
    > overloading it with junk features - Bundles, Auto Save, Versions,
    > Mobile Time Machine, Spotlight, completely broken Finder
    > pre-caching, broken journaling (HFS+J), broken caching, and a mess
    > of daemon processes that perform polling.


    Now you've gone from moron to imbecile. You shouldn't talk about things you
    know nothing about.

    > As you can see from diagnostic utilities, most Apple apps are disabling
    > caching to avoid bugs.


    Incorrect.

    > You can fanboi all you want but it doesn't make MacOS faster.


    You can lie all you want, it doesn't make MacOS slower.

    > The feature list for the next MacOS is out and I/O performance isn't on
    > it. Continue on your quest to buy extremely expensive hardware if you'd
    > like. It's your time and money.


    You think SSD's are "extremeley expensive"?? Sucks to be you.


    --
    Sandman[.net]
     
    Sandman, Jun 4, 2014
  11. Sandman

    -hh Guest

    photophan wrote:
    >
    > Consumer Reports does a major survey of vehicles.


    True, but there are issues with their sampling techniques
    which limit its utility. For eample, the way that it is
    done doesn't eliminate self-selection bias. Next, because
    it is owner-based reporting, there's also inconsistencies
    between reporting threshholds. Finally, their internal
    inconsistencies in editorial content creates a potential
    conflict statistically (undue influence).

    For an example of the 2nd/3rd points, CR is very much
    of the editorial position that automobiles are mere
    appliances .. they've trashed things like a 2 seater
    sportscar for it lacking back seat or trunk, for example.
    As such, they create a bias on their readers for what
    factors are more/less important, which will invariably
    influence those customers' subsequent survey results.

    Similarly, there's certain vehicle marquees which tend to
    attract certain customer demographics and these differences
    will bias the reporting too: if you think of the detailed-
    oriented customer and car enthusiast to report on expenses,
    he'll detail $83.27 for the oil change on 23 Feb, the $2.69
    spent on windhield washer on 3 March, the $23.79 for wiper
    blades, and even the $7.89 can of Carnuba Wax...functionally,
    this is an over-report. In the meantime, Mrs. Soccer Mom
    forgets about last spring's $500 service and barely remembers
    at all the $2000 bill for when the transmission blew up, so
    this consumer demographic tends to under-report.

    FYI, the only way to fix this flaw in their surveying method
    is to have a professional researcher review the records, so as
    to provide consistency in the report threshholding criteria.


    > I've looked at it in the past, but believe you have
    > to subscribe, but I could be off on that.


    The local public library often has a magazine subscription,
    so when you really want to see what they have, you can go
    read it for free.

    ....but you can still expect to get burned with some bad
    recommendations. I'd say that our track record was around
    a 20% "Horribly Bad" advisement rate before we caught on
    (and dropped paying for a subscription).


    -hh
     
    -hh, Jun 4, 2014
  12. Sandman

    nospam Guest

    In article <>, Sandman
    <> wrote:

    > > > Sandman:
    > > > If it is waiting, it is not processing. It's a binary state. It is
    > > > either processing data or it is not. It can't process data "slow"
    > > > due to disk speed, disk speed only affects the time it takes to
    > > > move data into the memory space it needs to be in order to be
    > > > processed.

    > >
    > > > A processor works at a given frequency, regardless of disk speed.
    > > > If the CPU is "waiting" for data, it is not processing data. Those
    > > > are two seperate tasks.

    > >
    > > that's nothing more than word games.

    >
    > > if the processor is starved for data because something is i/o bound,
    > > then things are slower and the user is less productive.

    >
    > True - which isn't the case with digital photo processing. At no point is
    > the CPU "halted" waiting for data due to a slow hard drive when post
    > processing photos. When you open a photo in Photoshop, there may be a delay
    > while the data is being read from disk, but at that point in time, the CPU
    > isn't working with the data.


    the cpu absolutely is working with the data and at no point is the cpu
    halted.

    > > > > > Sandman:
    > > > > > CPU benchmarks does not include media speed.
    > > > >
    > > > > nospam:
    > > > > cpu benchmarks are meaningless in the real world because they
    > > > > ignore everything else that matters.
    > > >
    > > > Sandman:
    > > > That doesn't change the facts.

    > >
    > > it's what the facts mean that matters.

    >
    > Indeed.


    then why are you arguing?

    > > > > > Sandman:
    > > > > > On the topic of photography processing, we're speaking of
    > > > > > processing data that is in RAM, and unless you're working with
    > > > > > gigapixel images, all photos you have will fit in RAM in today's
    > > > > > machines. There may be a delay for the data to be read from the
    > > > > > disk to RAM, but that's not part of processing.
    > > > >
    > > > > nospam:
    > > > > of course it's part of the processing.
    > > >
    > > > Sandman:
    > > > Incorrect.

    > >
    > > it's absolutely correct.

    >
    > Incorrect. Reading data from disk is not processing, not technically, and
    > not when considering a photo editing workflow. Processing takes places when
    > the data is read from disk, not before.


    you're playing word games. the processor must request which blocks to
    read off the drive into memory and wait for that to complete. it also
    has to move the data from memory into its internal registers, do
    whatever calculations and write it back out.

    if the calculations are complex and the i/o is not a significant
    portion then it's cpu bound. if the calculations are simple and the i/o
    is a significant portion, then it's i/o bound. ideally you want a
    balance but that isn't always possible.

    > You may have a workflow that opens up images in Alien Skin's Exposure, adds
    > a special color tone to it and returns to Lightroom. If you have a super
    > slow disk you may have to wait for several seconds for the image to open in
    > Exposure, and few - if any - would consider this wait to be part of them
    > processing their photos.


    you have that backwards. just about everyone would consider the opening
    and closing as part of the processing. you can't process something
    which you have not yet opened.

    > > > > nospam:
    > > > > you're focused on individual aspects, not the big picture.
    > > >
    > > > Sandman:
    > > > No, I am focused on the original question:

    > >
    > > > John McWilliams 05/30/2014 <lmabna$ulq$>

    > >
    > > > "Are you quite sure that the speed of an external drive will in
    > > > fact speed up processing? Last time I looked into it, the answer
    > > > was no, but times change, and processing methods move about as
    > > > well."

    > >
    > > > An external, or internal, drive won't "speed up processing" or
    > > > "processing methods", since both processing and processing methods
    > > > are seperate from the drive speed.

    > >
    > > a faster hard drive absolutely will speed things up if what's being
    > > done is i/o bound, which is almost always the case with photoshop.

    >
    > It is never the case with Photoshop, especially not when talking about
    > common photography. All photos from professional and consumer cameras fit
    > in RAM at all times.


    the photo might but not all of the other stuff, including multiple
    buffers, cache, undo history, etc.

    > > that's why it's generally the #1 thing adobe suggests to do after
    > > increasing memory, which has an upper limit depending on the design
    > > of the computer.

    >
    > Cite from Adobe recommending getting a faster disk to speed up Photoshop
    > image processing?


    here's one:
    <http://blogs.adobe.com/crawlspace/2011/05/how-to-tune-photoshop-cs5-for-
    peak-performance.html#storage>
    When Photoshop needs more memory than that available, it uses a
    portion of the hard drive as virtual memory or scratch disks. This
    process allows you to work with large image changes that exceed the
    capacity of your system RAM. The more hard-drive space available and
    the faster the drive access speed, the more efficient this process
    becomes. As a rule of thumb, aim for hard drives with faster disk
    rotation (usually classified in RPM) and faster read/write speeds. If
    you have the budget, then take a look at SSDs. Ideally, you should
    use a dedicated, empty hard drive that is not your startup disk, but
    if empty drives are not possible, at least make sure that the free
    space on your scratch disks is not fragmented.

    > > > > > > nospam:
    > > > > > > which for graphics, is almost always the case.
    > > > > > > that's why faster hard drives speed up photoshop.
    > > > > >
    > > > > > Sandman:
    > > > > > You have to have very VERY large photoshop documents
    > > > > > open in order to make it swap RAM to disk and thus include
    > > > > > disk speed in the processing speed. For a normal photographer,
    > > > > > this is never the case. Once the file is open in Photoshop, it
    > > > > > is in RAM and the processing Photoshop does is not limited by,
    > > > > > or sped up by, the speed of the disk.
    > > > >
    > > > > nospam:
    > > > > incorrect.
    > > >
    > > > Sandman:
    > > > No, correct.

    > >
    > > nope.

    >
    > Incorrect.


    nope

    > > > > nospam:
    > > > > one of the best ways to speed up photoshop is use a faster hard
    > > > > drive, which is why many hard core photoshop users use raid
    > > > > arrays and more recently, ssd.
    > > >
    > > > Sandman:
    > > > No, you are only speeding up the time it takes Photoshop to read
    > > > and write the file, not to process it.

    > >
    > > > > nospam:
    > > > > photoshop maintains multiple buffers in memory for speed and
    > > > > other reasons, which means that images will use a *lot* more
    > > > > memory than they might first appear.
    > > >
    > > > Sandman:
    > > > But Photoshop need to be pushed EXTREMELY hard in order to swap
    > > > that to disk. A normal photographer is never ever anywhere near
    > > > that limit.

    > >
    > > not that hard at all to have it access the swap file.

    >
    > Incorrect.


    wrong. just look at what's being read and written to the hard drive.

    > > > > nospam:
    > > > > if you have a slower drive, it will affect the overall
    > > > > performance.
    > > >
    > > > Sandman:
    > > > But not processing.

    > >
    > > you're playing word games.

    >
    > I.e. I am being factual. The topic was processing, not "overall
    > performance". You're the one that introduced "overall performance", not me.
    > I was merely taking the topic back to what I was respoding to and is thus
    > talking about.


    word games.

    > If I say that processing won't be sped up by faster drives and you reply by
    > saying that I am incorrect and that "overall performance" WILL be sped up
    > with faster drives, then I am not the one playing word games.


    if something is i/o bound, which most things are these days because
    processors are ridiculously fast and memory has not kept pace, then a
    faster drive and/or faster memory can easily speed things up. on the
    other hand, if it's cpu-bound, then it won't.

    > "Processing" is either the act of post-processing your photos on a more
    > general level, or it is the act of processing data done by the CPU.
    >
    > Since there is no question that processing data by the CPU has no relation
    > at all to the hard drive, I assume you want to turn this into a more
    > "general processing of photos" and whether or not faster disks will speed
    > that workflow up.
    >
    > While I disagree that this was the original question, I'm not sure I would
    > agree that processing of photos is quicker with faster drives, unless we're
    > talking about a batch-based workflow where you edit hundreds of photos the
    > exact same way.
    >
    > I.e. The time it takes to read the file from disk is insignificant in
    > relation to the manual processing you do in applications. If it takes a
    > second ot open a photo in Photoshop and a second to save it, that's nothing
    > compared to all the seconds you spend using menues, nevigating dialog boxes
    > and everything else not related to actual processing. Cutting those two
    > seconds down to 0.5 seconds really doesn't speed up that workflow in any
    > significant way.
    >
    > Now, if you're batch-editing, then the disk speed is really important.


    it's always important.
     
    nospam, Jun 5, 2014
  13. Sandman

    nospam Guest

    In article <>, Sandman
    <> wrote:

    > > > > > Scott Schuckert:
    > > > > > Yeah, no - old news. Typical factory memory
    > > > > > configurations have grown far faster than Photoshops memory
    > > > > > needs. Unless you have an ancient setup that's unnaturally
    > > > > > short on RAM, the only thing a fast drive will do is speed up
    > > > > > saving files, and to a slightly lesser extent, opening them.
    > > > >
    > > > > nospam:
    > > > > both of which are part of the workflow.
    > > >
    > > > Sandman:
    > > > But not part of the processing, which is one part of the workflow,
    > > > which is what takes place inside Photoshop (or Lightroom or
    > > > Aperture or whatever) after you have opened the file.

    > >
    > > it's all part of the processing. you're playing word games.

    >
    > Not at all. I am talking about the question which was posed, which I pasted
    > in an earlier message. It said nothing about "workflow".


    processing speed is a key part of that.

    > > what matters is how long it takes for the user to do what they want
    > > to do, not how long each individual component by itself takes.

    >
    > I agree, but as far as I can make out - "how long it taks for the user" was
    > not a parameter for the original question, especially since no one has yet
    > to define how long *what* takes for the user.


    how long it takes for the user is the *only* parameter that matters.

    > > > > nospam:
    > > > > however, you're forgetting about the scratch buffers that
    > > > > photoshop maintains, which do *not* all fit in memory unless
    > > > > your image is unusually small.
    > > >
    > > > Sandman:
    > > > Photoshop will *only* use a scratch disk if it runs out of RAM,
    > > > never before. And with todays computers, Photoshop will never run
    > > > out of RAM while working on photos from normal photographers.

    > >
    > > photoshop *always* uses scratch disk for a wide variety of things.

    >
    > Incorrect.


    it's absolutely correct.

    just where do you think all the history states and undo caches go? kept
    in memory??

    >
    > <http://helpx.adobe.com/photoshop/kb/optimize-performance-photoshop-cs4-cs5.ht
    > ml>
    >
    > "Photoshop reads and writes image information to disk when there is not
    > enough RAM to contain all of it."


    now read a bit further.
    Each history state or snapshot in the History panel increases the
    amount of scratch disk space that Photoshop uses.  The more pixels an
    operation changes, the more scratch space the corresponding history
    state consumes.
    ....
    Undo, the Clipboard, and History states all hold image data. To free
    up RAM, choose Edit > Purge and then Undo, Clipboard, Histories, or
    All. 

    in other words, every step you do is going to hit the scratch drive.
    *everything*.

    the slower that process is, the slower it will be to complete the
    operation.

    you may not notice it for simple things like brightness, contrast, etc.
    but that doesn't mean you won't ever notice it.

    > In short, Adobe suggests you get a faster disk only if you do not have
    > enough RAM to contain your images. And with todays computers and for the
    > normal photographer, that is never the case.


    it can easily be the case.

    you are looking at only the single image size and not all of the
    associated buffers and other stuff photoshop maintains per image.

    and it's quite common to open two images (or more) at a time so now the
    memory pressure has doubled.

    good luck for panorama photographers.

    > > > Sandman:
    > > > I have 8GB of RAM in this iMac, which is hardly unusually large,
    > > > Photoshop by default only use 5GB. Without any files, PS use 152MB
    > > > of RAM on my system. If I open a single RAW file from my D800E,
    > > > which is a 36MP photo, the RAM usage comes up to a whopping 257MB.
    > > > Even if we account for double that RAM when adding some layer
    > > > effects and whatnot, you could still open 25 such images in
    > > > Photoshop before you got close to the RAM limit.

    > >
    > > completely wrong

    >
    > No, completely right.


    you were not.

    > > and you have *no* way of knowing what is used by
    > > photoshop's internal buffers.

    >
    > True, but I can see how much RAM it is using.


    not by looking at the system's activity monitor you can't, because
    photoshop has its own virtual memory system and there's no way to see
    that with the system tools.

    the way to do it is with photoshop's efficiency indicator. only then
    can you tell.

    > > photoshop has its own memory management system, so looking at the
    > > system's stats isn't going to tell you much of anything.

    >
    > Incorrect, it tells me how much RAM Photoshop is using, which is what we're
    > talking about. Photoshop is not able to use RAM that is not handeled by the
    > system, regardless of whatever "own memory management system" you think it
    > uses.


    activity monitor will *not* tell you if photoshop is using the scratch
    drive.

    photoshop has its own vm system separate from the operating system and
    specifically tuned for image processing, which is yet another reason
    why it's as fast as it is.

    > > > > nospam:
    > > > > you're also forgetting about memory bandwidth in getting data
    > > > > into the processor to calculate whatever and then back to memory
    > > > > when it's done. most of what photoshop does are simple
    > > > > calculations (e.g., adjust brightness) on a *lot* of pixels
    > > > > which makes it i/o bound, not cpu bound.
    > > >
    > > > Sandman:
    > > > But not *disk* bound. Fast RAM is *essential* to processing.

    > >
    > > i said i/o bound. memory is i/o.

    >
    > The topic was disks. No one has claimed that RAM speed isn't important to
    > processing. It is very much essential to processing.


    what i originally said was i/o bound.

    memory bandwidth is part of that but the disk is where it hurts the
    most because disks are slow.

    the fastest speeds is if the data is in the cpu registers, followed by
    cache, then memory and then the hard drive.

    today's processors are often i/o bound.
     
    nospam, Jun 5, 2014
  14. Sandman

    nospam Guest

    In article <>, -hh
    <> wrote:

    > > Consumer Reports does a major survey of vehicles.

    >
    > True, but there are issues with their sampling techniques
    > which limit its utility. For eample, the way that it is
    > done doesn't eliminate self-selection bias. Next, because
    > it is owner-based reporting, there's also inconsistencies
    > between reporting threshholds. Finally, their internal
    > inconsistencies in editorial content creates a potential
    > conflict statistically (undue influence).
    >
    > For an example of the 2nd/3rd points, CR is very much
    > of the editorial position that automobiles are mere
    > appliances .. they've trashed things like a 2 seater
    > sportscar for it lacking back seat or trunk, for example.
    > As such, they create a bias on their readers for what
    > factors are more/less important, which will invariably
    > influence those customers' subsequent survey results.


    consumer reports are a bunch of blithering idiots.

    whenever they review products i know about, it's clear they haven't any
    idea what they're doing, so i can only assume that they make similar
    mistakes on products i don't know about.
     
    nospam, Jun 5, 2014
  15. Sandman

    Sandman Guest

    In article <050620141226144281%>, nospam wrote:

    > > > > Sandman:
    > > > > If it is waiting, it is not processing. It's a binary
    > > > > state. It is either processing data or it is not. It can't
    > > > > process data "slow" due to disk speed, disk speed only affects
    > > > > the time it takes to move data into the memory space it needs
    > > > > to be in order to be processed.
    > > >
    > > > > A processor works at a given frequency, regardless of disk
    > > > > speed. If the CPU is "waiting" for data, it is not processing
    > > > > data. Those are two seperate tasks.
    > > >
    > > > nospam:
    > > > that's nothing more than word games.

    > >
    > > > if the processor is starved for data because something is i/o
    > > > bound, then things are slower and the user is less productive.

    > >
    > > Sandman:
    > > True - which isn't the case with digital photo processing. At no
    > > point is the CPU "halted" waiting for data due to a slow hard
    > > drive when post processing photos. When you open a photo in
    > > Photoshop, there may be a delay while the data is being read from
    > > disk, but at that point in time, the CPU isn't working with the
    > > data.

    >
    > the cpu absolutely is working with the data


    No, when data is being read from the disk into RAM, the CPU is not working
    with the data in terms of "photo processing".

    > and at no point is the cpu halted.


    That's what I just said.

    > > > > > > Sandman:
    > > > > > > CPU benchmarks does not include media speed.
    > > > > >
    > > > > > nospam:
    > > > > > cpu benchmarks are meaningless in the real world
    > > > > > because they ignore everything else that matters.
    > > > >
    > > > > Sandman:
    > > > > That doesn't change the facts.
    > > >
    > > > nospam:
    > > > it's what the facts mean that matters.

    > >
    > > Sandman:
    > > Indeed.

    >
    > then why are you arguing?


    I'm not. I'm just telling you the facts. No need to argue anything.

    > > > > > > Sandman:
    > > > > > > On the topic of photography processing, we're
    > > > > > > speaking of processing data that is in RAM, and unless
    > > > > > > you're working with gigapixel images, all photos you have
    > > > > > > will fit in RAM in today's machines. There may be a delay
    > > > > > > for the data to be read from the disk to RAM, but that's
    > > > > > > not part of processing.
    > > > > >
    > > > > > nospam:
    > > > > > of course it's part of the processing.
    > > > >
    > > > > Sandman:
    > > > > Incorrect.
    > > >
    > > > nospam:
    > > > it's absolutely correct.

    > >
    > > Sandman:
    > > Incorrect. Reading data from disk is not processing, not
    > > technically, and not when considering a photo editing workflow.
    > > Processing takes places when the data is read from disk, not
    > > before.

    >
    > you're playing word games.


    Incorrect.

    > the processor must request which blocks to read off the drive into memory
    > and wait for that to complete.


    Incorrect. The CPU doesn't "request blocks". When a file is being opened in
    Photoshop, the file isn't being processed by the CPU. Only when the data is
    in RAM can the CPU work with the data, so the time the I/O controller takes
    to move data from the HDD to RAM is not time where the CPU spends
    "processing data".

    > it also has to move the data from memory into its internal registers, do
    > whatever calculations and write it back out.


    True, but it can only do that when the data is in RAM, at which point the
    speed of the HDD is irrelevant.

    > if the calculations are complex and the i/o is not a significant
    > portion then it's cpu bound. if the calculations are simple and the
    > i/o is a significant portion, then it's i/o bound. ideally you want
    > a balance but that isn't always possible.


    At no point is it HDD bound, which is what was being discussed. The speed
    of RAM and the size of the RAM bus is *crucial* to processing. That has
    never been in question.

    > > Sandman:
    > > You may have a workflow that opens up images in Alien Skin's
    > > Exposure, adds a special color tone to it and returns to
    > > Lightroom. If you have a super slow disk you may have to wait for
    > > several seconds for the image to open in Exposure, and few - if
    > > any - would consider this wait to be part of them processing their
    > > photos.

    >
    > you have that backwards.


    No.

    > just about everyone would consider the opening and closing as part of the
    > processing. you can't process something which you have not yet opened.


    You're contradicting yourself. If opening a file is part of processing a
    photo - then YOU can process something you have not yet opened, since the
    act of opening is part of the processing.

    For obvious reason, I disagree. You can not process something you haven't
    opened - which means that opening the file is not part of processing the
    file, which leads to what I've been saying all along - Processing photos is
    not "slow" or "fast" depending on your drive speed.

    > > > > > nospam:
    > > > > > you're focused on individual aspects, not the big
    > > > > > picture.
    > > > >
    > > > > Sandman:
    > > > > No, I am focused on the original question:
    > > >
    > > > > John McWilliams 05/30/2014 <lmabna$ulq$>
    > > >
    > > > > "Are you quite sure that the speed of an external drive will
    > > > > in fact speed up processing? Last time I looked into it, the
    > > > > answer was no, but times change, and processing methods move
    > > > > about as well."
    > > >
    > > > > An external, or internal, drive won't "speed up processing" or
    > > > > "processing methods", since both processing and processing
    > > > > methods are seperate from the drive speed.
    > > >
    > > > nospam:
    > > > a faster hard drive absolutely will speed things up if what's
    > > > being done is i/o bound, which is almost always the case with
    > > > photoshop.

    > >
    > > Sandman:
    > > It is never the case with Photoshop, especially not when talking
    > > about common photography. All photos from professional and
    > > consumer cameras fit in RAM at all times.

    >
    > the photo might but not all of the other stuff, including multiple
    > buffers, cache, undo history, etc.


    Yes, it will. Everything Photoshop does at all times when processing normal
    photographs will fit into RAM on every computer that is at least five years
    old or newer. This is a fact.

    > > > nospam:
    > > > that's why it's generally the #1 thing adobe suggests to do
    > > > after increasing memory, which has an upper limit depending on
    > > > the design of the computer.

    > >
    > > Sandman:
    > > Cite from Adobe recommending getting a faster disk to speed up
    > > Photoshop image processing?

    >
    > here's one:
    > <http://blogs.adobe.com/crawlspace/2011/05/how-to-tune-photoshop-cs5-for-
    > peak-performance.html#storage> When Photoshop needs more memory than
    > that available, it uses a portion of the hard drive as virtual
    > memory or scratch disks.


    This is not Adobe saying that you need a faster disk to speed up image
    processing. This is Adobe saying that the scratch disk is used when
    available memory (RAM) is insufficient. As has been showed, this is *NEVER*
    the case when working with normal photos

    > > > > > > > nospam:
    > > > > > > > which for graphics, is almost always the case.
    > > > > > > > that's why faster hard drives speed up photoshop.
    > > > > > >
    > > > > > > Sandman:
    > > > > > > You have to have very VERY large photoshop
    > > > > > > documents open in order to make it swap RAM to disk and
    > > > > > > thus include disk speed in the processing speed. For a
    > > > > > > normal photographer, this is never the case. Once the file
    > > > > > > is open in Photoshop, it is in RAM and the processing
    > > > > > > Photoshop does is not limited by, or sped up by, the speed
    > > > > > > of the disk.
    > > > > >
    > > > > > nospam:
    > > > > > incorrect.
    > > > >
    > > > > Sandman:
    > > > > No, correct.
    > > >
    > > > nospam:
    > > > nope.

    > >
    > > Sandman:
    > > Incorrect.

    >
    > nope


    Still incorrect.

    > > > > > nospam:
    > > > > > one of the best ways to speed up photoshop is use a
    > > > > > faster hard drive, which is why many hard core photoshop
    > > > > > users use raid arrays and more recently, ssd.
    > > > >
    > > > > Sandman:
    > > > > No, you are only speeding up the time it takes
    > > > > Photoshop to read and write the file, not to process it.
    > > >
    > > > > > nospam:
    > > > > > photoshop maintains multiple buffers in memory for
    > > > > > speed and other reasons, which means that images will use a
    > > > > > *lot* more memory than they might first appear.
    > > > >
    > > > > Sandman:
    > > > > But Photoshop need to be pushed EXTREMELY hard in
    > > > > order to swap that to disk. A normal photographer is never
    > > > > ever anywhere near that limit.
    > > >
    > > > nospam:
    > > > not that hard at all to have it access the swap file.

    > >
    > > Sandman:
    > > Incorrect.

    >
    > wrong. just look at what's being read and written to the hard drive.


    In terms of the scratch disk - NOTHING is read and written to the hard
    drive as long as you have sufficient RAM for Photoshop to work in, which
    you always do when post processing normal photos on a modern computer.

    > > > > > nospam:
    > > > > > if you have a slower drive, it will affect the
    > > > > > overall performance.
    > > > >
    > > > > Sandman:
    > > > > But not processing.
    > > >
    > > > nospam:
    > > > you're playing word games.

    > >
    > > Sandman:
    > > I.e. I am being factual. The topic was processing, not "overall
    > > performance". You're the one that introduced "overall
    > > performance", not me. I was merely taking the topic back to what I
    > > was respoding to and is thus talking about.

    >
    > word games.


    Incorrect.

    > > Sandman:
    > > If I say that processing won't be sped up by faster drives and you
    > > reply by saying that I am incorrect and that "overall performance"
    > > WILL be sped up with faster drives, then I am not the one playing
    > > word games.

    >
    > if something is i/o bound, which most things are these days because
    > processors are ridiculously fast and memory has not kept pace, then
    > a faster drive and/or faster memory can easily speed things up. on
    > the other hand, if it's cpu-bound, then it won't.


    Then it won't, since "processing" is CPU bound, not HDD-bound. Thanks for
    agreeing.

    > > Sandman:
    > > "Processing" is either the act of post-processing your photos on a
    > > more general level, or it is the act of processing data done by
    > > the CPU.

    >
    > > Since there is no question that processing data by the CPU has no
    > > relation at all to the hard drive, I assume you want to turn this
    > > into a more "general processing of photos" and whether or not
    > > faster disks will speed that workflow up.

    >
    > > While I disagree that this was the original question, I'm not sure
    > > I would agree that processing of photos is quicker with faster
    > > drives, unless we're talking about a batch-based workflow where
    > > you edit hundreds of photos the exact same way.

    >
    > > I.e. The time it takes to read the file from disk is insignificant
    > > in relation to the manual processing you do in applications. If it
    > > takes a second ot open a photo in Photoshop and a second to save
    > > it, that's nothing compared to all the seconds you spend using
    > > menues, nevigating dialog boxes and everything else not related to
    > > actual processing. Cutting those two seconds down to 0.5 seconds
    > > really doesn't speed up that workflow in any significant way.

    >
    > > Now, if you're batch-editing, then the disk speed is really
    > > important.

    >
    > it's always important.


    Incorrect.


    --
    Sandman[.net]
     
    Sandman, Jun 5, 2014
  16. Sandman

    Sandman Guest

    In article <050620141226184531%>, nospam wrote:

    > > > > > > Scott Schuckert:
    > > > > > > Yeah, no - old news. Typical factory
    > > > > > > memory configurations have grown far faster than
    > > > > > > Photoshops memory needs. Unless you have an ancient setup
    > > > > > > that's unnaturally short on RAM, the only thing a fast
    > > > > > > drive will do is speed up saving files, and to a slightly
    > > > > > > lesser extent, opening them.
    > > > > >
    > > > > > nospam:
    > > > > > both of which are part of the workflow.
    > > > >
    > > > > Sandman:
    > > > > But not part of the processing, which is one part of
    > > > > the workflow, which is what takes place inside Photoshop (or
    > > > > Lightroom or Aperture or whatever) after you have opened the
    > > > > file.
    > > >
    > > > nospam:
    > > > it's all part of the processing. you're playing word games.

    > >
    > > Sandman:
    > > Not at all. I am talking about the question which was posed, which
    > > I pasted in an earlier message. It said nothing about "workflow".

    >
    > processing speed is a key part of that.


    Just as a monitor is a key part of it as well, but we're not talking about
    monitores either.

    The question was whether or not processing was sped up by using a faster
    hard drive, not whether a image processing workflow is sped up.

    The answer is that no - processing isn't sped up with a faster drive, and
    yes - some image workflows can be sped up with a faster drive, depending on
    the workflow.

    > > > nospam:
    > > > what matters is how long it takes for the user to do what they
    > > > want to do, not how long each individual component by itself
    > > > takes.

    > >
    > > Sandman:
    > > I agree, but as far as I can make out - "how long it taks for the
    > > user" was not a parameter for the original question, especially
    > > since no one has yet to define how long *what* takes for the user.

    >
    > how long it takes for the user is the *only* parameter that matters.


    Not to the question that was asked, it wasn't.

    > > > > > nospam:
    > > > > > however, you're forgetting about the scratch buffers
    > > > > > that photoshop maintains, which do *not* all fit in memory
    > > > > > unless your image is unusually small.
    > > > >
    > > > > Sandman:
    > > > > Photoshop will *only* use a scratch disk if it runs
    > > > > out of RAM, never before. And with todays computers, Photoshop
    > > > > will never run out of RAM while working on photos from normal
    > > > > photographers.
    > > >
    > > > nospam:
    > > > photoshop *always* uses scratch disk for a wide variety of
    > > > things.

    > >
    > > Sandman:
    > > Incorrect.

    >
    > it's absolutely correct.


    Incorrect.

    > just where do you think all the history states and undo caches go?
    > kept in memory??


    Absolutely. You can even tell yourself. Watch the Efficiency indicator,
    when it's lower than 100%, Photoshop is using the scratch disk. For normal
    photo editing, the scratch disk isn't used at all, and the efficiency level
    is always 100%

    Also, when it DOES swap out image history states to disk, it does so in the
    background and it doesn't interfere with the actual image processing which
    is all kept in RAM. Only if you decide to undo 20 times would you possibly
    have to read data from the disk.

    > > Sandman:
    > > <http://helpx.adobe.com/photoshop/kb/optimize-performance-photoshop-cs4-cs5.ht
    > > ml>

    >
    > > "Photoshop reads and writes image information to disk when there
    > > is not enough RAM to contain all of it."

    >
    > now read a bit further. Each history state or snapshot in the
    > History panel increases the amount of scratch disk space that
    > Photoshop uses.


    Only if it can't keep it in RAM. Many image states take very little space.
    Plus - this has nothing to do with image processing, only with the ability
    to undo image processing. All image data you are currently working with is
    kept in RAM.

    > in other words, every step you do is going to hit the scratch drive.
    > *everything*.


    Incorrect. As I said, you can check this out yourself.

    > the slower that process is, the slower it will be to complete the
    > operation.


    Incorrect. Swapping out a history state to disk has no effect on the
    current image processing. It is done in the background and not when i/o is
    being used.

    If you're at 100% efficiency, and use a pixel-level filter on a 36MB TIFF
    file, the image processing takes X amount of CPU cycles, which reads and
    writes to RAM. When done, the history buffer *may* need to be written to
    disk, but this has no effect on the cycles for the CPU for the actual image
    processing.

    > you may not notice it for simple things like brightness, contrast,
    > etc. but that doesn't mean you won't ever notice it.


    In terms of image processing, you will never notice it. As I said, history
    states that are written to disk will only make something slower at the
    point where you want to access that history state (i.e. hit undo).

    Try it yourself. I just opened a 36MP RAW file in Photoshop on my 4 year
    old iMac with 8GB of RAM, while having a slew of other applications open. I
    cut and moved parts of the image around and hit 95% of efficiency when I
    had done so 14 times.

    I then reverted back to the original state and ran the "Accented Edges"
    filter, which is a pixel filter, I ran it 20 times, so I have 20 versions
    of the 36MP image in the history, the efficiency was at 100% during the
    entire time.

    As I said - normal processing of normal photos will NEVER EVER use the
    scratch disk on a modern computer. It is not a problem.

    > > Sandman:
    > > In short, Adobe suggests you get a faster disk only if you do not
    > > have enough RAM to contain your images. And with todays computers
    > > and for the normal photographer, that is never the case.

    >
    > it can easily be the case.


    Incorrect. Try it for yourself.

    > you are looking at only the single image size and not all of the
    > associated buffers and other stuff photoshop maintains per image.


    Incorrect, I am looking at all data Photoshop manages.

    > and it's quite common to open two images (or more) at a time so now
    > the memory pressure has doubled.


    Indeed. I just opened 40 36MP images in Photoshop, on my 8GB system.
    Photoshop is now using 2GB of RAM for these photos.

    On these 40 photos, I ran a batch command that ran the Vignette action on
    all photos, adding 5 history states to each and every image and two new
    layers to each image.

    Efficiency: 100%, RAM usage: 3.45GB

    > good luck for panorama photographers.


    As you can see above, panorama photographers would have no problem what so
    ever.

    Again, try this for yourself and you'll see. At no point when opening 40
    36MP raw files, and running a batch on them did Photoshop use the scratch
    disk.

    > > > > Sandman:
    > > > > I have 8GB of RAM in this iMac, which is hardly
    > > > > unusually large, Photoshop by default only use 5GB. Without
    > > > > any files, PS use 152MB of RAM on my system. If I open a
    > > > > single RAW file from my D800E, which is a 36MP photo, the RAM
    > > > > usage comes up to a whopping 257MB. Even if we account for
    > > > > double that RAM when adding some layer effects and whatnot,
    > > > > you could still open 25 such images in Photoshop before you
    > > > > got close to the RAM limit.
    > > >
    > > > nospam:
    > > > completely wrong

    > >
    > > Sandman:
    > > No, completely right.

    >
    > you were not.


    I was. Just arguing doesn't change reality.

    > > > nospam:
    > > > and you have *no* way of knowing what is used by photoshop's
    > > > internal buffers.

    > >
    > > Sandman:
    > > True, but I can see how much RAM it is using.

    >
    > not by looking at the system's activity monitor you can't


    Yes, I can.

    > because photoshop has its own virtual memory system and there's no way to
    > see that with the system tools.


    Photoshop's virtual memory is its scratch disk, which I also can see how
    much is being used. I can thus see exactly how much memory Photoshop is
    using at all times.

    > the way to do it is with photoshop's efficiency indicator. only then
    > can you tell.


    That's what I've been telling you. Photoshop will NEVER use the scratch
    disk unless RAM runs out. So by knowing its RAM limit (Settings ->
    Performace) and see how much RAM it is currently using, you can see whether
    or not it is using the scratch disk. To make sure, check the efficiency
    indicator.

    > > > nospam:
    > > > photoshop has its own memory management system, so looking at
    > > > the system's stats isn't going to tell you much of anything.

    > >
    > > Sandman:
    > > Incorrect, it tells me how much RAM Photoshop is using, which is
    > > what we're talking about. Photoshop is not able to use RAM that is
    > > not handeled by the system, regardless of whatever "own memory
    > > management system" you think it uses.

    >
    > activity monitor will *not* tell you if photoshop is using the
    > scratch drive.


    I never said it did.

    > photoshop has its own vm system separate from the operating system
    > and specifically tuned for image processing, which is yet another
    > reason why it's as fast as it is.


    Which wasn't being used in the aforementioned scenario, so it's irrelevant.

    > > > > > nospam:
    > > > > > you're also forgetting about memory bandwidth in
    > > > > > getting data into the processor to calculate whatever and
    > > > > > then back to memory when it's done. most of what photoshop
    > > > > > does are simple calculations (e.g., adjust brightness) on a
    > > > > > *lot* of pixels which makes it i/o bound, not cpu bound.
    > > > >
    > > > > Sandman:
    > > > > But not *disk* bound. Fast RAM is *essential* to
    > > > > processing.
    > > >
    > > > nospam:
    > > > i said i/o bound. memory is i/o.

    > >
    > > Sandman:
    > > The topic was disks. No one has claimed that RAM speed isn't
    > > important to processing. It is very much essential to processing.

    >
    > what i originally said was i/o bound.


    What you originally said is unimportant, you joined a thread that talked
    about hard drive speed. If you wanted to talk about RAM speed, perhaps you
    should start a thread about that instead of talking about it in a thread
    about disk speed?

    > memory bandwidth is part of that but the disk is where it hurts the
    > most because disks are slow.


    Slow disks doesn't affect CPU processing speed.

    > the fastest speeds is if the data is in the cpu registers, followed
    > by cache, then memory and then the hard drive.


    The CPU can not access data on the hard drive, only data in RAM.

    > today's processors are often i/o bound.


    It's been that way always. Or rather, it moves back and forth in cycles,
    sometimes RAM is faster, sometimes CPU is faster.

    --
    Sandman[.net]
     
    Sandman, Jun 5, 2014
  17. In article <>,
    Sandman <> wrote:

    > In article <>, Kevin McMurtrie
    > wrote:
    >
    > > > > Kevin McMurtrie:
    > > > > If you're thinking that you need SSD because you're running
    > > > > MacOS, then it's really MacOS that's the problem.
    > > >
    > > > Sandman:
    > > > Huh?? I want SSD because it's super-fast. That has nothing to do
    > > > with MacOS (other than the fact that I want Thunderbolt which
    > > > still is pretty much Mac-only. Also, superfast)

    > >
    > > > > Kevin McMurtrie:
    > > > > The filesystem is ancient, tuned my morons, and is completely
    > > > > overwhelmed by all the junk features of the past few releases.
    > > >
    > > > Sandman:
    > > > Haha, talk about clueless.

    > >
    > > Says the fool thinking an SSD is needed for photo editing.

    >
    > I know of no such person.
    >
    > > Try running 'fs_usage' next time your computer feels slow.

    >
    > No need.
    >
    > > HFS+ has poor concurrency and caching yet Apple has been completely
    > > overloading it with junk features - Bundles, Auto Save, Versions,
    > > Mobile Time Machine, Spotlight, completely broken Finder
    > > pre-caching, broken journaling (HFS+J), broken caching, and a mess
    > > of daemon processes that perform polling.

    >
    > Now you've gone from moron to imbecile. You shouldn't talk about things you
    > know nothing about.



    Actually, I'm a software developer. You're a troll in a digital
    photography newsgroup looking for an SSD drive of possibly non-existent
    specifications. Did you know that spinning rust provides about
    180MB/sec of throughput?


    > > As you can see from diagnostic utilities, most Apple apps are disabling
    > > caching to avoid bugs.

    >
    > Incorrect.
    >
    > > You can fanboi all you want but it doesn't make MacOS faster.

    >
    > You can lie all you want, it doesn't make MacOS slower.
    >
    > > The feature list for the next MacOS is out and I/O performance isn't on
    > > it. Continue on your quest to buy extremely expensive hardware if you'd
    > > like. It's your time and money.

    >
    > You think SSD's are "extremeley expensive"?? Sucks to be you.
     
    Kevin McMurtrie, Jun 6, 2014
  18. Sandman

    Sandman Guest

    In article <>, Kevin McMurtrie wrote:

    > > > Kevin McMurtrie:
    > > > HFS+ has poor concurrency and caching yet Apple has been
    > > > completely overloading it with junk features - Bundles, Auto
    > > > Save, Versions, Mobile Time Machine, Spotlight, completely
    > > > broken Finder pre-caching, broken journaling (HFS+J), broken
    > > > caching, and a mess of daemon processes that perform polling.

    > >
    > > Sandman:
    > > Now you've gone from moron to imbecile. You shouldn't talk about
    > > things you know nothing about.

    >
    > Actually, I'm a software developer.


    As am I.

    > You're a troll in a digital photography newsgroup looking for an SSD
    > drive of possibly non-existent specifications.


    Haha! Did I mention that you're clueless? I've already provided the parts I
    need for such a drive.

    > Did you know that spinning rust provides about 180MB/sec of throughput?


    Did you know that I wanted more throughput than that, given the initial
    requirements I provided? Of course not.



    --
    Sandman[.net]
     
    Sandman, Jun 6, 2014
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dragon

    Thunderbolt R3 with english Dubbed

    Dragon, Apr 12, 2004, in forum: DVD Video
    Replies:
    3
    Views:
    542
    Dragon
    Apr 13, 2004
  2. Cass

    High capacity Bus powered USB Harddrives

    Cass, Sep 8, 2004, in forum: Computer Information
    Replies:
    1
    Views:
    472
  3. LoXodonte

    Address Bus and External Data Bus Confusion

    LoXodonte, Apr 6, 2006, in forum: A+ Certification
    Replies:
    1
    Views:
    2,873
    LoXodonte
    Apr 18, 2006
  4. Sir To You

    Seagate 1TB drive problems

    Sir To You, Jan 15, 2009, in forum: NZ Computing
    Replies:
    43
    Views:
    6,490
    ~misfit~
    Jan 26, 2009
  5. Becky

    Intel SSD 910 PCI Express SSD Performance

    Becky, May 4, 2012, in forum: Front Page News
    Replies:
    0
    Views:
    1,190
    Becky
    May 4, 2012
Loading...

Share This Page