[Insight-developers] Test for large image buffer convert

[Luis Ibanez]

Hi Sean,

All very valid questions...

Fortunately in this case, the decision has been
left to the human who configures ITK with CMake.   :-)

For the purpose of testing ITK I would suggest that
we set this number to the amount of "usable" RAM
available in the machine.

We probably agree in that we don't want to rely on
virtual memory for processing an image processing
pipeline.


    Luis


----------------------------------------------------------------------
On Tue, Aug 11, 2009 at 11:23 AM, Sean McBride <sean at rogue-research.com>wrote:

> On 8/10/09 4:40 PM, Luis Ibanez said:
>
> >We already have other tests in this category:
> >
> >       Tests that require 64bits and a large RAM.
> >
> >We enable them conditionally by using the CMake flag:
> >
> >        ITK_COMPUTER_MEMORY_SIZE
> >
> >with expressions such as:
> >
> >IF( ${ITK_COMPUTER_MEMORY_SIZE} GREATER 12 )
> >
> >  # Image of 9.12 Gigabytes (pixels size is 16bits)
> >  ADD_TEST(itkLargeImageWriteReadTest3 ${IO_TESTS}
> >itkLargeImageWriteReadTest
> >           ${ITK_TEST_OUTPUT_DIR}/LargeImage03.mhd  70000L )
> >
> >ENDIF( ${ITK_COMPUTER_MEMORY_SIZE} GREATER 12 )
>
> Is the idea here to reduce virtual memory thrashing?  On any modern OS
> that test could still be run even with insufficient physical RAM (albeit
> slowly).
>
> Should ITK_COMPUTER_MEMORY_SIZE state the amount of physical RAM in the
> machine?  What if my machine has 8 GB of physical RAM but my OS is only
> 32 bit (and thus a process is limited to max 4 GB RAM)?  Would that
> cause the test to run, but then crash?
>
> Thanks,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montréal, Québec, Canada
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090811/c5243533/attachment.htm>