<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 12, 2014 at 3:30 PM, Rafael Ávila de Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">It seems that the common wisdom on the fastest way to create a file is<br>
<br>
* create the file<br>
* resize it to the final size<br>
* mmap it rw<br>
* write the data to the mapping<br>
<br>
I benchmarked that against doing 1 MB writes to create a 1GB file with pseudo random data.<br>
<br>
The test program is attached. The results I got were (in seconds, mmap is the first):<br>
<br>
btrfs<br>
1.752698e+00<br>
1.112864e+00<br>
<br>
tmpsfs<br>
1.484731e+00<br>
1.113772e+00<br>
<br>
hfs+ (laptop)<br>
4.015817e+00<br>
2.240137e+00<br>
<br>
windows 7 (vm)<br>
1.609375e+00<br>
3.875000e+00<br>
<br>
ext2 on arm (old google chrome book):<br>
5.910171e+01<br>
6.566929e+01<br>
<br>
So on Windows it is true, mmap seems to be faster than writes. On Linux and OS X x86_64 the situation is inverted. On arm mmap is a bit faster.<br>
<br>
It would be interesting to see if someone else can reproduce these numbers. It would be particularly nice to try a newer arm system and windows outside a vm.<br>
<br>
Also, does anyone have a theory of where the difference comes from?<br></blockquote><div><br></div><div><div>On my Mac Pro (./test-file-output 1),</div><div>mmap: 2.8s</div><div>write: 1.6s</div><div><br></div><div>I DTrace'd the program to see what was going on. The mmap version spends less time doing IO actually. The problem is that the IO doesn't start until later. In fact, the IO doesn't start until the close, which occurs 1.8 seconds in.</div></div><div><br></div><div>From poking around with DTrace on the Mac and seeing what is actually going on in both cases, I'm guessing that on windows, the write() code path in the kernel is atrociously bad (or lots of syscall overhead), so there is a lot of overhead for each call, making the mmap version better. The chromebook is probably taking long enough (or is under sufficient memory pressure) that the kernel starts paging out before the close (I think linux by default is every 30s?), giving most of the benefit of the write version, but with naturally fewer overheads (especially if there is a spare core to page out on the side). The tmpfs is probably getting slowed down in the mmap case by setting up and tearing down the larger address space; you might want to try enabling/disabling huge pages (2MB and 1GB flavors on x86) to see if that affects things; I would be amazed if an mmap of a 1GB page in tmpfs is not the fastest (on fast CPU's).</div><div><br></div><div>The virtual memory performance seems to be really bad on Mac... Replacing the mapped_file_region with just malloc makes it barely any faster (with or without free). Probably this is because my Mac wasn't using huge pages for some reason (doesn't support huge pages?), as DTrace showed lots of kernel functions called # bytes / 4096 times. Majnemer, do you know if Mac supports huge pages? googling around doesn't seem to find anything (and I can scarcely imagine that VMWare wouldn't be using them... maybe they implement them in their kernel extension?).</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Cheers,<br>
Rafael<br>
<br><br>
<br>
<br>
Sent from my iPhone<br></blockquote></div></div></div>