|Re: [hatari-devel] Memory mapped (mmap) image files|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 17.8.2021 16.36, Thorsten Otto wrote:
On Dienstag, 17. August 2021 15:20:21 CEST Uwe Seimet wrote:
Does anybody of you know whether accessing image files with regular file
system calls (like Hatari) is faster or slower than mapping those files into
memory (like RaSCSI)?
mmap()ed files are usually much faster, because I/O is done by the kernel
directly to your memory, without the overhead of calling file system
functions, copying buffers around etc.
And because kernel may be able to better optimize disk accesses. How
much better kernel could do this depends how disconnected the
loading and its manipulation functions are, i.e.
does it load a lot of data that's not really
Kernel is in both cases going to load data from
disk to memory pre-emptively (especially with
spinning rust), so in the end that might no be
a large difference.
Also, system call overhead is nothing compared to
emulation overhead, so I'm not sure whether it's
even measurable overhead for *emulated* SW.
I think largest perf difference is related to
behavior when host system starts to run out of
memory. With mmap(), kernel can just drop
references to non-written memory pages, but
when they're buffers that have been dirtied
by fread(), they need to be written to swap.
However on 32bit systems, that may not
always be possible, because you run out of virtual memory
Yes, total limit is 3.5GB, and libraries & other
memory maps and allocs already use part of that.
Another issue is portability (I assume Windows
has different APIs & behavior flags for the same
Also, on emulators, when you have to simulate reading data from some port
(e.g. from the IDE interface), swap data etc, that may not be an option at
Whether the data is loaded to host memory through
fread() or mmap() page faults, does not affect
how the emulated accesses to it happen.