[SDL] #sdl - Hardcore programmers at work
akawaka at csn.ul.ie
Sun Apr 23 11:36:30 PDT 2000
>On Tue, Apr 11, 2000 at 05:43:47PM +0200, Daniel Vogel wrote:
>> AFAIK the memory mapping SMPEG used was not portable.
>Well, there's nothing non-portable about memory mapping, per se, and
>it should be a big speed win. Sam, any specifics?
Sexy as mmap is, it isn't always faster. I included an explanation from some
kernel hacker below. Morale (as always): profile, profile, profile!
To: linux-kernel at vger.rutgers.edu
From: torvalds at transmeta.com (Linus Torvalds)
Subject: Re: mmap/mlock performance versus read
Date: 5 Apr 2000 13:18:19 -0700
Organization: Transmeta Corporation
Sender: owner-linux-kernel at vger.rutgers.edu
X-Loop: majordomo at vger.rutgers.edu
In article <200004042249.SAA06325 at op.net>,
Paul Barton-Davis <pbd at Op.Net> wrote:
>I was very disheartened to find that on my system the mmap/mlock
>approach took *3 TIMES* as long as the read solution. It seemed to me
>that mmap/mlock should be at least as fast as read. Comments are
People love mmap() and other ways to play with the page tables to
optimize away a copy operation, and sometimes it is worth it.
HOWEVER, playing games with the virtual memory mapping is very expensive
in itself. It has a number of quite real disadvantages that people tend
to ignore because memory copying is seen as something very slow, and
sometimes optimizing that copy away is seen as an obvious improvment.
Downsides to mmap:
- quite noticeable setup and teardown costs. And I mean _noticeable_.
It's things like following the page tables to unmap everything
cleanly. It's the book-keeping for maintaining a list of all the
mappings. It's The TLB flush needed after unmapping stuff.
- page faulting is expensive. That's how the mapping gets populated,
and it's quite slow.
Upsides of mmap:
- if the data gets re-used over and over again (within a single map
operation), or if you can avoid a lot of other logic by just mapping
something in, mmap() is just the greatest thing since sliced bread.
This may be a file that you go over many times (the binary image of
an executable is the obvious case here - the code jumps all around
the place), or a setup where it's just so convenient to map the whole
thing in without regard of the actual usage patterns that mmap() just
wins. You may have random access patterns, and use mmap() as a way
of keeping track of what data you actually needed.
- if the data is large, mmap() is a great way to let the system know
what it can do with the data-set. The kernel can forget pages as
memory pressure forces the system to page stuff out, and then just
automatically re-fetch them again.
And the automatic sharing is obviously a case of this..
But your test-suite (just copying the data once) is probably pessimal
More information about the SDL