-
2002.08.20 16:13 "RE: memory allocation", by Roger Bedell
-
2002.08.20 20:48 "OT: large memory allocation in Windows", by Dante Allegria
-
2002.08.21 08:34 "Re: OT: large memory allocation in Windows", by Rob van den Tillaart
-
2002.08.21 11:30 "Re: OT: large memory allocation in Windows", by Peter Majer
-
2002.08.21 13:47 "Re: OT: large memory allocation in Windows", by Rob van den Tillaart
- 2002.08.21 16:05 "Re: OT: large memory allocation in Windows", by Bob Friesenhahn
-
2002.08.21 20:47 "Re: OT: large memory allocation in Windows", by Peter Nielsen
-
2002.08.22 08:33 "Re: OT: large memory allocation in Windows", by Andreas R. Kleinert
-
2002.08.22 15:30 "RE: OT: large memory allocation in Windows", by Roger Bedell
-
2002.08.22 16:29 "Re: OT: large memory allocation in Windows", by Chris 'Xenon' Hanson
- 2002.08.22 17:20 "RE: OT: large memory allocation in Windows", by Roger Bedell
- 2002.08.22 17:33 "Re: OT: large memory allocation in Windows", by Peter Montgomery
-
2002.08.22 16:29 "Re: OT: large memory allocation in Windows", by Chris 'Xenon' Hanson
- 2002.08.22 15:59 "RE: OT: large memory allocation in Windows", by Ed Grissom
-
2002.08.22 15:30 "RE: OT: large memory allocation in Windows", by Roger Bedell
-
2002.08.22 08:33 "Re: OT: large memory allocation in Windows", by Andreas R. Kleinert
-
2002.08.21 13:47 "Re: OT: large memory allocation in Windows", by Rob van den Tillaart
- 2002.08.21 11:48 "Re: OT: large memory allocation in Windows", by Peter Nielsen
-
2002.08.21 11:30 "Re: OT: large memory allocation in Windows", by Peter Majer
- 2002.08.22 18:00 "Re: OT: large memory allocation in Windows", by Bob Friesenhahn
-
2002.08.21 08:34 "Re: OT: large memory allocation in Windows", by Rob van den Tillaart
-
2002.08.20 20:48 "OT: large memory allocation in Windows", by Dante Allegria
2002.08.22 16:29 "Re: OT: large memory allocation in Windows", by Chris 'Xenon' Hanson
Which means you are still restricted to the virtual address space size and fragmentation problems mentioned before. It doesn't sound like much of an improvement to me, but I may be wrong.
You are correct. Three avenues to solution present themselves:
#1: Use a 'Enterprise Edition' Windows OS, that apparently has a boot-time option to extend the per-process virtual address space from 2Gb to 3gb for applications linked accordingly as described here:
http://www.microsoft.com/hwdev/platform/server/PAE/PAEmem.asp
Downside: not available on most common Windows installations.
#2: Reduce your needs for simultaneous contiguous memory. Don't try loading the whole TIFF at once. In GIS fields we work with massive TIFF images, and we typically have to use the strip-loading or tile-loading APIs of libtiff to access only the parts of the TIFF image that we actually need at any given time.
Downside: makes some image-processing operations cumbersome and slow.
#3: Investigate the exotic realm of the VLM functions like VirtualAllocVlm and its ilk. Learn about strange and long-forgotten (since the days of DOS) concepts like segment paging (now called PAE):
http://www.microsoft.com/hwdev/platform/server/PAE/pae_os.asp
http://www.microsoft.com/hwdev/platform/server/PAE/PAEdrv.asp
Downside: Your soul will be sucked into the black void and rent into gibbering pieces by nameless horrors that haunt the night and shun the light.
This non-forward-thinking 2Gb limit brought to you by Microsoft and Bill "Who would ever need more than 640k?" Gates. ;)
Chris - Xenon
--
Chris Hanson | Xenon@3DNature.com | I've got friends in low latitudes!
New World Construction Set 6!: http://www.3DNature.com/
"There is no Truth. There is only Perception. To Perceive is to Exist." - Xen