Ross Levis wrote: >I'm obviously not aware of all the benefits 64-bit can provide. Native >64-bit integers, large floating point numbers, access to lots of RAM, is all >I've thought of. Can you explain why memory mapped files are unnecessary in >a 64 bit world?
Permit a rather long explanation: If one has to program for people who work on images whose sizes are such that they can no longer be stored as a complete array causing the application to run out of paged pool system memory heap (see Chapter 7, Memory Management, pp 401 ff. in Microsoft Windows Internals, Fourth ed. M. E. Russinovich, D.A. Solomon, MS Press, 2005), then an "out of memory" message from the OS results even though physical memory may far exceed the 491.875 MB available in Win 2000 & XP or 650 MB on WinServer 2003. This is a design limitation dating from the origins of Windows NT back in the early 1990's. My main machine (SuperMicro, 2 AMD dual core Opterons, with 4 GB physical and 3 GB user space using the /3GB switch in boot.ini suffers from this. For example, this limit is easily reached or exceeded when working on a full NASA Landsat 7 false color tile. If you declare a canvas for this in Delphi so that you can write something to it, the OS will crash the program with an "out of memory" error although it really means "out of paged pool". If instead, you use a memory mapped file which resides on disk and use pointers to return portions to be worked on, larger images can be treated although no canvas is permitted. Little window pieces can be "cut" out of the main image, stored separately, written to and then inserted back again without overhead. Some operations can be agonizingly slow while the system queries the disk for additional data that's not currently mapped. If the operations are sufficiently local so that a circular set of buffers can be used to "roll through" the image, then this speeds things up, but if the operations are non-local, then one has to live with the speed penalty. In 64 bit Windows, the maximum pool is 128 GB, so an image can be handled as a 2D array and stored and treated entirely in main memory independently of locality of an operation. Thus, to answer your question, memory mapped files are not necessary as long as the pool is still available. Hopefully, a 64 bit Delphi will have a canvas. A typical non-local operation is geometric transformation of a set of multiple images for rectification in digital photogrammetry. In the old days of Win 9x, one ran into this problem with fairly modest images, but the 32 bit environment of WinNT solved that for a while. The pool, by the way, is shared by all windows, so even less is available than might first seem evident. As the saying goes, "appetite increases with eating". Modern digital aerial cameras have largely replaced the older 228 mm side length color film scanned at 10-25 microns per pixel with multiple full color sensors often with 20K + side lengths and image strips running into the sub-terrabyte range. Similar data quantities are encountered in satellite images from QuickBird (Digital Globe) and others like Google Earth's Keyhole data if paid for. Even a modern Hasselblad camera with a 39 Megapixel digital back, if used in high dynamic range mode, can also break the OS limits quite easily. My attempt to use the AWE (Address Windowing Extentions, ref. above, p. 399) which theoretically might allow for larger windowed space have not succeeded in Delphi 7, although the memory mapped files used in HiComponent's TIEBitmap are ok but slow. I have tried both the internal Delphi memory manager and FastMM4. Perhaps someone on this list can tell me why. Irwin Scollar _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
