Rob Leslie wrote:
On Thursday, February 21, 2002, at 04:20 PM, john cooper wrote:
Realistically, mmap() is a luxury provided by virtual memory operating systems. As used my minimad it is a simple way to get the system to do the file I/O automatically under the hood, and simplifies the programming model. You will however find doing the stream I/O yourself to be lower overhead and more appropriate for the application environments where libmad is attractive.
Granted, without a virtual memory system, mmap() might not be the best or even a possible approach. However, it can have special benefits when available that make it more attractive than traditional I/O. Since mmap() usually provides direct access to memory pages from the filesystem's block cache, the overhead of additional private buffer space and memory copying is avoided. Eliminating the buffer for your own stream I/O can be important especially in low-memory environments, particularly since multiple instances can share memory-mapped pages.
What I was getting at was if hardware FP isn't around I'd predict an MMU won't be either. libmad seems uniquely attractive in resource barren application environments -- perhaps even those forgoing much of an OS. In this case the application can do the required and minimal overhead IO without having to paw at it through OS abstractions.
Even on an embedded Linux/VM system, the overhead of VM mechanisms, policy algorithms, and coherency traffic start to steal valuable cycles from the typical low cost non-superscalar CPU's integer-processing bandwidth.
Of course you can find instances to the contrary as well.
On systems where the secondary data storage is already memory-accessible, such as flash devices, mmap() is an even more obvious choice.
In the case of a VM OS being between the application and physical memory resident data, I agree. Note in this case the MMU mapping is (or can be) static without the overhead of mapping via page fault, pushing dirty pages, aging page buffers, cache coherency, etc..