[x264-devel] Performance difference between windows and linux

[Pradeep Ramachandran]

Finally we realized that the issue was with the "power settings" in
windows. By default, even on Win 2012 R2, the "balanced power option" is
selected which seems to enable deeper C-states of the core. For performance
measurements, we should move to the "high performance option". Doing this
closed the gap between windows and linux! I believe the 2016 builds have
addressed this issue, but I haven't gotten my hands on a system with that
build to test it out.

On Tue, Feb 7, 2017 at 4:15 PM, Henrik Gramner <henrik at gramner.com> wrote:

> On Tue, Feb 7, 2017 at 5:45 AM, Pradeep Ramachandran
> <pradeeprama at gmail.com> wrote:
> > I'm copying my files to a RAM disk that I create using a tool like lmdisk
> > and reading files from there; shouldn't that be sufficient?
>
> Depends on how the OS kernel handles it. If it's clever enough to
> essentially treat the RAM disk directly as a page cache that would
> avoid unnecessary memory copying, but if it treats the RAM disk as
> just a fast disk and still caches files then the file will likely be
> read from memory, written back to different location in memory (the
> page cache), and then read from there, which is inefficient for
> obvious reasons. I'm not a kernel dev and I have no idea what either
> system does.
>
> The raw input modules in x264 CLI uses mmap()/MapViewOfFile() if
> possible which essentially maps a portion of the OS page cache
> directly into it's address space.
>
> It's probably a good idea to to test both cases of the input being
> cached or not.
>
> To test cached input it should be enough to read through the entire
> input file a few times first as long as the file is reasonably small.
> To test uncached input the OS page cache needs to be cleared before
> each run, this can be done as following:
>
> Linux:
> sync && echo 1 | sudo tee /proc/sys/vm/drop_caches
>
> Windows:
> Run https://technet.microsoft.com/en-us/sysinternals/rammap.aspx and
> use Empty -> Empty Standby List.
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> https://mailman.videolan.org/listinfo/x264-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20170310/677c00e2/attachment.html>