Loading ...
Sorry, an error occurred while loading the content.

Re: PTgui -- why doesnt it just use RAM?

Expand Messages
  • matt_nolan_uaf
    I created a RAM disk using http://www.ramdisk.tk/, changed my scratch disk and write disk to the ram disk, and ran Milko s speed test and got exactly the same
    Message 1 of 19 , Dec 2, 2007
    • 0 Attachment
      I created a RAM disk using http://www.ramdisk.tk/, changed my scratch
      disk and write disk to the ram disk, and ran Milko's speed test and got
      exactly the same results -- 2 minutes 30 seconds. Wierd. How could it
      not be incredibly faster? My dual CPUs ran at 50%, with one near 100%
      and the other near idle; I checked the affinity for PTgui was set to
      both.

      -Matt


      --- In PanoToolsNG@yahoogroups.com, Bruno Postle <bruno@...> wrote:
      >
      > On Sat 01-Dec-2007 at 22:28 -0000, matt_nolan_uaf wrote:
      > > To create a hi-res spherical, PTgui says 7 tiffs at 70MB each
      > > requires about 1GB of scratch disk -- if I have 4 GB of RAM, why
      > > does it need a disk at all except to save the final image?
      > > Wouldn't doing everything in RAM dramatically speed things up,
      > > especially since disk I/O seems to be the bottleneck?
      >
      > Good point, try setting up a 2GiB RAM disk for the scratch data and
      > see if that makes an improvement.
      >
      > --
      > Bruno
      >
    • Joost Nieuwenhuijse
      This is because PTGui was already using RAM.. PTGui stores temporary data in temp files, but due to the OS s file system caching, the files never really get
      Message 2 of 19 , Dec 2, 2007
      • 0 Attachment
        This is because PTGui was already using RAM..

        PTGui stores temporary data in temp files, but due to the OS's file
        system caching, the files never really get written to disk but instead
        they are cached in RAM. Only for large panoramas the OS will not have
        enough cache memory and that's when the temporary files actually start
        being written to disk.

        This also means that PTGui should use all available RAM as long as the
        OS is not doing anything else.

        These 'stitching speed' questions are always difficult to answer since
        there are so many factors that influence the speed.

        Joost


        matt_nolan_uaf wrote:
        > I created a RAM disk using http://www.ramdisk.tk/, changed my scratch
        > disk and write disk to the ram disk, and ran Milko's speed test and got
        > exactly the same results -- 2 minutes 30 seconds. Wierd. How could it
        > not be incredibly faster? My dual CPUs ran at 50%, with one near 100%
        > and the other near idle; I checked the affinity for PTgui was set to
        > both.
        >
        > -Matt
        >
        >
        > --- In PanoToolsNG@yahoogroups.com, Bruno Postle <bruno@...> wrote:
        >> On Sat 01-Dec-2007 at 22:28 -0000, matt_nolan_uaf wrote:
        >>> To create a hi-res spherical, PTgui says 7 tiffs at 70MB each
        >>> requires about 1GB of scratch disk -- if I have 4 GB of RAM, why
        >>> does it need a disk at all except to save the final image?
        >>> Wouldn't doing everything in RAM dramatically speed things up,
        >>> especially since disk I/O seems to be the bottleneck?
        >> Good point, try setting up a 2GiB RAM disk for the scratch data and
        >> see if that makes an improvement.
        >>
        >> --
        >> Bruno
        >>
        >
        >
        >
        >
      • Pat Swovelin
        ... Is that also a good number for WinXP with 4GB RAM and the 3GB switch flipped? ... Pat Swovelin Cool Guy @ Large
        Message 3 of 19 , Dec 2, 2007
        • 0 Attachment
          On 12/1/2007 3:44 PM, Hans Nyberg rambled on about ...:
          > --- In PanoToolsNG@yahoogroups.com, "AYRTON - avi" <avi@...> wrote:
          >> On 12/1/07, Hans Nyberg <hans@...> wrote:
          >>
          >>> The 11400x5700 16bit takes 31 minutes using PTguiWarp + Ptgui Blend.
          >>>
          >>> Using PTGuiWarp + Enblend with 3 GB Ram applied I get down to 19.20
          >>> minutes.
          >> Sorry I could NOT figure out HOW to aplly more RAM when using Enblend ???
          >> Pls some directions will be appreciatted :-)
          >> Thanks
          >
          > In PTGui Preferences/Plugins write: -m 3000 in the command line parameters

          Is that also a good number for WinXP with 4GB RAM and the 3GB switch
          flipped?

          > If your mac and Enblend 3.0 behaves the same as mine enblend will
          > crash after a while if
          > you try to apply 3600 or more.
          > How much Ram did you get?
          > I just found out that I can update my G5 with 4 gb and get 8 in all
          > for just $130.
          > I guess I paid 4 btimes as much at least for the 4 GB I got when I
          > bought the G5.
          >
          > Hans




          Pat Swovelin
          Cool Guy @ Large
        • matt_nolan_uaf
          This is because PTGui was already using RAM.. ... instead ... have ... start ... I guess I m missing something easy and fundamental. For fisheye sperhical
          Message 4 of 19 , Dec 4, 2007
          • 0 Attachment
            This is because PTGui was already using RAM..
            >
            > PTGui stores temporary data in temp files, but due to the OS's file
            > system caching, the files never really get written to disk but
            instead
            > they are cached in RAM. Only for large panoramas the OS will not
            have
            > enough cache memory and that's when the temporary files actually
            start
            > being written to disk.
            >

            I guess I'm missing something easy and fundamental. For fisheye
            sperhical projects using only a GB or so, does this mean that using a
            virtual RAM disk will have no benefit on any computer, not just my
            slow, bloated one? Also, if everything is happening in RAM already
            with a small stitch, why is there a hard disk bottleneck at all?



            > This also means that PTGui should use all available RAM as long as
            the
            > OS is not doing anything else.
            >
            > These 'stitching speed' questions are always difficult to answer
            since
            > there are so many factors that influence the speed.

            I bet. But I guess my interest in understanding the existing messy
            hardware issues is so that I can purchase something that is optimized
            for stitching, with a minimum of unknowns involved.

            What I'm trying to decide at the moment is whether it's worth
            investing in something like the iRAM disks, or whether virtual RAM
            disks would do the same thing but better. These iRAM disks seem to
            be an order of magnitude faster or more than the fastest spinning
            disks. Any insights would be appreciated.

            Thanks,
            Matt
          • Joost Nieuwenhuijse
            ... If you have enough RAM, yes. Windows will effectively emulate a RAM disk by means of file caching. ... For small panoramas there should not be a hard disk
            Message 5 of 19 , Dec 4, 2007
            • 0 Attachment
              matt_nolan_uaf wrote:
              > This is because PTGui was already using RAM..
              >> PTGui stores temporary data in temp files, but due to the OS's file
              >> system caching, the files never really get written to disk but
              > instead
              >> they are cached in RAM. Only for large panoramas the OS will not
              > have
              >> enough cache memory and that's when the temporary files actually
              > start
              >> being written to disk.
              >>
              >
              > I guess I'm missing something easy and fundamental. For fisheye
              > sperhical projects using only a GB or so, does this mean that using a
              > virtual RAM disk will have no benefit on any computer, not just my
              > slow, bloated one?

              If you have enough RAM, yes. Windows will effectively emulate a RAM disk
              by means of file caching.

              > Also, if everything is happening in RAM already
              > with a small stitch, why is there a hard disk bottleneck at all?

              For small panoramas there should not be a hard disk bottleneck, assuming
              that disk caching is enabled for your temp drive (thanks to Bernhard for
              pointing that out..)

              > What I'm trying to decide at the moment is whether it's worth
              > investing in something like the iRAM disks, or whether virtual RAM
              > disks would do the same thing but better. These iRAM disks seem to
              > be an order of magnitude faster or more than the fastest spinning
              > disks. Any insights would be appreciated.

              I think it will not make much difference, but the only way to find out
              is by trying. But that could be an expensive experiment, I agree..

              Joost
            • Bernhard Vogl
              ... Well it s not as simple ;-) - quarter stroking *can* speed up head positioning as long as you don t use the other portions of the disk. But similar
              Message 6 of 19 , Dec 5, 2007
              • 0 Attachment
                > Another trick I've read about is called quarter stroking your disk.
                > Apparently you can create a partition on a 7500 RPM disk such that
                > the partition is only using the inner portion of the disk, so that
                > the arm doesnt move so far. Doing this is apparently faster than
                > using a 15k SAS disk, and much cheaper, and plus you still get the
                > slow part of the disk to use for storage.

                Well it's not as simple ;-) - "quarter stroking" *can* speed up head positioning as long as you don't use the other portions of the disk. But similar concepts are implemented in nearly every file system driver. E.g. the middle of the disk is used to store directory information and the data is arranged around it. Chunks of a file are stored near to each other as long as there's enough space left for an optimal placement. Only if the filesystem is nearly full, the chunks are placed non-optimal.
                This is the reason why you never should fill a files system above approx 70%.
                Another thing to point out: It's not the inner side of the disk which is the fastest, it's the outer side. The disk surface below the head has an higher speed here, so you can store more data in a given time than on the inner side.

                Just in case i didn't already mention: I strongly suggest everyone who is not perfectly sure what he's doing to use a standard setup instead of tweaking the system. There are chances that the system become worse than before...

                Best regards
                Bernhard
              Your message has been successfully submitted and would be delivered to recipients shortly.